Yesterday David and I met with Sarah and Michael for a bit to get an update on how customer support/service is going. We recently switched from using Gmail to HelpSpot and we were curious how the transition felt. Basically, how was the workflow and were we learning anything?
Why the switch?
One of the reasons we switched to HelpSpot was so we could do a better job tracking which requests and issues were top requests. Sometimes support will say “People have been having a hard time uploading files this week” but it’s hard to know what “people” means. Is it two people? 10 people? Dozens? If we made changes to the app, would we reduce support demands and customer frustration? Gmail couldn’t really give us specifics, and HelpSpot could, so we switched to HelpSpot.
Knowing but not learning
In our review yesterday we discovered that were were tracking everything in detail, but not really learning anything. Why? We were tracking for the sake of tracking, not tracking for the sake of learning. We weren’t really sure why we were tracking what we were — but we kept on doing it because, well, momentum is a powerful force. It became an exercise in seeing how organized we could get in spite of what we actually needed.
Our extensive use of categories and tags and custom fields and pulldowns could give us a whole lot of report-friendly information, but it didn’t give us any useful information. Information without insight is junk. That’s what we had. Plenty of it.
Going back to simple
So yesterday we decided to change everything. Let’s point the ship towards simple. Every mistake we’ve made as a company has been because we tried to do too much, not because we didn’t do enough. So let’s apply that lesson to how we track support requests too.
What really mattered?
Instead of neatly categorizing every request, we’d just roughly categorize them. So instead of multi-level categorizing like “Milestones > Editing > How to move milestones between projects” we’d just track the “How do move milestones between projects” part. The “Milestones” and “Editing” categories didn’t matter. We didn’t need the hierarchy or extensive organization. All that mattered was the bottom line: The question/issue.
Basically as questions/issues came in, we’d create new long tags that paraphrased the question/issue. And whenever another question/issue came in that was roughly the same as the paraphrased question, we’d tag the actual question with the paraphrased question. This way we could get a count on these paraphrased questions and see how many people were basically asking “how can I update my password” or “how do I move information between projects?”.
We could run a report that would simply give us the top 10 questions this week. Are they the same as last week’s top 10? Are we seeing a pattern? What’s up? What’s down? Now we have specifics that we can act on. In the past we’d know there were 60 questions in the “milestones” tag, but that doesn’t really give us anything to act on. But now we’d know there were 23 questions about “How do I add more than 10 milestones at a time”, 21 about “Can I move milestones between projects?”, and 16 about “Can I add times to milestones?”. Now we’ve learned something.
Obvious isn’t always obvious
Looking back at this it seems obvious. We should have done this from the start. But like many things, it’s easy to get carried away. This new tool gave us all sorts of tracking options. Categories, tags, custom fields, lookups, etc… So we got excited and confused enthusiasm with priority. We did a lot of busy work but didn’t learn anything.
So just a reminder: Know what you’re measuring. Data for the sake of data can be a fun intellectual exercise, but practicality is usually what you’re after.
Ian Landsman
on 16 Jun 09Hey, that sounds great.
The way you’ve got it setup now is much closer to how we actually use the tool ourselves and I think you’ll like the results.
As always, if we can be of any assistance please let me know.
D Goetz
on 16 Jun 09Couldn’t agree more with your comments about having enough data, but not too much, to be actionable.
With your new understanding of the needs, would gmail now work for the tracking?
Scott Semple
on 16 Jun 09How do you move milestones between projects?
I didn’t know you could.
zephyr
on 16 Jun 09Awesome post, highly quotable!
JF
on 16 Jun 09@Scott You can’t right now.
JF
on 16 Jun 09With your new understanding of the needs, would gmail now work for the tracking?
Unlikely since it doesn’t do counts or produce reports over time.
Plus, this was just one of the reasons we switched to HelpSpot. Gmail is a single-user app which starts to break down when you have two or more people answering email at once.
pwb
on 16 Jun 09Will be interesting to see if Google (or someone else; maybe they open Gmail Labs to outside development) adds some features to Gmail to make it more suitable for customer support.
Sean
on 17 Jun 09@JF You may have already mentioned this, but what ended up making up your mind to switch to HelpSpot as opposed to ZenDesk or Tender?
Enrico Foschi
on 17 Jun 09Jason, looks like you adopted the same approach as you did in Basecamp feature development: http://gettingreal.37signals.com/ch05_Forget_Feature_Requests.php
As it worked for organizing feature requests, I guess it will work for organizing customer support :)
Enrico
Kevin Chan
on 17 Jun 09I have used a really detailed ticketing system with Entellium previously. I was thrown back at the features that were available to me. The workflow itself was suffocating enough, that you need to perform an action to trigger another action.
Sure I questioned the necessity of it, and the general consensus was, “Yes, it is important for tracking!” I even had customers demanding more tracking capabilities, when it had so many to begin with.
I will definitely try out the approach that you have suggested, and look at data and tracking differently from now on.
Nate Abele
on 17 Jun 09Wait, wait… you had a meeting?
;-)
Greg DeVore
on 17 Jun 09We actually do a similar thing, but create a tutorial instantly that shows how to “solve” the issue or answers the question. It gets added to our repository. Then whenever a similar question comes in we just send the customer a link to the answer.
Repository is searchable so our knowledge base grows over time with real answers to actual questions. We don’t waste time creating content our customers don’t actually need.
I blogged about it here: http://bluemangolearning.com/blog/2009/02/plan-to-not-plan/
Dougie Fresh
on 17 Jun 09Great insight into the decision.
Martial
on 22 Jun 09“At its best, measurement closes the loop, auditing and assessing what the organization is doing, thereby ensuring that the firm does what it knows.“
The sixth and strongest point about “Measurement That Turns Knowledge into Action” from Sutton and Pfeffer’s The Knowing-Doing Gap: How Smart Companies Turn Knowledge into Action. I recommend the whole book.
I also recommend Sutton’s blog for evidence-based business wisdom. http://bobsutton.typepad.com/
This discussion is closed.