A 5-year support capacity plan, built before anyone asked for one.

A walkthrough of how I designed a multi-scenario capacity model that ties support headcount, tooling spend, and ARR risk directly to growth, and how it now informs board-level decisions.

Why I built it without being asked

Most support functions plan capacity reactively. Tickets pile up, the team is stretched, and someone makes the case for another hire. By the time the model exists, the problem already exists.

I wanted to flip that. The capacity plan was something I built proactively, not in response to a request from leadership but because I could see the gap. We had years of historical data. We had a clear sense of where the business was heading. There was no reason support should be the only function operating without a forward-looking financial view of itself.

The brief I set myself was specific: predict the volume of work coming in, model what that means for headcount and tooling, and tie it back to commercial outcomes the leadership team actually cares about.

What the model actually does

The plan models three growth scenarios across a five-year horizon: conservative, base, and aggressive. Each scenario factors in:

• Volume forecasts based on multiple business levers, including investment rounds, geographic expansion, vertical expansion, and the onboarding of larger enterprise customers (which can bring in multiple sub-accounts at once).
• Ticket complexity trends, accounting for whether incoming queries are becoming more or less complex over time. A 10% volume increase of high-complexity tickets is not the same workload as a 10% increase of simple ones.
• Tooling investment and ROI, including which tools should scale with growth, which can be replaced with automation, and where AI deflection should reduce headcount pressure rather than add to it.
• Cost-saving and reinvestment opportunities, modelling what we could responsibly increase or decrease in the support stack at each stage of growth.
• Headcount triggers, identifying the volume thresholds at which a new hire becomes necessary, so we can recruit before the team is stretched rather than after.

It's not a static document. It's updated monthly as new data comes in, so the plan stays accurate against reality rather than drifting out of date.

How ARR-at-risk fits in

This is the part that makes the plan land in commercial conversations. Capacity isn't just about whether we can answer tickets. It's about what happens when we can't.

The model uses SLA and SLO performance as the primary signal of service quality. If response or resolution times degrade, that's the leading indicator that customer experience is slipping. Combined with that:

• Keyword-based churn signals are flagged automatically through Intercom, surfacing language patterns that historically correlate with at-risk accounts.
• Per-client monthly reports are produced for the Customer Success team, summarising what each enterprise client has been raising, so renewals and QBRs can be prepped with a real view of customer health rather than a sales-only one.
• Audit and review of the flagged signals catches at-risk accounts early enough to act, rather than discovering them at renewal.

Capacity isn't just whether we can answer the tickets. It's what happens to the customer relationship when we can't.

By tying support performance directly to retention indicators, the plan gives leadership a much clearer picture of what's actually at stake when a hiring or tooling decision gets delayed.

The hardest part wasn't the modelling

Building a multi-scenario financial model as a non-finance person is genuinely difficult, but the harder problem was upstream of that: data quality.

We had migrated our customer support platform between regions during the period the model needed to cover, and pulling clean historical data across that migration required exporting through APIs and reformatting it before it could be reliably modelled. Once that was done, the analysis itself was straightforward. But the export and clean-up was the part that took the most time and the most patience.

How it's actually being used

The plan now informs leadership conversations directly. Specific outputs feed into:

• Hiring decisions, with the model identifying when team capacity will hit its threshold and an additional hire becomes the right move, rather than a discretionary one.
• Tooling and automation investment cases, with ROI projections grounded in the same forecast that drives the rest of the planning.
• Customer Success enablement, with the per-client reporting now part of how the team prepares for renewals and reviews.
• Cross-functional planning, since the volume forecasts give Product and Engineering visibility into where support load is likely to come from, not just how much.

What I'd do differently next time

The biggest lesson is uncomfortable but important: I should have built this from day one.

I didn't pull the first version of this report until three years into the role. The work it has unlocked since (clearer hiring decisions, sharper tooling cases, earlier churn signals) all could have started years earlier. Capacity planning is one of those things that feels too early until suddenly it's too late.

If I were doing this again at a different company, I'd build a thin version of this model in the first quarter, even if the data was rough, and iterate it monthly from then on. Keeping it live and current is what makes it useful. A static plan goes out of date the moment something material changes.

Why this matters more than the metrics suggest

A capacity plan looks, on the surface, like a finance exercise. It isn't. It's the document that lets a support function speak the same language as the rest of the leadership team. It turns "we need another hire" into "here's the volume threshold, here's the ARR at risk if we don't, here's the cost-benefit of hiring versus automating."

That's the difference between a support team that gets reluctantly approved budget and a support function that's understood as a commercial lever. The plan didn't change what we did. It changed how the rest of the business saw what we did.