Capacity: the constraint nobody models

Most service firms model revenue targets in detail and capacity not at all — yet capacity, the hours genuinely available to sell and deliver, is the constraint the whole plan lands on. Growth plans fail at the point nobody drew: the founder's week. Until capacity is a number in a spreadsheet, every target is a wish with a deadline attached.

What is capacity in a service firm?

Sellable, deliverable hours — after everything else. A service firm's product is applied attention, so capacity is the stock of attention-hours the firm can actually spend on client work and on winning it. The naive calculation (staff × 40 hours) is out by half or more once you subtract admin, meetings, context-switching, management, sales, and the recovery cost of interruptions. For the founder the honest number is worse again: in most firms I see, genuinely productive founder hours on sales or billable work are a minority of the week, with the rest absorbed by being the routing layer for everyone else's questions — the structural problem set out in The Founder-as-Bottleneck Report.

The uncomfortable implication: in a founder-dependent firm, firm capacity is not the sum of everyone's hours. It is the founder's available hours, because every project and every deal queues for a slice of them.

Why does nobody model it?

Three reasons. Revenue is exciting and hours are not, so planning gravitates to the number that goes in the deck. Capacity feels elastic — founders have always absorbed overload by working evenings, so the constraint never presents as a hard wall, only as creeping exhaustion. And modelling it honestly is mildly humiliating: writing down that the firm's growth ceiling is "about eleven founder-hours of selling a week" makes the plateau embarrassingly legible.

But unmodelled is not the same as absent. The constraint still binds; it just binds by surprise — as missed deadlines, rushed proposals, and quarters where delivery ate the pipeline.

What is the simple model?

One page, five steps, refreshed monthly:

1. Count real hours. For each person including yourself: contracted hours minus admin, meetings, and management. Log a fortnight if you are guessing — the log is always lower than the guess.
2. Split them into sell-hours and deliver-hours. These compete, which is the root of the feast-famine cycle.
3. Cost your offers in hours. When a project needs 60 delivery hours and the month holds 300, then the ceiling is five projects — no opinion required.
4. Cost your pipeline in sell-hours. When a won deal needs roughly ten hours of calls, proposals, and chasing, and the founder has ten sell-hours a week, then the firm closes about a deal a week at best — and that arithmetic caps revenue regardless of demand.
5. Compare the plan to the ceiling. When target revenue needs more hours than the model holds, then something must change before the quarter starts — price, process, or people — rather than being discovered in week nine.

The model's value is not precision; it is that overload becomes visible before it happens, and the response becomes a decision instead of a fire.

What breaks when you ignore it?

Everything downstream, on a delay. Overcommitted delivery pushes selling to zero, so the pipeline empties just as projects finish. Proposals go out late and thin, so win rates sag exactly when you need them. Quality slips, which taxes the referral channel months later. And the founder's judgement — the firm's scarcest input — degrades under sustained overload, which quietly worsens every other decision. None of these announce themselves as "a capacity problem"; they present as bad luck, four months after the cause.

How do you buy capacity back?

In order of cost. First, remove work from the constraint: the delete-automate-delegate triage recovers founder hours that were never doing anything valuable. Second, systemise demand generation so selling stops consuming founder attention it does not need. Third, price against the constraint: when demand exceeds modelled capacity, then that is a pricing signal before it is a hiring signal — the rule is in The win-rate trigger: when to raise prices. Hiring comes last, once the constraint is documented enough for a hire to actually relieve it.

Two adjacent disciplines round this out. The founder's personal energy and attention are a capacity system of their own, run by the same logic — that is the territory of The Personal Operating System. And reclaimed hours need a deliberate destination, or the business will silently refill them with more of the same; the highest-yield use I know is building assets that sell while you deliver, covered in Building authority before your first case study. Model the constraint, and growth becomes arithmetic. Ignore it, and growth remains a hope with a spreadsheet in front of it.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks and what to build first.