2026/02/03

It feels a little odd to be writing about scaling support as if from a position of authority. But I had two recent conversations around the same topic—going from a state where support was largely confinable to a single person’s Gmail to a place where it wasn’t—and all of the messy things that arise from that transition.

And so I figured I would write down some of the best practices that I have settled on (or rather, been thrust upon me) in order to not forget them, and to have a blog post I can point people to. This is meant to be an essay for folks who find themselves hitting the same pain points that I and many others have:

1. A constant state of emotional strain and fatigue that never goes away regardless of how much time you spend working on support.
2. A sense that things are very disorganized even though everyone is trying very hard to help.
3. A perceived inability to move forward on known important and urgent work because all of your team’s cycles are spent dealing with reactive support issues.

The target audience here is someone at a company with greater than one but fewer than five people "doing support," whatever doing support means to them. That being said! I think a lot of what I talk about here is actionable for folks who aren’t quite there yet but want to start building better processes in anticipation. To a certain extent, this post will also be a catalog of the things I wish we did earlier than when we ended up doing them.

Use the right tool.

This is probably obvious, but the sooner you get tickets out of Gmail and into a specialized tool, the easier it is to start thinking about things in a structured and process-oriented way. No context or messaging is trapped in one person’s personal inbox. Almost every tool lets you have aliases, so this doesn’t even have to be a user-facing change.

Start a rotation.

A common failure case when scaling support looks something like this: everyone is good-natured and wants to help out with support and does so in a very half-baked and fairly haphazard way. Lack of tooling and standardization means that the state for a given ticket or thread is in one person’s head, by virtue of them being who happened to respond when it came in. You fast forward a quarter, and you have ten tickets in five different states of limbo, with the only way to get context being to track down whoever was last in the thread.

This is analogous to having an engineer say they’re going to go into a hole and work on a feature for a few weeks without any process or updates around it. Sometimes that’s the most efficient move, but most other times—increasingly as time goes on—it is worth sacrificing a little bit of theoretical efficiency for legibility and standardization.

That’s fun to say, but fairly abstract. What do you actually need? For starters, your team needs to define what the support workflow looks like, much the same way they standardize on what engineering workflow looks like.

The goal of the person on the support rotation is not to resolve underlying issues, but to keep the inbox clean. This can be decomposed into three responsibilities:

1. Timely and helpful responses.
2. Fixing shorter issues and cataloging larger ones so they can be triaged against the existing backlog.
3. Making it easier to do steps one and two.

It is very easy for an engineer doing support to look at a bug, think they can solve it, and then spend an entire afternoon chasing down blind alleys. That work needs to be prioritized against everything else—and the place for that prioritization is probably not in the support rotation person’s head on a random Tuesday.

Similarly, state about the ticket or bug needs to be in a common place. The simplest answer here is either within the ticket itself or within your issue tracking software (Linear, in our case).

Invest in tooling.

A useful mental model is to assume that at some point you’ll want to hire a dedicated support person who may be technical but won’t be as technical as you. Approach all of your tooling and documentation with that in mind. Your job is to replace yourself in due time.

Almost every ticketing platform is extremely friendly to quick duct-tape tooling. It lets you inject context, links, and widgets into the thread view. If yours doesn’t, you should immediately churn onto one that does. I recommend Help Scout, not because I think it’s the best overall tool, but because it’s at least one that lets you do this very easily.

You should, in general, treat it as a failure case if you have to tab away from a thread to look up material about a user or situation. And in general, as you’re doing support, ask yourself: what tiny little tool would have made my job a little bit easier here? I emphasize tiny because I think people tend to underestimate the mental burden of so many lookups. Even just piping in billing information and saving yourself the effort of having to look up the customer in Stripe accretes very quickly over a hundred tickets in a week.

Invest in documentation.

You should treat every single email that you get as an implicit bug report against your docs in some way. (With the obnoxious proviso that a better product UX is one that is self-documented.)

Train yourself, even if it feels inefficient and even if you already know the answer, to look up the docs first before responding to a customer. This trains you to get a better sense of where documentation coverage is lacking. And, like all bugs, once you’ve finished it at the object level—add a regression test. Or at least file one. Bolster the docs.

I cannot emphasize this strongly enough: without investing in docs and UX improvements downstream of support, your support burden will only ever grow monotonically.

Measure the right things.

Support is, while onerous, a channel that lets you build better docs, processes, and products. The worst-case scenario is that you treat support as a satisficing function—do the bare minimum to get things across the line—only, like Sisyphus, to discover that that bare minimum increases monotonically as your business grows.

To that end, the most useful metric to think about is incremental support load per dollar of revenue, not support load over dollar. If your business doubles over a year, you’re going to have more tickets. That’s a good thing! What you want to be able to do is bend the curve such that support burden grows sublinearly relative to overall top line.

All of this is to say: support is not a pit you fall into. It’s a flywheel you build.

About the Author

I’m Justin Duke — a software engineer, writer, and founder. I currently work as the CEO of Buttondown, the best way to start and grow your newsletter, and as a partner at Third South Capital.

Colophon

You can view a markdown version of this post here.