Customer Support Via Twitter: Fear, Loathing, And the Right Way to Do It
These days, companies are strongly encouraged (by market forces, mainly) to open up as many “front doors” for customers to walk through as possible. Email, Twitter, Facebook, Skype, Instagram , in-app chat, contact forms — the list goes on.
It’s not surprising that customers often choose the path of least resistance when they need help. Sending a tweet or a Facebook message is not only much easier than dealing with email or filling out a contact form, there’s the expectation of quickly getting a response.
Today I’d like to focus on the pros, cons, and technicalities of using Twitter as a customer support medium.
The Way Companies Interact with Customers on Twitter Today
Recently I did a small, but telling research exercise. I browsed through “Tweets & replies” of a few dozen companies’ Twitter accounts, and I noticed a couple of recurring themes.
First, it’s surprisingly common to see significant periods of silence between a customer’s tweet and the company’s response.
Here’s an example from RdioHelp’s feed:
There is a 27-day gap between a customer’s question and the team’s comeback. Of course this wasn’t intentional, the tweet probably got lost — RdioHelp is otherwise extremely responsive.
This happens all the time, with companies of every size and stage, as long as they actually ship a product people can complain about.
Second, companies tend to rescue conversations away from Twitter as soon as possible, requesting that the customer send an email or file a bug report. Intercom is a great example of this. Here’s a fan of theirs shaking his head at Intercom’s pricing structure:
Intercom’s Twitter feed has practically no conversations — it’s mainly composed of requests to divert discussions to email:
What Intercom is doing is actually very responsible: they are capturing issues, complaints, and feature requests in a system (CRM, bug tracker, Intercom?) where data doesn’t run away like it does on Twitter. While this does create an inconvenience for the customer — she has to come up with a subject line, compose an email, and send it into the unknown — the approach all but guarantees a response.
There are tools and services specifically designed to manage interactions on social channels — Hootsuite is a well-established player in this space, for example, while Respondly and Sprout Social are some of the newer entrants. There is an entire industry bustling with products that can help you manage, analyze, and otherwise harness your (or your competitor’s) social presence.
The Twitter Problem That Most Companies Face
What we’re seeing is a sort of a love-hate relationship that businesses have with Twitter. Companies have to get lots of followers to project social proof, be responsive and helpful to retain customers, and of course dispense memes and emoji with ease. This is at odds with the reality of routinely losing inbound requests and having to keep actual Twitter interactions to the minimum.
If you’ve ever attempted to engage in even two concurrent public conversations on Twitter (who are we kidding? Even one!), you will probably agree that getting those conversations off Twitter as soon as humanly possible without appearing rude, is the only way to go.
But oh, how nice would it be to keep the discussion there, on Twitter? Such benefits don’t exactly grow on trees: public display of unrestrained customer engagement, increased social footprint, ongoing relevant, topical conversations — immediately indexed by Google, by the way — all about your product or company!
Here, at Sameroom, after we accidentally let one too many public mentions slip away despite having several people watching the account (and having a mentions feed in workspace chat), we began thinking about how to fix the underlying problem. We wanted for it to be feasible—workable, even — to maintain meaningful conversations on Twitter with our audience. We needed three things: a way to respond to a customer as quickly as possible and to keep the conversation going as long as necessary, an easy mechanism for involving a topic expert from our team to address tricky questions, and a simple way to search past conversations.
We don’t have a dedicated support team. Instead, everyone does support. This means something like Hootsuite or Respondly is a tough sell, because we’re all maxed out on the number of tools we use — monitoring yet another one would not work, long-term. Plus, we’re narrowly-focused on support, not so much marketing or sentiment analysis.
What we needed was a way to respond to tweets from team chat, our mission control center.
The software we’ve been making up to that point provided us with a set of fairly low-level constructs aimed at bridging chat rooms or channels between different teams and services. But you had to configure these connections manually, by specifying rooms or channels for Side A and Side B:
The question was, “can we figure out a way to represent a public Twitter conversation as a ‘chatroom’, or a list of temporally organized replies?”
How We Built a Twitter Support Tool at Sameroom
We decided we could automate the creation of our bridges (we call them Tubes) by having a new channel in our team chat created for each new Twitter mention (or DM). There, we could respond and receive subsequent replies in real time. We had three goals in doing this, all of which were pretty crucial to the operation being useful.
Goal #1: Find a way to respond to a customer as quickly as possible and maintain the conversation as long as necessary.
Here’s how it works. A new question from a customer appears in a dedicated channel:
To reply, all staff has to do is….reply:
As long as you’re on the Twitter on-call team (it’s configurable), you will automatically join each new channel bridged to the conversation on Twitter.
There are a few key observations here:
- You don’t need to use another dashboard to monitor activity;
- You don’t need to know the corporate Twitter credentials;
- Each conversation resides in its own channel, which makes it actually possible to follow a discussion (this gets tough in a typical single-channel notifications feed);
- It’s real-time.
Goal #2: Figure out how to involve an expert from your team — without spamming your customer on Twitter.
This one was a little tricky. To address this requirement, we came up with the “hush command” — any message that begins with ^^^ does not leave the channel. With the hush command you can type stuff like:
^^^ @alice, what do you think about this?
This lets Alice in on the conversation (she joins the channel, if needed); she is even free to take over responding.
The side effect of using team chat is greatly improved conversation coherence — it’s very easy to follow:
Goal #3: Create a simple way to search past support discussions
This one was actually easy: team chat search will quickly reveal all channels with matching Twitter conversations
The Future of Support on Twitter
So, is this really the right way to do it? We’re not sure yet. The few teams that are trialling this out say they’re happy.
We’re happy as well. In fact, I don’t know how we were doing this before. Of course, there are still some issues, like dealing with emojis, or managing N-way conversations, where N > 2:
- We realized, on our own, that we shouldn’t create channels for every retweet;
- Sherman (the Tweeter above) helped us realize that self-initiated tweets shouldn’t create channels either — only responses;
- The biggest problem is that we still need to add a bunch of other “front doors” to work with this system — at the moment we only have adapters for Twitter and Intercom.
I have a strong feeling that this approach of dealing with support on Twitter will help bring us closer to sustainable communication. Learning how to remove tools from the workflow, while increasing productivity and happiness, feels like the right step on the way to actually managing all our communication in one place.
p.s. You can try this yourself, here: https://sameroom.io/attend.