Tag: hospitality

Don’t Confuse Your Success for Customer Success

DataTNG
Data is awesome. Scientists have known this for a while now, but now we have Big Data, which some are going so far as to call a “Natural Resource” – watching a site like Growth Hackers only confirms that we are more interested in our data, and what it can tell us, than ever before.

This is a cautionary post. I love Google Analytics. I take great pride in being a part of a data-informed company, and I think solid data analysis and the drawing of insights from that analysis has a place in any modern business.

That part we can all agree on. That part is easy.

 

What I want to distinguish here is the difference between your success as a company, and the success of your customer. It is harder to focus on customer success when your data provides actionable insight that could trade their success for yours. I don’t mean to preach to you which one you should prefer: I’m a pragmatist, I can appreciate that sometimes to keep the doors open you have to make compromises. I’d encourage you to be honest with yourself, and simply recognize when you’re acting for your customer, and when you’re acting for yourself.

Maybe some examples would help illustrate what I mean.

  • Pop-up ads were gone for a while – remember? But now they’re back. Visually disruptive ad campaigns are the easiest example in this category. They may lead to more clicks, to additional ad revenue, but they are clearly not leading your customers to success. They are on your site to engage with your content and your products – obscuring those things with an external (or internal!) ad is putting your success ahead of theirs, plainly.
  • Opt-out or cancellation buttons and screens that include passive aggressive or semi-threatening language are becoming popular – “I don’t want to maximize my income.” “Leaving now may leave you at risk!” – these are, again, plainly putting a win for the company ahead of a win for the customer. You may minimize loss, but you’re not only putting aside hospitality, you’re being a bit of a bully. url
  • A/B Testing is a huge part of growth engineering and data collection. A button placed differently, a header image removed or altered, testing adjustments to see what converts, what leads to more traffic. Try to construct your A/B tests with customer success in mind. Their success is not usually tied as closely to conversions and page views – I can’t tell you what their success looks like, but they sure can!
  • When defining your Goals in a tool like Google Analytics, the same sort of thinking applies: yes, knowing the path your customers take to the final purchase confirmation page is important, but it is also worth considering the (much larger) group that does not convert. Identifying where they drop off, and using a tool like Qualaroo to find out why they leave, would help focus on their success.

Keep collecting data. Keep drawing actionable insights from it, but remember: the data doesn’t tell the whole story. Additional conversions, decreasing customer churn, these may look great on a quarterly spreadsheet, but you need to dig deeper to see if they are really giving your customers the best experience they can have.

Bad Hospitality Plus Shadow Labor

Full Disclosure: I’m only able to write this post because I got a parking ticket. Parking is the wrong word, because the ticket was actually for having a temporary registration displayed past its expiration date. Right – the piece of paper indicating that I had a new, paid, registration on the way? There are layers to this situation, but what I really want to discuss is the online bill pay system I used to pay my ticket.

It was pretty straightforward, name, address, ticket number. My ticket number as displayed didn’t work, so I scrolled down and found some instructions. Here are those instructions:

traffic-ticket

I’d imagine you’re going through the same series of emotions that I did: confusion, then suspicion, then despair. Yes, they are passing the work that could be done by ten lines of JavaScript onto their customers. Why format the information using a computer when you can force folks using your product to do it?

This is bad hospitality. It’s also shadow labor, which is a whole different can of worms. Luckily for http://www.parkingticketpayment.com, their customers are unique in that they absolutely must give them their money, regardless of terrible UX and hostile hospitality.

Don’t make your customers do the math. Please.

First Happiness Data Project

I’ve successfully harangued a pair of my colleagues (Rachel and Kevin) into getting our feet wet implementing some growth engineering tactics in our larger hospitality strategy. That strategy is, of course, to make WordPress.com customers the happiest customers in the world.

Here’s the 1.0 of the plan:

  1. Each of us will individually analyze the Google Analytics data for http://en.support.wordpress.com/
  2. From that data, we will each find what we see as the three documents with the highest traffic but also the highest bounce rate, indicating lots of views, and lots of departures from that document. The idea here being that these docs will either be the very best (customers problems are solved, and they go to their Dashboard to implement the solution) or the worst (customers simply abandon their search and head to Google. Or Buzzfeed. Probably Buzzfeed.)
  3. Add a pop-up survey to the bottom of each of these high-traffic-high-bounce sites asking general questions about the quality of the doc, feedback, etc. We haven’t sussed out these questions yet.
  4. Let the survey run for a few weeks, being vigilant to any support requests it might gather.
  5. Read the responses & confer with the documentation folks to work on improvements.
  6. Track the docs over time, watch for a change of bounce rate.

For a first dive, I’m hopeful. It will give us a chance to work together as a team, become familiar with the tools at hand (Google Analytics and Qualaroo, in this case), and hopefully iterate into bigger and better things!

Tickets Non-Ownership: New Data!

I am lucky in that I have some seriously smart coworkers – working at Automattic is a constant gut-check; the level of drive, creativity and ability are at a very high level. It would be exhausting if it weren’t so inspiring. We’re all lucky to work somewhere where we’re given time to work on side projects – in fact, some of these side projects take the form of project-based meetups, where a crew of Automatticians travel to a new city, and buckle down to work toward a goal.

I’m secondarily lucky that one of these project meetups came to a close at the end of last month, and some members of my squad came home with some very interesting insights. They had spent a week diving into the mountain of data that we have on feedback from our customers, looking for correlations. What was most closely associated with happy customers? How could we better calibrate ourselves to what makes our customers happy?

Data!
Data!

Admittedly, this is not the cleanest data set: the feedback mechanism leaves something to be desired, and that is certainly on our radar. But, this is the data that we have, and after some validation and cleaning up, they came to a surprising conclusion:

Reported User Happiness was most closely tied to the length of time between our first response, and resolution. 

Why is this surprising? Because it turns out that the amount of time between a customer submitting a support request and when they first hear back from us is does not appear to be not all that impactful: falling around .1 points per day (on a 10-point scale.) That’s only a 1% loss per day.

When a customer has heard back from us, time passing has a much greater negative impact, going from an average of 8.8 after 24 hours to 8.0 in our largest queue. That negative impact is eight times greater than the same amount of wait time between their submission and our first response.

This data indicates to me that the idea of leveling the wait time across all tickets is not the right approach: it assumes a roughly even wait time sensitivity regardless of the ticket’s state. This does not seem to be the case: our customers do not mind a bit of a wait to hear back from us, but once they’ve heard – they want our full attention.

The question remains: how do we move forward with the lessons from April and the implications of this new data?

Ticket Non-Ownership: Reflections

After doing some ruminating here as well as the discussion over on UserCentered, I decided to iterate a little on the idea of Ticket Ownership with my squad over at Automattic.

For the month of April, we eschewed  all ownership of our incoming support requests. What does this mean, exactly? Traditionally, our approach is this: the first Happiness Engineer to respond to a customer then replied to that customer each time they supplied more answers or information, until the issue was resolved. This past month, rather than seeing tickets as being owned by an individual, we owned our entire queue of tickets as a team – focusing not on ownership, but rather replying to the tickets strictly in terms of wait time – whichever customer waited the longest got the next reply, regardless of who had interacted with them in the past. Another way to look at this is this: we were evenly distributing the wait time across tickets, which is reminiscent of line balancing, a method of improving capacity use in production settings.

Wonderland_Walker_2
As April came to a close, I spent some time talking with the rest of my squad, seeing how they felt about the whole idea, if they wanted to continue, and what they saw as the upsides and downsides of this sort of non-ownership. Here are the two big advantages that non-ownership offered:

  1. It created an informal peer review: in reading through a support request’s history, you are able to see in very clear terms how other members of the squad approach different problems, as well as getting a first-hand look at their writing style, tone, and use of outside links (both to WordPress.com support documents and other tools).
  2. It allowed the Happiness Engineer team to much more quickly identify bugs when compared to full ticket ownership: this is because we were exposed to a much larger number of conversations per day, thus making patterns in customer reports much easier to spot than a traditional ticket ownership system, where it is much easier to write off a customer’s problem as misuse or misunderstanding rather than as a broader systemic bug. You can imagine if a Happiness Engineer replies to one customer 6 times regarding a potential bug, it will be cognitively less obvious as a problematic pattern than if the same Happiness Engineer replies to 6 customers a single time each.

And the negatives:

  1. Each particular support request felt less personally involved, and less personally invested, and at least from the Happiness side, thus felt less hospitable.
  2. Working on a request that someone else had already replied to felt more time consuming, as the Happiness Engineer had to re-do the legwork of researching the customer’s site, background information, etc.
  3. Highly time sensitive replies are answered at the same pace as other tickets, since the wait time load is evenly distributed.

Moving forward, we’re hoping to find a way to embrace the advantages while removing or reducing the negatives.

P.S. Does this sound fun to you? Does working on a small team providing hospitality to an enormous userbase seem like a worthwhile pursuit? Would you be able to restrain from strangling a Squad Lead who pulled this kind of experimentation on you? Good news – we’re hiring.