Luis Hernandez joined Geckoboard as VP Customer Success in 2014. Here he shares his experience of building the Customer Success team (almost) from scratch and into a well-oiled machine.
Today, we deliver customers an average first reply time of around 100 minutes and our customer satisfaction score rarely dips below 96% (in fact you can see our live metrics here). But this hasn’t always been the case and it’s been a long hard slog to get there.
In the beginning, tickets were mounting up, customers sometimes had to wait days to get a response, and the team was constantly fighting fires rather than focusing on delivering great support to our customers.
As I look back on it now, I can see four clear phases of development in our Customer Success team, some significantly longer than others. In this article, I want to openly and honestly share how I approached each of them with a goal to help anyone in the same situations learn from our experiences.
Geckoboard’s worldwide Customer Success Team.
Phase 1: Getting my hands dirty firefighting
When I joined Geckoboard, we were fortunate enough to have a quickly growing customer base. But as a young company, we simply didn’t have the processes and people in place to help us cope with the ever-increasing number of questions and feedback from our users.
We would frequently work non-stop throughout the day to make just a small dent in our ticket backlog. Our average first response time was a little over 30 hours – a figure we would balk at today – and I would frequently need to call on members from other teams to help out.
If you’re working with a new CS team, as I was, you’re unlikely to have a deep understanding of the flow of tickets and processes in place. By doing the job myself for a while, I was able to:
- Understand processes that were in place and what new processes needed to be in place and documented.
- See first-hand the types of questions we were getting and the profile of people we would need to hire to best serve those user needs.
- Get a feel for general issues that wouldn’t have been surfaced by simply looking at the data.
When things appear to be in a bit of a muddle, it’s very tempting to start hiring and building processes. But jumping straight in can make things worse. My biggest learning has been that it’s vital to spend as long as it takes to assess the current situation and get context before taking any action.
Phase 2: Stepping back to investigate the data
I needed to take a step back and start investigating the data to build up a clearer picture of what was happening below the surface and create a way to measure the success of any changes made.
I began digging into our Zendesk metrics to figure out exactly what was preventing us from making headway on the backlog.
Two metrics stood out:
- The average number of tickets created per day over the past few months.
- The time of day tickets were being created over the past few months.
Seeing these next to each other was an epiphany. Far from being a constant barrage, which it felt like at the time, the average number of tickets created each hour varied massively and, crucially, peaked towards the end of the working day here in the UK where our Customer Support team were based.
Suddenly, our struggle to dent our ticket backlog made complete sense – we were working hard for six hours every day to process tickets only for our efforts to be canceled out by a spike of new tickets at the end of our day. Our slow responses often caused customers to follow up to see if their ticket was being processed, further adding to our backlog and demoralizing the team who desperately wanted to deliver a great service.
The numbers made it clear that we simply didn’t have the bandwidth to handle the volume of tickets we were receiving, particularly given that over 60% of our customers are in the US.
Two approaches came to mind:
- Make our ticket responses faster, more useful and friendly by expanding the team.
- Cover US business hours so we can serve our customer base on their terms, not ours.
With a clearly identified (and quantified) problem and obvious options for fixing it, it became incredibly easy to make a business case for investing in our Customer Support team, so much so that we started hiring straight away.
Phase 3: Hiring a distributed team to reduce First Response Time
After hiring Javier in London and documenting processes, we needed to make a decision on how to both expand the team and cover US business hours. This meant either introducing shifts in HQ or building a distributed team. We chose the latter because research suggests that shift work reduces productivity. It also contradicts an important cultural value of ours: “Prioritize health and family over work ALWAYS.”
I started the search for our first distributed team member thinking that our first remote hire would be West Coast US because:
- Most tickets were generated in the PST time zone.
- PST is 8 hours behind the UK with 1 or 2 hours overlap for team communication.
- It created 15 consecutive support hours each day, when 70% of our tickets were generated.
However, our first remote hire was Tamsen in Christchurch, New Zealand because her application was simply too good to dismiss. We could cover similar times just a day ahead, including Oceania where 10% of total tickets were created. We were lacking coverage on a Friday for US business hours but added some weekend coverage as her Monday started on our Sunday.
Ultimately, time coverage can be complicated. Originally, I restricted the search to certain locations but decided to leave it open and instead mentioned ideal parts of the world in the job spec. The more specific you are, the more likely you are to trade talent for location.
We Work Remotely has been a goldmine of talented distributed Customer Success applicants. When it comes to identifying the right people to work in a distributed team, I’ve learned to look for six key traits through our hiring process, which consists of interviews as well as a task to test for these traits:
- They can happily work independently, as not everyone will be online when they are.
- They value the flexibility of remote work and don’t suffer from loneliness.
- They can connect the dots and proactively seek information themselves because inevitably there will be gaps in information.
- They’re organized, as organized people rarely ask the same questions over again. That’s key when that person is halfway around the world, especially when you assume they already know something.
- They over-communicate, as they often won’t be there to fill in communication gaps.
- You trust them as you’re going to be partially blind to what they’re doing on a daily basis.
(Here’s how we determine trust levels in our hiring process.)
Collaboration tools like Slack, Zendesk, Clubhouse, Tettra, and Zoom have also made managing a distributed team much easier these days. I’ve also learned the value of weekly 1:1s; the need to empower, not punish when inevitable mistakes are made; and the importance of providing a high level of transparency to ensure the distributed team members have the knowledge they need to feel included.
Over the next few months, we began to build out our distributed team across many different time zones with Hariharan in India, Kev in Boston, and Jason in Hawaii. We could now provide near 24-hour ticket coverage around the world with a small but highly efficient team that reduced the First Response time to a more manageable level.
Phase 4: Fine tuning the machine
With First Response Time down, we could finally go beyond the ticket queue, working on some more proactive projects to increase efficiency and provide a higher level of support.
We knew some customers weren’t getting in touch with support because we weren’t available when and where they needed us. So we added a number of new channels for customers to submit support requests:
- Social Media: We used Zendesk’s Social Support Features to begin supporting customers via Facebook and Twitter.
- Chat: We’ve used Intercom both in our app and on certain pages of our Marketing Site (such as the pricing page) to offer support via chat. We also used Intercom to send behavioral messages during onboarding to provide a more tailored support experience during a free trial.
- Developer Community: We created our Developer Community for developers who were trying to build integrations with specific tools and Geckoboard.
Squashing Bugs Quickly
Bugs in the product will always account for a high proportion of tickets. This is why we built Team Tabasco. They’re a group of engineers focused solely on removing some of the more simple bugs quickly that would otherwise end up in the engineering queue and may take a while for our engineering team to react to. It’s a delightful experience for customers when bugs are taken care of quickly and also reduces the overall ticket volumes.
Optimizing Self-Service Support
We also hired Richard, who has a technical writing background to work on reducing support tickets through a better optimized self-service support experience. This has gone beyond writing articles to include improving the user experience of our Help Center.
While bots aren’t at a stage where they can replace Customer Success team members, they can take care of repetitive support queries that don’t need human intervention. We’ve been experimenting with a bot ourselves.
Summary: Don’t put the cart before the horse
My overarching lesson while building the Customer Success team is not to put the cart before the horse. By this I mean, don’t jump in and start building a team before you’ve got your hands dirty understanding the problems both in terms of doing the job and reviewing important customer success metrics. If you do, you risk building in the wrong direction.
It’s also easy to get distracted with the latest trends such as bots. But first, you need to meet your customers’ support expectations by building a team to deal with their support inquiries quickly and effectively. Only then should you be looking at tuning the machine in terms of efficiency and creating delightful customer experiences.
Want to start tracking your most important Customer Success metrics? Check out this example Customer Support TV dashboard for your office.
Or, give it a try by making your own live customer support metrics dashboard.