You’ve seen it. The red eyes… An ennui for life…
The drained sadness of someone who has been lost for weeks in a customer support ticket tracking system.
At mySociety (the awesome Internet democracy charity I was on the founding team of) we tried using Request Tracker for a while, and quickly fled.
We could flee, because we had the comfort of a simple email based system to return to.
It worked like this:
a) All support or feedback email comes in to a particular address (we used team@ – for example team@theyworkforyou.com for the site TheyWorkForYou)
b) That address is set up as an alias (like a group in Google Apps) to transparently forward mail to everyone working on that product.
c) Everyone filters their email, so those support emails all go into a special support folder.
d) When replying to customers, always use reply to all. This is so replies go into everyone else’s support folder, both so they have a record, and so they know the customer has been replied to.
e) When either you or someone else have fully dealt with a mail or a thread, archive it. Otherwise, leave it in the support folder.
f) Be really disciplined about this. Anything in the support folder represents a customer who isn’t satisified.
g) Make sure at least one person on the team goes and looks at slightly older, harder messages, and bullies appropriate people into resolving them one way or the other.
This particularly works well early on in a product, when there is relatively little support. It’s particularly important then that everyone working on the product lives and breathes the customers. Even just seeing the emails go past with other people answering them can help with that.
I’ve used it to manage support for probably a dozen web products in total. It’s surprisingly robust…
It worked well (and still does as far as I know!) with half a dozen volunteers on WhatDoTheyKnow. It worked fine even when we were launching the Downing Street petitions system, with millions of users and front page newspaper stories (Matthew had many long sessions of email answering – and that’s a good thing!). We’ve just been looking at customer support systems for ScraperWiki, the startup that I run.
The main products (like ZenDesk) seem to be aimed, both in price and functionality, at larger, more corporate organisations than we are. They look overly complicated, we really only need something as featured as the Github Issues tracker.
I don’t know what we’ll move to using yet – that’s partly why I’m writing up a description of mySociety’s email based system.
It could perhaps be simplified by using a shared GMail account. Careful use of labels and folders would also make it more powerful.
It would need some training and discipline. Everyone handles their personal email differently. When it is customer support requests, it needs more discipline than just chilling out in the tao of a flow of passing messages.
This is natural to people who have the horrible habit of using email as a todo list, less so to anyone else.
Comments please! What questions do you have about the above system?
And can you recommend a lightweight customer support tracker?
We use rt [1] over here at the physics department. Looks open source. Being on the requesting end, it has worked well enough. I don’t know what it is like on the receive end.
My other experience is with the issue tracker CERN uses [2], but that looks enterprisy and expensive, so probably not what you’re looking for.
Re: your usage of e-mail as a ticketing machine (which I like, because I’m one of those people with the horrible habit of using e-mail as a TODO tracker), I don’t understand how “archiving” gets propagated between independent users. Is that a feature of google apps or something? Is there something shared about this mailbox that I’m missing?
[1] http://www.bestpractical.com/rt/
[2] http://www.servicenow.com/
I use a similar system at work and when freelancing, which is basically:
1. Anything in my inbox represents an item which requires a response, or where I am waiting for a reply (and will chase if I don’t get one). New emails go into my inbox automatically so there is no filtering required.
2. Once an email chain is ‘complete’, I move it to an archived folder (different folders for different projects, so I can find them again if need be).
3. If an incoming mail relates to a non-urgent task, it gets moved to a Postponed folder, which I check a couple of times a week and either move emails back into inbox if they are now urgent (or I have time to deal with them) or into an archived folder if they are no longer relevant.
I’m not sure how well this would scale, but it has two huge advantages:
1. Non-technical people know how to use email (most of the time), whereas they don’t know how to use fancy ticketing systems.
2. Email is a tried and tested technology. I don’t have to worry about updating a PHP bug tracker every two weeks when there is a security release (or getting compromised because there hasn’t been one), nor do I have to write any fancy queries to work out what my current todo list is.
Peter – the archiving doesn’t get propagated between independent users. Everyone has to archive every thread.
This is less of a pain than it sounds. My hunch is that if it really was a pain, having a truly shared support inbox (e.g. using a GMail account for the purpose) would fix it.
Paul – your “postponed” folder is a nice idea. I have things sitting about for too long in my inbox.
(I’m one of the people currently using this system for team@whatdotheyknow.com email)
We use this system at my work as well, using a shared mailbox, and it also works ok for a fairly small group (~20 people).
I don’t think it scales much beyond that, though.
I haven’t actually got round to setting up an archive folder for WDTK, and it hasn’t hurt too much. Generally I assume that threads with a reply are ok and threads without a reply need action, which is not 100% accurate but good enough.
I think there would actually be significant benefits from a from a good tracking system in our workflow, but certainly not a generic system like RT – it would need to be properly integrated with the site. The lists of todo items we already have in the admin interface (“incoming misaddressed email”, “outgoing delivery errors” etc) are examples of this kind of thing and there’s scope to expand that, e.g. complaints about miscategorised requests, authority email addresses etc.
We use a similar system (almost exclusively handling tickets via emails) but it’s underpinned by Freshdesh. We’re thrilled with it as a system and for us, it was a far more appropriate solution than Zendesk/Zohodesk/Comm100 (all of which we experimented with first).
For ongoing conversation with users, a “Redirect/Bounce” facility in your email client is invaluable.
Even if you CC your inital response to the team@ address, people inevitably reply to only you personally, so the other team members won’t see the whole conversation.
Merely forwarding a message to the team@ address doesn’t preserve the threading, and introduces other cruft into the conversation.
A better solution is to instead redirect such replies, so everyone on team@ gets it and can jump in if needed. Message threading is preserved and it’s all lovely.
Thunderbird has a great extension for redirecting:
https://addons.mozilla.org/en-US/thunderbird/addon/mailredirect/
(not sure about any other email clients)
We use (and thoroughly recommend) SupportFu. It is very light touch – basically gives you a nice back end interface to what is otherwise your Google Alias scheme. Still on ‘early bird’ pricing so not as expensive or corporate or product-bloated as the rest. Lets’ you get on with actually doing support, rather than living inside another software system. http://www.supportfu.com