-
Posts
-
Let’s talk a little bit about ticket ownership - in your team, when you receive an incoming support request, what happens next? It seems like there are two big schools of thoughts:
- The person who replies first answers to all subsequent correspondence with that customer
- Everyone answers the oldest available tickets, regardless of past correspondence
What do you do? One of these, or maybe something else? I think there are pros and cons to each approach, and I have opinions, but I’m very curious how this is approached elsewhere.
Great question! With our team, the support pro who replies first handles all the replies to that ticket. It keeps things simple and the customer doesn’t get passed around to a bunch of different people.
We also include our working hours in the bottom of the first email. That way the customer can start a new ticket if they’ve got a question in the middle of the night. That new ticket would be picked up by the support pro working and they’d take it from there.
@chase - Do you find that customers will actually create a new ticket (in the way you described), or do they often just reply to the existing ticket with a new question?
@hoonpark - What I’ve seen so far is that if it’s a non-urgent question, the customer just replies to the existing ticket. If it’s something that needs an immediate reply, they create a new ticket. I’ve only been testing that out for a few months but it seems to be working well so far!
@chase - Do y’all say anything in the email or signature to suggest to the customer to start a new ticket if something urgent comes up?
To answer the original question @saouderkirk asked: my team of three uses the “option #1″ approach, where the agent who makes the first reply owns the ticket until the end. The only exception to this is when someone is out on a normal business day (vacation/sick). Incidentally, if this happens, the ownership of the ticket changes to the new agent taking it over.
Also, everyone has the option to jump in to an existing ticket and “take it over” if it means a faster response to the customer. Sometimes this happens when one agent doesn’t know the answer and is waiting to hear back from product/engineering/etc, and another agent happens to know the answer. We take care of the “educate each other” side of things after the ticket is resolved.
@hoonpark - Here’s what my most recent version in my signature looks like:
Please Note: It’s 11:42AM Central Time right now. I work M-F 8am-5pm Central Time. Replies outside of that might be a bit slower.
If you’d like an answer outside of those hours, the quickest route is to send us a new ticket at
https://basecamp.com/support. One of our other awesome support pros will get you an answer back right away!So let’s chaw on this a little bit - Automattic generally also goes with ticket ownership, though it’s been on my mind quite a lot lately. Why have we all gravitated toward this as a preferred method of service?
Is it because it’s sort of how most service based transactions work? When you picture a nice restaurant, maybe Blue Smoke, part of that picture includes one waiter who serves your table, returns, brings the food, etc. When we go to the DMV (still a service transaction!), we deal with one person, muddle through it, go back and forth, and head home. Are we simply matching existing institutions with our current model?
And - this is the big question - is it the best way to do it? There’s probably a blog post in here once I get my brain around it, but in assigning ownership in this way, aren’t we simply front-loading the wait time? That is, average wait time is generally inflexible without adding more staff or throttling intake - which means that if we own tickets and answer our own previously-replied-to tickets first, what we’re really doing is increasing wait time for unanswered (yet unowned) tickets.
I’m not sure that that is the most hospitable thing. I’ll write a blog post.
Here we go: http://ouderkirk.co/2014/04/15/wait-time-distribution/
@saouderkirk Fantastic post!
For me, I like taking ownership of tickets because I become familiar with that person and what’s going on. When the customer replies, I’m able to send them an email right away rather than reading back through the history to figure out what’s going on.
With the DMV example, imagine each new DMV employee having to spend five minutes looking at my history when I got passed over to them. For me, I’d rather have one DMV employee stick with me through the whole thing. Like you pointed out, the downside is that to speed up response times, they would need to hire more people. But I think that’s acceptable to deliver a solid customer experience.
We do it the other way — any Support agent can answer any ticket that’s waiting in the queue. We’re a very small team dealing with a lot of volume and various work shifts, so this helps us keep the queue under control no matter who’s currently working. I think there are certainly downsides to it. Ownership over a given ticket from start to finish definitely allows for extra TLC in many instances. But our method really helps to keep the whole team abreast of each others’ techniques. We’re all in a state of constant training, because we see another agent respond to a ticket in a way we wouldn’t have, or do something creative that makes us incorporate something new into our workflows. I think our skills are better for it.
Great conversation to have - we should make sure to examine our assumptions regularly!
I do think it depends on the complexity of the systems. To @chaseclemons’s point, it’s silly for one of my agents to be digging around in transaction history making sure they understand exactly what the issue is when the agent who originally answered the ticket may be able to answer that question instantly. That’s less of an issue if you’re making a sandwich at Subway, where you are starting fresh at each “station” anyway.
As an agent, I like owning my own tickets. If a ticket thread is ongoing, it’s usually a more complex issue, so it doesn’t make sense for another agent to get up to speed, and with certain issues, that can take a lot of time (resulting in everyone waiting longer for an answer).
Also, it lets me build a relationship with the customer as we work to get it figured out. Building that relationship with customers is one of things I love about support.
As a customer, I dislike sending in a ticket, getting help from one agent, writing back and hearing from a completely different person (unless it’s being escalated to another tier of support). Do they actually understand my issue like the last person? How much time will it take to get them up to speed?
Also, sometimes I’ve written back just to say thank you, only to have a different agent (who never helped me) say you’re welcome. That just seemed odd.
Yeah, I think users do dislike being responded to by different people who may or may not know what’s going on with the issue, but we try to read every ticket SUPER thoroughly to avoid reinventing the wheel with every response. I think what I’ve found is that users hate waiting a long time for a response even more than they hate multiple responders. But that may be because our demographic skews very young (read: impatient).
For the most part, I think that it’s best to keep the same agent responding to the same ticket for relationship building and consistency and knowledge of the issue at hand for sure. However, every once in a while, when something goes south with a customer, or there’s a particularly difficult issue, having a different agent introduce themselves and take over the conversation can be a very powerful thing. It’s kind of like asking the manager to step in and help - or escalating, as Claire said - but we’re a little more subtle about it.
In my help desk team we are trying to figure out which one is the best method. Maybe a intermediate model? We support the whole end market salesforce team from our customer. We need faster response, and the model that @tess works would be perfect, but it is to hard to control the demand as we dont have good options in terms of tools (a lot of our work is done with excel sheets). The ownership would be a better alternative because the tickets won´t get lost in the “midst of incidents”. I’m thinking of using a mix of the two techniques: taking ownership of the tickets directing them to other agents as needed at the time. What do you think?
You must be logged in to reply to this topic.