When Campaign Monitor launched, the customer support team was just Dave, one of our two founders. It's easy to know all the answers when you designed the whole product yourself!
In the years since then Campaign Monitor has added a whole lot of functionality and our customer base has grown dramatically. There's no down time when people are using Campaign Monitor every day all over the world.
So our support team are similarly spread out; Australia, England, Ireland, Canada and the US at the moment. We always want to provide you with accurate and timely support no matter what time zone you live in, but as the team and the application grow that becomes much more complicated.
I wanted to share with you some of the systems we use to make our support team as consistent and effective as possible.
Great customer service is a combination of attitude, skills and knowledge. Being friendly and helpful is essential, but not sufficient if you don't give the right answer.
When Campaign Monitor was fairly new it was easier to understand it all at once. Our veteran support team members were able to learn the whole system, and then just add on additional knowledge with each new release. Each support person also had a pretty good idea of what questions customers asked, because they’d seen big chunk of the tickets personally.
As the product grew it became much harder to understand everything up front, and that made every new team member slower to get started. Hiring highly skilled people for our support team is one way we address that; finding web designers, graphic designers and developers who are looking for a change of role.
People who can bring a lot of past technical experience to bear on a new problem can get up to speed reasonably quickly. We still do that now, but we're also aware that we we’re missing out on hiring those amazing customer service focused people from other backgrounds.
Over the past year or so, we've tackled this challenge with several different approaches. The one I'd like to talk about today is our internal knowledge base; we call it Yoda (please don't sue us Disney!).
If you've worked in a very small team you know how easy it is to find information. You just ask the developer who worked on that section to tell you what they did, or ask the one customer service person what was the problem last time this error showed up.
As the team grows, that becomes harder and harder. Information is splintered into tons of wiki posts, chat rooms, private messages, emails and tens of different brains.
We developed Yoda in-house as the one-true-repository-of knowledge to pull it all back together again in way that’s easy to use and to extend. Significant time was spent on this project by our design and development teams, an investment in customer service that I know from prior experience is not always a well funded area of a business!
Every team member has access to Yoda from our internal dashboard, so links to Yoda documents and searches can be easily shared and referenced. Here are a few of the design decisions that make Yoda work for us.
In support we have set up custom searches in Chrome so we can search the knowledge base directly from our browser.
The search results return both public help documents and private internal notes. It's visually very obvious whether the document you are reading is public or private.
Rather than explaining concepts twice, Yoda is layered right over our public help documents. When you are searching or browsing from Yoda you see the public view, plus additional details meant for internal staff.
For example, on a help document about bounces our team members can also see information about how to investigate bounce issues, and where to find useful tools.
So with one search they can learn about the feature itself (if they are inexperienced in that area) and also get the benefit of all the internal knowledge related to that topic.
Yoda is based on a stripped back editor that makes it very quick and easy for any team member to add or edit knowledge. It does just what we need and nothing more.
To add something to Yoda you don't need to know HTML, read a style guide or go through "a publishing workflow". You find the right page (or make a new one), type your text, drag and drop your images and hit save.
Sometimes the trickiest part of a knowledge base is deciding what should be added, and in what order. When you know that Yoda is there as a storehouse it's much easier to hold onto knowledge.
It's used for everything, from the most basic "what is our policy on ebay stores" to the "what happens if it's a full moon and the email campaign is sent to Lotus Notes, but it's a leap year" edge cases.
If you find out something new, you add it to Yoda, and now everybody else can find it too, without having to pull anyone away from their work.
Our public help documents are pretty comprehensive, but they can never cover everything. So to help us decide where the help can be improved, and in what order, we have another tab in Yoda called "User searches".
This tool does two things. It keeps track of what customers have searched for in our help section, and it also monitors those customers for a few minutes after they search, to see whether they then go on to contact support.
If a customer searches and gets a few matching results but then still decides to email our support team, that's a pretty decent indication that the help document didn't answer their question.
In the user searches tab, Carlee our technical writer can see over any given period which searches consistently end in a support request. She can click through to see the actual support tickets attached to those searches too, which helps her decide if it was a missing help document, a problem with accuracy, detail or wording, or if it was really an unrelated question.
One lesson that we quickly learned is that people most often search with just one or two words, so if they don't happen to use the same term our help document uses they might not get an answer.
We can use that information to naturally add synonyms to help documents to increase the chance of the right topic showing up.
The user searches section also keeps track of successful searches, where the customer searches, gets results and then doesn't need to ask us for help. By comparing the number of successful searches to the number of unsuccessful searches we can get a good idea of how effective our help documentation is over time.
We can also measure the impact of help document additions and improvements through improvements in successful search numbers and reductions in support tickets about those issues.
Introducing Yoda has had an immediate impact on our support. The kind of information that we'd discovered, lost, had to investigate again and then forgotten is now kept for easy reference.
Our more experienced support team members are shifting away from hoarding their own text files and evernote databases of useful information and putting it all into Yoda where the whole team benefits.
The biggest impact is on the speed that new team members can become productive. Our reporting shows that the latest group of support team hires have been about 30% more productive in their first few months compared to the pre-Yoda group (as measured by ticket activity).
When looking at customer help searches, we've improved the percentage of successful searches from just under 90% to 95% since we started graphing them.
Now Yoda is not the only improvement we've made in support, so it can't take all the credit. We can clearly see that it has made a difference to confidence and speed of information retrieval, and that has translated into better customer service for you all.
We've got more improvements to Yoda coming down the pipeline too that will make it easier for our team to see what is new and to encourage even more sharing of information.
Next time you need to ask our support team for help, you'll know that Yoda is helping you too!
Sign up for free.
Then send campaigns for as little as $9/month