Great service doesn't require being a super hero

On May 1st, 2014 I gave a talk at the always excellent UserConf (now Elevate Summit) in Chicago. These are the notes and related resources to go along with that talk.

You can now watch the whole talk on video over at UserConf.

I was demoted from my first support team-lead role, and became a web designer for 7 years before I joined Campaign Monitor in 2006 (when the team was 4 people) becoming the first support team member.

In 2014 we have over 20 people in support, and we get some pretty great results (averaging 94%+ happy customers over more than 10,000 ratings)

This is the story of how we went from just me to 20+ people in support, and improved our customer service along the way.

It's also the story of the mistakes and pitfalls I hit along the way, and how the Wizard of Oz is more than just a classic movie.

Our Age of Heroes

Early in Campaign Monitor's history everybody did everything, because there were not the other options. We did a really good job in a scrambling sort of way.

I was working every day, because the queues were not too long but we always had more overseas customers than Australian.

I knew every customer who wrote in, and every issue because it was just me.

Early hiring

  • Finding highly independent, experienced people who we flew in, flooded with knowledge like an F1 petrol stop then sent home
  • Communication "just happened"
  • Hiring smart, over-qualified people was a useful shortcut for the first few years

First challenges

As we gathered more and more customers and the product became more complicated, our system for support was stretched.

I should have realised when HelpSpot stopped working (because I had too many resolved tickets) that we needed to do more strategic thinking about our support queues.

I was still doing a huge chunk of the direct support myself, and lots of product and customer knowledge was locked up in my head and in the heads of my team mates.

I loved being knowledgeable, and if I'm honest there's a sort of addiction to being important and swooping in to rescue a ticket with a knowledge bomb.

If I could go back in time now, I'd tell myself to get my head out of the queues earlier and make some of the changes that needed to happen.

Learning to let go

I bet a lot of people in small support teams are still in this phase, just keeping in front of the stone of Sysiphus where you solve a ticket and another one arrives forever.

I'd talk to my bosses about all the bigger picture improvements we wanted to make, how to reduce tickets and fix problems. We'd agree, I'd go back to my desk and there would be tickets to answer and it would be suddenly 6 months later.

Being on frontline support is like being a bear catching salmon in the river. You can get really, really good at catching them, but there are always more salmon.

You can keep adding bears but eventually the woods get pretty disgusting. So instead, you need to find a way to create enough time to get upstream where you can make smarter decisions about reducing the number of tickets, handling them more quickly and resolving problems.

It took me far longer than it should have to make the space to do all the things we knew needed to be done.

I tried a lot of different ways to make space and time to do that, but ultimately we just needed to add more people to create enough slack.

Some examples of what we were able to do once a few new people started.

  • Working with designers to tweak our pricing pages to clarify some confusing issues that generated a lot of questions
  • Changing some of our contact forms to request specific information that helped us respond more quickly
  • Writing summaries of product changes and sharing that regularly with the support team so they were not surprised by new features and updates
  • Documenting some of the information previously trapped in our brains

Letting go of individual support answers also meant not micro managing how tickets are answered, and trusting in my team.


As the team grew, our processes hit their limits. We tried:

  • wikis
  • ad hoc emails
  • Unstructured meetings
  • Chat rooms

With varying degrees of consistency and success. Information would be lost, or confused.

Growing pains

This is the modern era for our support team. We are 20+ people now and the systems and processes that worked for 5 people are just not good enough any more.

My role has expanded and I no longer try to be the best or the fastest at answering tickets.

  • Be a multiplier - small improvements across 5 or 10 or 20 people add up very quickly
  • Really work hard at communication. As you get bigger, it needs more deliberate effort to share information. This is especially true for Campaign Monitor where we have a mix of in-house and remote staff
  • Avoid the Rumsfeld effect for remote people. Unknown unknowns lead to fear and uncertainty

When you have smart people with access to great resources, you can spend more time keeping them engaged and happy in their roles.

Some of the ways we try to keep our team engaged:

  • Regular weekly emails that cover the big topics, but also the little bits of social information remote people can miss out on
  • Having full size cardboard cutouts of some remote team around the office
  • Our Directors calling out our support performance and the value to the company

Define success

When the team grew, hiring people just like me stopped being a handy shortcut and started being a limitation on our quality of service.

We decided to hire more broadly, but as it turned out we weren't quite ready for it. Hiring people with different backgrounds was great, but we didn't have a clear idea of what skills and abilities were really critical, and which could be learned.

We also didn't have a training structure to build up all the knowledge we'd previously assumed people to have. So a few new people had a much harder time becoming productive, and it impacted the rest of the team who had to help them up.

More recently we have created a clear, detailed document called "How to Succeed in the Campaign Monitor Customer Service team" which covers things like:

  • What can be measured?
  • What are our attitudes?
  • How do we work with other teams?
  • How do we contribute to our team?

Reading it, a new support person knows what they are expected to get done, and how they are expected to behave as part of the team.

The same document is a useful interview guide and a ruler for measuing performance during reviews.

Customer service isn't cool

It's just not, and we do a disservice by pretending it is. Cool people often aren't the ones who are empathetic or who want to try to help.

So even though I understand why companies use titles like

  • Customer hero
  • Ticket champion
  • Wow magician
  • Email whisperer

But to me, it seems to be placing the emphasis on the wrong person. Customer service isn't rocket science, and we all at UserConf know what we need to do.

If you are saying being a hero is what you need to do to provide good service, something is wrong.

Heroes can get the job done, but they tend to trash everything else. Heroes in the support team may make one customer really happy but the next day the same person might get a mediocre experience.

There are customer service heroes, but they aren't us. They are the people who somehow manage to provide great service inside banks and insurance companies where they have no authority, no information, no control and no respect.

That's heroic. But that's not sustainable or desirable. The model we use at Campaign Monitor is not The Avengers, it's the Wizard of Oz.

Wizard of Oz support

Sometimes we get some effusive feedback for our team saying how we've gone above and beyond for them, and provided amazing service.

When I look at the ticket, sometimes it's literally a 30 second job for the customer service agent. We'v just given our team the tools to do it, and the authority to make it happen quickly.

So in Wizard of Oz Dorothy and her friends thought he wizard sounded impressive and powerful. But it turns out he just had access to a cool machine and his part of the job was easy.

That's our goal in support; make it so great service is as much as possible an automatic outcome from the whole company, and not something that takes heroic effort.

What that looks like in practise:

  • Push authority for decision making down to the front line. Don't make people ask for permission to refund or to bend a rule.
  • Give them tools and information to make better decisions, and back them up on it.
  • Create processes that are customer friendly and automate them so that no decision needs to be made.

For my team, we have a whole bunch of systems supporting them.

  • Written clear accessible guides for how to handle certain situations
  • Added a Status page that intercepts a lot of questions before the customer needs to contact us
  • Hire a tech writer who is constantly updating our help to answer common questions that crop up in support
  • Built an internal knowledge base that combines our public help and our internal knowledge into one fast, editable and current tool
  • Created "DQ" time to let our support team work on things other than direct customer support
  • Created "kill that question" and "cringe list" pages that draw out the frustrations from our front line team and try to address them
  • Built a custom front end to ugly JIRA to track feature requests in a couple of clicks
  • Written training courses to reduce the time to competence for new people
  • Expanded our 2nd level support team of engineers who feel the customer pain and can make changes and build tools to address it
  • Created simple checklists of what a great response looks like, for new people and as a safety fallback

So Tina Turner said it best: We don't need another hero.

What we need is to get the rest of our companies being truly customer focused, and then let our support teams get on with doing their job.