Plan sustainable capacity
How to scale a service business when expert time is the bottleneck
Scaling a service business means delivering more accepted client work without every extra job requiring the same scarce expert effort. Reusable methods and software can help, but review, support and knowledge upkeep still consume time. Model those parts of delivery alongside the demand you can actually win.
Count all the work needed for an accepted result, then distinguish available capacity from the demand and revenue actually realised.
Find the expert work that limits delivery
Map a complete accepted job. Separate repeat preparation from judgement, client clarification, review and corrections. Identify which part genuinely needs the expert and which part requires information the expert happens to be carrying.
Said sees an opportunity for content firms to reuse client and competitor context through self-service. That could let former clients use a smaller ongoing service. Whether it expands delivery depends on uptake and on the expert time still needed for each accepted job.
Choose a repeated method you can describe and test. Keeping every client variation in the founder’s head makes reuse difficult, even if the first draft is generated automatically.
Model the whole accepted job
Delivery hours per job = preparation + expert review + corrections + support Capacity per period = (available delivery hours − fixed upkeep hours) ÷ delivery hours per accepted job
Use the same definition of an accepted job in both designs. Include failed attempts and rework in the observed average. Add fixed upkeep for shared methods, sources and software, plus one-time setup outside the recurring model.
| Design | Available hours | Fixed upkeep | Hours per accepted job | Calculated capacity |
|---|---|---|---|---|
| Current expert delivery | 100 | 0 | 2 | 50 jobs |
| Reusable method with bounded review | 100 | 10 | 1.5 | 60 jobs |
| Reusable method needing more correction | 100 | 10 | 2.5 | 36 jobs |
These invented figures show why review matters. The second route creates ten more jobs of theoretical capacity. The third route delivers less capacity than the starting design because correction consumes the supposed saving. None of these values is a client outcome or benchmark.
Connect the capacity model to real demand
If clients want only 20 jobs in the period, capacity for 60 does not create 60 paid jobs. Record the offer, clients who accept it and the frequency with which they return. Former-client reactivation is one possible route, with its own demand test.
Model delivery contribution using actual revenue minus the direct delivery work and running costs you include. State which costs are excluded; contribution is different from overall profit. Keep setup, sales and wider overhead visible in the investment decision.
Check whether the smaller service adds useful work or moves existing higher-value work to a lower fee. Some clients may need a lighter service, while others still need substantial expert help. Learn that from actual jobs and accepted offers.
Preserve the method as volume grows
Record client-specific requirements and approved changes. Give sources owners and review rules. In Said’s reporting experience, the number of routes and the effort to maintain them are important parts of the complexity.
Test quality and support at the proposed volume. A handful of successful jobs may conceal a queue at expert review when every client uses the same deadline. Include a fallback when the shared system is unavailable.
Expand after accepted work, repeat use and delivery effort support the next step. The new-service validation guide provides a demand test, while the productisation guide helps define the offer.
Build the model from your own jobs
Worked example
The invented 100-hour comparison
Invented teaching example. No client outcome is claimed.
STARTING ROUTE
100 available hours ÷ 2 hours per accepted job = 50 jobs.
REUSABLE ROUTE
(100 − 10 upkeep hours) ÷ 1.5 hours per accepted job = 60 jobs.
SENSITIVITY
At 2.5 hours per job, the same route has capacity for 36 jobs.
DEMAND
If clients accept 20 jobs, the model does not assume revenue from the unused capacity.
LIMIT
All values are invented and exclude one-time setup from recurring capacity.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.