This is the first in a three part series looking at how we manage Twitter as a support channel. In the parts 2 and 3, I’ll discuss some of the finer points of how we sort through hundreds of tweets each day to get people answers quickly.

Since the launch of the new Basecamp back in March, we’ve been encouraging the use of Twitter as a support channel. On our help form we encourage people with simple questions to use Twitter rather than sending an email, and we monitor mentions of 37signals throughout the day. We’ve always gotten support requests via Twitter and answered them, but it’s only this year that we’ve actively encouraged and focused on it.
Our Twitter presence has grown substantially: in October of this year, 37signals was mentioned an average of 443 times every weekday, roughly double what it was in October 2011. Not all of these need an immediate reply from our support team – many are people sharing links or things that they found interesting. The 60 or so replies we do send a day in response to immediate support requests represent a little less than 10% of our total support “interactions”.
One of the things I spend part of my time working on is how to improve the speed and quality of the responses that we provide to customers, and part of that involves providing advice on the best tools and processes for the support team to do their job. As far as Twitter goes, the biggest pain point is the actual tool used to monitor and send tweets.

The search for a Twitter tool

Since we got serious about Twitter, we’ve mostly used the built in Twitter functionality that our support tool (Desk.com) provides. When I asked the team how it was working for them a couple months ago, the general reaction was tepid. The consensus was that while it gets the job done, it was rather slow to use, and the large number of retweets and links to SvN posts mixed in makes it hard to get people with urgent questions answers promptly. Most of the team was using it, but no one was happy about it.
What did we want in a tool?

  • Pull in tweets by search term, including negative terms / filters.
  • Track which person actually sent a reply, even though they all come from @37signals.
  • Provide some marker of what tweets are new vs. resolved.
  • Preserve threading and show conversation history.
  • Find email support cases by the customer.
  • Have keyboard shortcuts, a responsive interface, and background updating.

We didn’t find anything that was quite what we wanted, so we scratched our itch. With a few hours of work, our internal dashboard application now sports a new section that acts as an optimized Twitter client tailored to our particular workflow.
It’s very simple – an infinite scrolling list of all Tweets that mention 37signals from newest to oldest. Tweets that have been resolved are shown grayed out, and can be completely filtered out if you want.
You can reply to a tweet, retweet it, share it to Campfire, or mark it as resolved. Once you reply to a tweet, that reply shows up in the history, so we always know who replied. There are keyboard shortcuts to move up and down through the list of unresolved tweets. When new tweets come in a counter in the page title keeps up, so it’s easy to see if there’s a new tweet waiting for you while you work in another tab.
While we usually only have one person working on tweets at a time, if you happen to be looking at the page while someone else is working on it, you’ll see their updates happen in realtime.
This started as a quick experiment—what would a Twitter client tailored to our own use cases look like? So far, it’s been more successful than I imagined – the team is happy, and we’ve been running a median response time for tweets of about 7 minutes since launching.
As with any piece of software, this isn’t perfect. In the next part, I’ll talk about addressing one of the biggest warts: tweets that don’t need an immediate response clutter things up and slow our responses to those that do need an immediate reply.