It’s week four of the Support Driven Writing Challenge, and sadly, I’m a bit behind what with the US holiday and the customary food coma. That said, let’s get cracking.
The Ubiquitous Ticket Queue
I’ll start off by saying that the most common way of supporting our customers at DigitalOcean (from a Customer Success Team standpoint), is via support ticket through our home-grown system. That’s where most of our work comes from, be it customer-initiated tickets, or automated tickets. A majority of the time, tickets work decently. But there are some pitfalls, especially when working for a self-managed platform like DigitalOcean. Namely, that the ticket approach can seem impersonal
We also use email to support customers working directly with our Customer Success team. This is done via Helpscout, and works fairly well. Emails, while they don’t have an SLA attached to them, typically get responded to quite quickly. Emails also tend to not deal so much with in-depth technical issues, and when they do, we usually push that sort of thing to a ticket, so that everything is documented and auditable.
The Not-So-Common Phone Call
At my previous two positions, phone calls were the bread an butter of what I did, especially at Rackspace. I typically was on the phone with a customer walking them through and issue, and troubleshooting an issue on their server while they watched. It was a bit nerve-wracking at times. However, since DigitalOcean doesn’t have a support line, the phone support that we typically do tends to be on the more consultative side. For example, my team works with quite a lot of startups who come through our “Hatch” program. Many of the calls that we do are introductory, and I like to think of them as a first date. You know, the “Hi, who are you? What do you do? Here’s what I do” sorts of calls. On the rare occasion, we’ll hop on the phone with a customer and troubleshoot over the phone.
A View of the Other Side of the House
Just to give an idea of what our front lines teams do, they typically operate off of tickets, but also include social support via Twitter or Facebook. Our support team definitely sees a higher volume of tickets than our Success team, so our ticketing system shines when they’re able to address quite a few tickets in a relatively short amount of time.
I wasn’t around for the choosing of any of the components of our support stack, and it’s been interesting to read up from other members of the Support Driven community who have had that opportunity to build theirs out. That said, I’ve got no opinions really on the platform that’s being used to provide support (a la Zendesk, Kayako, Intercom, etc.).
I will say that I have a bit of a love/hate relationship with ticketing systems. For all the benefits they provide, I find ticketing systems to be the least personal out of any support tool. That may be the communication researcher in me speaking, but I think the loss of verbal/nonverbal queues can exacerbate situations in which those sorts of things are necessary. I can tell a customer in a reply that I empathize with them, and that yeah, it’s terrible that X happened, but they don’t get to see that. Instead, they’re forced to infer my tone/meaning in my reply. And no matter how much I try to instill empathy into a response, there will always be a case where that falls short.
Phone support, if done well, can eliminate some of that–namely, the lack of verbal queues. This all goes back to training, though. If a support agent isn’t empathetic, and doesn’t take the time to put themselves in their customers’ shoes, all the phone support in the world won’t do any good (I’m looking at you, Comcast & Time Warner). So I think (and perhaps I’ll do a post on this in the future) that while a support stack is important, and should be chosen carefully, it’s really a collection of tools to accomplish one purpose: supporting a customer. If the tools don’t do it well, then they’re not worth choosing. Likewise, it’s important to have people on your team who know how to use those tools effectively. If you choose a tool that doesn’t allow for being able to pick up on verbal/nonverbal queues, the person behind that tool has to know that weakness, and compensate for it.
Well, I’ve rambled on long enough, and I’ve got to get cracking on the next post! Stay tuned for a Day in the Life Of a 3rd shift Customer Success Engineer at DigitalOcean.comments powered by Disqus