Business practice
Support capacity planning.
Support team capacity planning for SaaS and AI companies: an honest read on which pressure on your queue is a staffing problem and which is a process problem, with capacity measured rather than estimated. You get a plan you can defend to your board before you open the role.
When the queue grows, the instinct is to hire, and sometimes that's right.
The problem is that a hire is the most expensive way to find out you were wrong. In SaaS Capital's 2026 benchmarks, median spend on customer support and customer success at private B2B SaaS companies is already 9% of ARR, up from 8% the year before. A new agent takes months to arrive and months to ramp, and if the pressure was coming from a process rather than from volume, they inherit the same broken week their teammates have.
So the question gets answered before you open the role. Capacity measured rather than guessed at, the pressure split into the part a fix absorbs and the part that genuinely needs a person, and a plan you can put in front of your board without being asked for evidence you don't have. Fix the queue first, then hire for what's left.
The approach
Three words we work by.
Measure.
Current capacity gets counted rather than estimated. Tickets per agent by type, handle time, how much of the week is recurring work, and how much is rework caused upstream, like reopened tickets and bugs routed to the wrong team. People are generally accurate about being busy and unreliable about where the time went, which is why this is measured.
Separate.
The pressure is split honestly. Some of it is real volume and needs a person. Some of it is a process that a fix absorbs, and hiring into it buys you a second person doing avoidable work. You get both numbers, and the second one is the one most teams have never measured.
Defend.
The plan is written to survive the questions your board or CFO will ask. What the role covers, what was tried first, what happens to first response time and cost to serve if it's approved, and what happens if it isn't. Evidence attached, so approval turns on the case rather than on conviction.
The work
Four workstreams, in sequence.
Capacity measurement
Where the hours in the affected team actually go, taken from your help desk and CRM data and a short structured look at the work rather than from a survey. Recurring work, exception handling and rework separated, because they lead to different answers.
Process and staffing split
The pressure divided into what a process fix absorbs and what needs a person. Each fix sized by the hours it returns and the effort to make it, so the comparison against a salary is like for like.
Role definition
Where a hire is genuinely the answer, the role written from the work it takes on: the tiers and ticket types it covers, the decisions it owns, who it relieves, and what has to be true within ninety days for it to have worked.
Board-ready plan
The case assembled as a short document: what was measured, what was tried, what's recommended, and what the numbers do either way. Built to be read by people who weren't in any of the conversations.
Related reading.
All insights
Operations
The two-person dependency test
Every SaaS company has them. Two people, sometimes one, who hold a process together through memory and habit. They're usually excellent, they're usually loyal, and they're usually the reason nobody has ever needed to write the process down.
Retention
The six questions that find churn before it finds you
Churn in a SaaS company almost never looks like a decision. It looks like a slow drop in contact, a QBR that keeps getting rescheduled, a champion who stops replying, and then a non-renewal notice that arrives as a surprise to everyone except the customer.
Questions
Asked before, answered plainly.
If the case is clear, it's a short exercise that puts evidence behind it, and it takes weeks rather than a quarter. Where it earns its place is the other outcome: finding that some of the pressure comes from a process, which changes the size of the role or the timing of it.
Mostly from systems you already have, like your help desk's ticket and handle time data, and from a structured look at the work with the team, not from a timesheet exercise. Where a short period of tracking is genuinely needed, we scope it tightly and say what it's for, because a tracking program nobody believes in produces numbers nobody believes.
Then that's the answer, and the plan says so with the evidence behind it. The exercise isn't built to talk you out of hiring. It's built so the number you take to your board is one you can defend when somebody asks how you got there.
It's a fair worry and worth addressing directly before it starts. This work usually starts because a team is overloaded, and it ends in one of two places: a hire, or the removal of work people already resent doing. We say that plainly to the people involved.
They answer different halves of the same question. This one tells you which pressure is a staffing problem and which isn't. Where the answer is process, process and workflow is what absorbs it, and the two are often sequenced together. Where the answer is a queue nobody owns, that's a manager problem first, and Manager Fundamentals is where managers learn to run the queue instead of absorbing it.