Tag: service

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.

 

Internal and External Service

When we think about service and support, it is very easy to think only of our customers, of the folks who have purchased our products or processes – we answer their questions, ensure their happiness, and so forth.

It’s worth considering that we cannot provide excellent service to our customers without first providing excellent service to one another – it’s always been my position that the very best way to serve a customer is not to put them first. Rather, there are a few groups of people who must be served with excellence and hospitality before we even reach our customers. In a restaurant, these are your vendors and your co-workers. This is sometimes called internal service – as opposed to customer-facing support or service, which would be external service.

This mindset applies to any business, especially in the tech sector – if your internal communications are flawed, if you don’t have a culture of mutual respect and support, it is impossible to extend really excellent hospitality toward your customers. 

Wait Time Distribution

Let’s do some napkin math on wait times and wait distribution among customers using an email or ticket-based support system. Here are the big assumptions I’m carrying into this one:

  1. There are enough tickets and customer support staff that averages work out as expected over time without major aberrations
  2. Staff is sufficiently well trained that each staffer can answer any particular ticket in the same amount of time

Wait time, defined here as the period of time between when a customer submits a ticket (or email), and when a staff member responds to it, is something on the forefront of anyone providing customer support in the world today. This is something cafe operators think about, this is something Operations Managers obsess over, it’s a really fun problem to chew on and try to figure out.

In this particular context, we have some flexibility that organizations like Subway lack – we get to choose the order in which we respond to our inputs. At Subway, you help the next person in line. It would be nice to group all of the meatball subs together, but that isn’t the way that their model operates. There are lots of ways we can batch incoming tickets – by difficulty, by product, by language, but the only kind of batching that I’m thinking about today is batching replies by ownership.

What do I mean by ownership? For this particular post, I’m thinking of ticket ownership in this way: once a ticket has been replied to once, it is owned by the operator that replied. That’s all. Once a ticket has a response from The Company and is awaiting a new reply from the Customer, that ticket and its ongoing conversation is owned.

The goal of ticket ownership is to ensure that customers who have created a relationship, whose tickets are owned, get priority. You respond to tickets that you already own first, before going on to new, unanswered, unowned tickets. There is a long history of hospitality leading customer interactions in this way – restaurants don’t usually switch up your waiters mid-meal, right?

I’m going to bastardize some operations management tools to work on this – namely a little bit of process diagramming. Here’s how a process diagram works:

b3VxVvy

Squares are customer activity, triangles represent wait time. Interactions from the customer side are fairly simple: you submit a ticket, you wait for a reply. When you hear back, you reply again, and wait some more. This goes on until your issue is resolved. From the support side, this would be much more complicated; seeking answers from developers, doing some research, etc etc.

Here’s a fact about support: without bringing in additional staff, making big changes to your training or management systems, or changing your approach in other ways, your average response time is going to stay pretty much static from day to day. When we look at response systems like ticket ownership, we aren’t really talking about decreasing our average wait time, but rather changing the way that it’s distributed. Let’s consider three approaches:

A.) Support staff reply first to tickets which they own, then move on to new tickets.

B.) Support staff ignore ownership, and reply to the tickets experiencing the longest wait time regardless of previous replies.

C.) Support staff ignore ownership, and reply to tickets experiencing the shortest wait time regardless of previous replies.

There are arguments for each of these, and there are many more ways we could break down the approach, but let’s focus on just these three.

Here’s what these would look like (roughly) diagrammed:

wG6QDHa

 

Or, a terrible graph:

wG6QDHa

We can see that what we’re really doing is simply moving our wait times around; approaching online support through ticket ownership is a way of front-loading our wait time – essentially saying “Once we get to you, we’ll reply more quickly.” It’s not obvious to me that this is the very best way to approach this. It seems like each of these approaches could be equally valid, at least in the abstract, and I can see arguments for all of them.

The good news is that we can experiment! Every support department should have a feedback mechanism through which their customers can close a feedback loop. I encourage you to mix up your approach – spend a month using Approach B rather than Approach A – or, if you really want to mix it up, give C a try. Be careful with C, as if you aren’t able to clear all of your tickets every day, your oldest tickets will become asymptotic to the wait time axis, and that’s not good for anyone.

Give it an honest shake; try to reserve judgment as to how the system is working – you’re iterating and collecting data, after all – and, and the end of the month, compare your feedback numbers. Let the data speak for itself – if nothing else, you and your team will have shifted mindsets about how to approach the question of wait time distribution.

 

Danny Meyer on Data and Hospitality

Tell us a little bit about your “ABCD” (Always Be Collecting Dots) policy?

Meyer: Dots are information. We hear a lot about the business need to “Connect the dots.” But unless you’ve turned over every rock–working athletically to collect information–there just won’t be many dots to connect. ABCD is my way of encouraging our staff members to learn as much as they can about our guests and the world so that we can create even stronger strands of loyalty and constantly make new friends for our restaurants. Taking an extra interest in people goes a long way.

This applies to any business that deals with the public – hospitality counts, and not just when it comes to serving food and drink. The individuals best suited to collecting and connecting dots are the folks who talk with your customers every day. Support staff serve as an essential hinge between the development process and the consumption process; service staff can be a huge resource if you let them.

Meyer is an inspiration to me, and anyone working any sort of support or service should read his book, Setting the Table. I wrote about another interview with him a while back.