Tag: support

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.

 

Vimeo Support Team Portraits

Something that I really enjoy about well-done Support is the way that is goes from a business transaction (think of the last time you called your cable or internet provider) to a more personal interaction. At WordPress.com we’ve recently added a bar of our Happiness Engineers’ Gravatars, like this:

In poking around Vimeo’s documentation today, I noticed they’ve taken this to the next level, with some neat hover states and built-in animation, and I really dig it. Check it out: