When you talk to our support team at Pingdom, you’re talking to real people who listen. Tech support is an often discussed matter, and to us it’s one of the most important parts of our company. It provides us with incredibly valuable suggestions, requests, and bug reports. Switching the support system for more than 700,000 users is a little bit like performing heart surgery – on a running patient. At least you know it will be interesting.
Why did we need to change?
Back when Pingdom was starting out, the support was run directly from the Gmail inbox we all love and hate. But the user base grew rapidly and a real support tool was needed, and a self hosted solution that shall remain nameless was implemented. And before you say anything, yes, sometimes in life you make mistakes, and if nothing else, those mistakes make good stories.
The solution we chose was something we somehow learned to live with for a couple of years. But it was a life riddled with solutions like “oh you want to do that? Well, hold down two keys, spin your chair, and if Jupiter aligns with Mars you click on the third link.”
There really should be a warning label saying “he who implement will inevitably lament”.
As the saying goes “if it ain’t broke, don’t fix it”, well, this thing was broken.
We had no ability to automate workflows, we couldn’t track data on which of our customers connected with us. Most important of all, we couldn’t get any type of data on the most common issues and break this down over customer type or agent time spent. And as a bonus the customer facing FAQ site required SQL knowledge to search.
While the list of things we wanted in a new solution could go on for several pages the basics were simple.
Our need-to-have list:
- Be browser and cloud based, to avoid upsetting our DevOps-team and allow agents to choose their own OS.
- Have a single place for all incoming requests (email, ticket form, phone, Twitter and Facebook) to avoid agents having to switch between different systems based on the requests.
- Satisfaction surveys.
- Categorize and time tickets.
The nice-to-have list included things such as:
- An easily updatable help center/FAQ page.
- Custom domain to let us use our own domain to direct people to support.
- Ticket history for our customers.
- Integrations to other tools used in the company (JIRA, Slack/HipChat/Sprout Social).
After some weeks investigating the clear winner was Zendesk. On top of meeting the minimum requirements it also included everything on the nice-to-have list and even more stuff that we hadn’t included at all, such as an ability for using markdown and macros to more or less have one-click solutions on tickets. This was something previously done with various auto-complete apps everyone had installed on their respective computers.
Such macros or “canned” responses are generally frowned upon, and we don’t like any more than a customer does. They can be incredibly useful for a couple of cases though:
- Simple questions that have simple answers.
- When something goes wrong that affects a large number of customers and the answer is the same for all.
How does a change like this happen at Pingdom?
The switchover was easy enough. During the free trial we tested various scenarios, set things up to look the way we wanted and tested the reporting capabilities internally. We also set up the self service help center and put it on the brand new domain help.pingdom.com.
On the day of going live we made final preparations, made sure links worked in the help center and that spelling errors where at a minimum. It was easy enough to go live: we changed the automatic “Ticket receive email” to a new one informing customers that we had a new system in place so please check out the help center on https://help.pingdom.com, and let us know if anything looked strange.
All “old” tickets would be automatically added in Zendesk instead when customers replied to them, and there was no need to migrate any ongoing tickets as we had none at the time.
The result
In accordance with Murphy’s Law, of course, we had missed a space in an email, but a helpful customer pointed that out and after that it was just smooth sailing.
An example what we can do with this shiny new support system presented itself recently. And we’re willing to permanently cement that by writing about it, because we’re self-aware like that.
Tweeting is a great way of communicating things like this, but not all our customers follow us so we had some 50+ worried people contact us and we needed to answer them in bulk and quickly.
All we needed was a macro that tagged the ticket accordingly and gave a proper answer while addressing the customer contacting us in a somewhat personal way. Creating it took no more than two minutes and the process looks like this:
The setup just defines all the ticket properties, set the ticket to Solved, make sure the person contacting us doesn’t receive a satisfaction survey (in this case just because they received enough emails from us) and add a tag to easily identify the issue for reporting purposes.
The result is then this:
And just like that, using the built in markdown, we could easily explain the situation, calm our customers down and get back to work on other questions and issues. When a new ticket came in about it the response could be given in seconds.
What’s next?
With all this data our support team is aware of all common issues and questions, and we can properly inform our DevOps teams of what customers pain points are and have a valuable part in future development.
In the long run data like this helps us build a better product and makes our customers, support and DevOps team happier.
The next big leap is to start a Pingdom community hosted directly in our help center. We thought this would be a great place for discussion about our products and a place to keep feature requests in a transparent way.
