Your First Support Model
I’m starting a series on support systems. While the domain will be customer support, it will also be an introduction to systems. I hope you enjoy it.
The next post in this series is Modeling the Support System.
Maybe I have weird interests, but I find it fun to imagine what it’s like to begin a job as the first customer support person for a small start-up. I mean, this sort of thing must be happening all the time. New products and companies are being started every single day, and as the founding teams grind away trying to find product/market fit, they’ll slowly start acquiring customers, and those customers will have questions and find bugs, which means they’ll send an email to the company asking for help.
In the early days, the founding team will figure out ways to stay on top of the inbox on their own. “We want to stay close to the customer”, they’ll add, because of course that’s what you do when you’re small and everyone is wearing all the hats.
Eventually, the inbox will grow at a rate that’s faster than the team can handle without occasionally being painful, either because they’ve started focusing their attention on other areas, or maybe just because the number of emails is piling up faster due to a bunch of new customers (good problems!). It’s at this point that the team decides to make its first support hire.
In another newsletter for another day, I would spend a good bit of time trying to convince you that this first support hire should be strategic, that you want them to have a good bit of experience so they can build a robust system that can grow to continue supporting customers with high customer and employee satisfaction as the company matures. But that’s for a different day. Let’s pretend that the founders decide instead to “get someone to do support” so they can get back to focusing on founder-y things. What is that person going to do and what does their support model look like?
Photo by KOBU Agency on Unsplash
Scoping the Support Role
Let’s imagine you’re the one who gets the job. If it’s your first foray into customer support, how are you going to approach your new job for this small but growing start-up? You’ll probably sit down with the founders and they’ll tell you how every customer is very important, how the quality of your email responses really matter, and how nice it is to get a timely reply if you’re a customer. You might find yourself discussing other things too, like keeping an eye on Twitter and maybe helping out with documentation, but the real need, at least at first, is staying on top of the inbox.
What does “staying on top of the inbox” really mean? For most small teams, it means trying to get to inbox zero by the end of the day, which means every customer has received a response. It takes a while to get up to speed, so early on inbox zero may arrive late in the day, but once you understand the product and the common patterns that show up in customer support, you’ll notice you start hitting inbox zero earlier and earlier every day.
At some point, inbox zero starts to get harder to attain again. It’s not because your skills have atrophied—quite the opposite, you’re a fully functioning support machine—but rather because volume is picking up. Either there are more customers or more bugs, but whatever the reason, there are more tickets and it’s harder to keep up. What do you do next?
The Basic Support Model
This is where your first support model comes into play. You could go to the founders and say “I’m really busy—can we hire someone?”, which, you have a valid feeling! But we also want to find the data that points to the cause of the feeling, namely, that ticket volume is approaching the threshold of how much you can reasonably handle in a day without getting burned out.
There are of course lots of different ways you can model support, but I’m going to start by keeping it super basic. In this model, you need two inputs and one calculated variable:
Tickets per Day - About how many tickets are arriving per day on average?
Tickets per Agent - If you’re solo, this is you. Look back at the days where you were most dialed in without getting burned out. About how many tickets did you get to?
# Agents Needed - This is calculated by dividing the number of Tickets per Day by the number of Tickets per Agent.
Visicalc
Although this seems (and is) super basic, it’s necessary. If you as the first support hire are spending so much time in the queue that you don’t stop to think about how the support system will grow, you could end up getting close to burn out before you’re ready to expand the team, and at that point, it might be too late. Factor in time for some extra-queue-rricular work so you can build your support model.
The number of agents needed should at the very least tell a story of how close you’re getting to hiring the next support agent. It can all feel pretty fuzzy when the company is small and there is only one agent, but you have to start somewhere.
If you’ve read my post on why you should optimize for queue-based performance, you’ll recall that it begins with a story of a startup that has to hire three people to replace the first support person at the company who left¹. This could be seen as a failure to appropriately model support—the company didn’t realize how the inbox was growing and then their single support agent was getting burned out—but it’s also likely an example of failing to model correctly.
If your first support hire is a superstar who handles 150 tickets a day, but they work long hours and have no out-of-queue time, you need to identify that you have a broken model. For example, if you plug in “150” into your spreadsheet for Tickets per Agent, it should be obvious that’s unrealistic if you know they’re already burned out. Perhaps 60 tickets per day is more realistic, and coupled with productive out-of-queue time, that’s going to change your ratio and prompt you to hire much sooner (hopefully early enough to keep your superstar first support hire).
Evolving the model
The key takeaway in this post is not to create the perfect support model. Rather, it’s that you need to have a model. You have to create the time and space to understand the very most basic constraints in the support system so you can appropriately plan for the future.
In the coming weeks, we’ll explore the support model from several different angles, using spreadsheets when it makes sense, but also exploring support as a dynamic system that breaks out of the bounds of a basic spreadsheet model. Stay tuned!
The next post in this series is Modeling the Support System.
The story is actually an amalgamation of multiple real stories where founders had to hire multiple people to replace their original support hire who left. In at least two of the stories, they did in fact have to hire three people to replace the original person who left. Amazing.