September 13, 2026
SCOPE, CAPACITY, AND THE ECONOMICS OF YOUR TIME

Service pricing fails in the invisible hours. The meeting is two hours; the engagement is twenty. This lesson makes capacity and effective rate visible so a fixed price covers the whole job — and so you stop selling weeks you do not have.
The vocabulary
- Capacity — the total deliverable hours you actually have in a period.
- Utilization — the share of capacity spent on billable delivery versus everything else.
- Delivery time — hours the client sees (calls, workshops, live work).
- Preparation — research, setup, customization, and materials before delivery.
- Support — messages, fixes, and follow-ups after delivery.
- Revision — bounded rework rounds included in the price.
- Opportunity cost — what you forgo by taking this engagement instead of the next best use of the time.
- Effective hourly rate — fixed price divided by all hours the engagement consumes, visible and invisible alike.
The formula that matters: a $2,000 package consuming 20 total hours pays $100 per hour, not the $500 per hour the four visible hours suggest. Price the twenty.
Fixed price means pre- plus post-work
Beginners price the performance and donate the rehearsal. A fixed-price service must count six buckets: discovery and scoping, preparation and customization, delivery, documentation and handoff, support, and revision. Miss any bucket and margin evaporates exactly when the client is happiest — right after delivery, when questions peak.
Name revision bounds in writing: "two revision rounds, each returned within five business days, each limited to the original brief." Without bounds, "just one more tweak" becomes an unpaid retainer. The same discipline applies to support: "30 days of email, two-business-day response, questions about the delivered workflow" — not unlimited consulting by another name.
Use the two-day workshop sketch as a calibration tool (illustrative hours, not a market quote). The brochure says "two days." The real ledger looks like this:
| Phase | Work | Typical hours |
|---|---|---|
| Prep | Discovery call, customization, materials, room/tool setup | 8–12 |
| Delivery | Two live days with facilitation and notes | 12–14 |
| Follow-up | Session notes, artifact review, feedback replies | 4–6 |
| Materials | Templates, deck, checklist, FAQ updates | 3–5 |
| Total | 27–37 |
A "two-day" workshop is a full workweek. Price it as one. The same multiplier applies to audits, implementations, and cohort weeks: multiply visible hours by three to four when estimating, then refine with real tracking after three deliveries.
Capacity is a customer-experience issue
Overbooking is usually framed as a personal productivity problem. It is really a quality problem. The fourth concurrent client gets the tired version of you: slower replies, thinner feedback, missed follow-ups. Quality dips, referrals dry up, and the margin from the extra booking is paid back as reputation.
So set concurrency as a promise, not a stretch goal. A solo builder running three-week implementations might set a maximum of two concurrent clients with one onboarding slot per week. Add a pause trigger with a number attached: "pause sales when active engagements reach two, or when support backlog exceeds five open threads, or when prep for the next delivery is less than 50% complete three days out." Write the trigger before you need it, because need is exactly when judgment fails.
Track utilization honestly for one month: delivery, prep, support, revision, admin, and business development. Most solo providers discover delivery is under half their week. That discovery is the point — it resets prices, timelines, and the courage to say "next slot opens in three weeks."
Exercise: write SERVICE-CAPACITY.md
Create SERVICE-CAPACITY.md with a table of every delivery step: step name, owner, estimated hours, and timing (before/during/after). Then add:
- Maximum concurrent clients with the reasoning (support load, feedback turnaround, quality bar).
- Pause trigger — the exact condition that stops new sales.
- Effective-rate check — fixed price divided by total estimated hours, plus the delivery-cost assumption to revisit after three engagements.
Worked miniature (illustrative hypothetical): source-linked workflow implementation at $2,400 — discovery 2h, prep 6h, delivery 6h, documentation 3h, support 4h, revisions 3h = 24h total → $100/hour effective. Max two concurrent. Pause trigger: two active builds or six open support threads. Revisit: if support averages over 5h, raise price or tighten the support boundary.
Finish line: an offer a solo builder can deliver well more than once — with every hour owned, a concurrency ceiling, and a pause trigger written before the rush.
Verify quickly: add 30% to your support estimate. Does the effective rate still clear your floor? If not, narrow scope or raise the price now, not after the third exhausting client.
Common failure mode: counting only delivery hours and calling the rest "small stuff." The small stuff is the job. Measure three engagements end to end, then reprice.
Check your understanding
1. Define effective hourly rate and compute it for a $1,800 package costing 18 total hours. 2. Why does a "two-day" workshop typically consume a full workweek? 3. What is a pause trigger, and why must it be written before demand spikes?
Next
You can deliver sustainably. Lesson 82.5 turns repetition into leverage: inventory the questionnaires, templates, and checklists hiding inside your past work and build the asset backlog that makes every future engagement faster and clearer.
ARTICLE DISCUSSION
JOIN THE
CONVERSATION.
Got a question, a take, or a better way to do this? Log in and leave a comment.
