Client onboarding control system for a fictional 12-person service firm.

This page shows the type of operating artifacts a 5-Day Operating Control Sprint can produce. The company, workflow, people, data, issues, and examples below are invented solely to make the deliverable concrete.

No customer result is being claimed. This is not a case study, testimonial, diagnosis, or representation of work performed for an actual client.

WorkflowSigned client → kickoff-ready

Illustrative teamFounder + Sales + Ops + Delivery

Primary problemFounder catches missing handoffs

Target stateTeam-owned with exception escalation

1. Current-state workflow map

The first artifact makes the actual movement of work visible—including the informal checks that currently live in someone’s head.

Contract signed→Sales emails Ops→Ops creates project→Drive folder created→Client questionnaire sent→Delivery lead assigned→Kickoff scheduled

Hidden dependency: founder is copied whenever scope differs from the standard package.
Handoff gap: there is no explicit evidence that billing terms, scope, and client contacts were transferred before delivery assignment.
Visibility gap: “waiting on client” and “waiting on internal owner” look identical in the project board.
Failure mode: kickoff can be scheduled before required access/materials are complete, creating avoidable rescheduling.

2. Ownership + escalation matrix

Decision / event	Owner	Evidence of completion	Escalate when
Standard client handoff	Sales owner	Required handoff fields complete	Never, if standard scope
Project creation	Ops coordinator	Project ID + owner + due date assigned	Required data missing > 1 business day
Scope variance	Delivery lead	Variance logged + proposed resolution	Commercial impact exceeds agreed threshold
Client access missing	Ops coordinator	Missing-access checklist + reminder sent	Still blocked 48 hours before kickoff
Kickoff readiness	Delivery lead	Readiness gate = green	Any required gate remains red at T-24h

3. Exception / bottleneck register

Exception	Signal	Default action	Severity
Missing signed scope detail	Required handoff field blank	Return to Sales owner; do not create kickoff	High
Client assets incomplete	Readiness checklist incomplete	Automated reminder + Ops owner task	Medium
No delivery owner	Project unassigned after 4 business hours	Route to Ops lead	High
Nonstandard request	Scope variance flag = yes	Delivery lead evaluates; escalate only above threshold	Medium
Ready on time	All required gates green	Proceed without founder review	Normal

4. Weekly operating review

The review is intentionally small: only metrics that should change a decision or expose an exception.

Onboarding cycle timeSigned contract → kickoff-ready. Review trend, not vanity target.

Blocked onboardingsCount + oldest age + blocker owner.

Founder escalationsCount and reason. Repeated reasons become system-fix candidates.

Readiness failuresKickoffs reaching T-24h with required gate still red.

15-minute review questions

Which onboarding is currently blocked, by what, and who owns the next action?
Which exception repeated this week and should become a standard rule or checklist item?
Did anything reach the founder that could have been decided at the team level?
Which automation failed, produced uncertainty, or still requires a human check?
What one change should be tested before the next weekly review?

5. Three implementation-ready SOP/checklist examples

SOP A — Sales → Ops handoff

Confirm signed agreement and package.
Complete required handoff fields: scope, contacts, promised dates, billing state, special conditions.
If scope is standard, submit directly to Ops; founder approval is not required.
If variance flag is triggered, attach the variance and proposed resolution.
Handoff is complete only when Ops accepts ownership.

SOP B — Kickoff readiness gate

Confirm delivery owner assigned.
Confirm required client assets/access received.
Confirm scope and first milestone visible to delivery team.
At T-24h, unresolved required items turn gate red.
Red gate prevents “ready” status and triggers named escalation.

SOP C — Founder escalation rule

Do not escalate a routine issue merely because it is uncomfortable or unusual.
First identify the owner, rule, threshold, and recommended next action.
Escalate only when commercial impact, legal/contract ambiguity, strategic exception, or defined financial threshold exceeds team authority.
Every escalation must include: decision needed, options considered, recommendation, and deadline.
Repeated escalation reasons are reviewed weekly for a new decision rule or system fix.

6. Automation opportunity shortlist

Opportunity	Automate	Keep human	Why
Project creation	Create standard project/folder/tasks from accepted handoff	Review nonstandard scope flag	High repetition, deterministic inputs
Missing client materials	Reminder cadence + blocker status	Judgment on unusual client circumstances	Automate chasing, not relationship judgment
Weekly exception brief	Aggregate blocked items + age + owner	Choose action / change rule	AI can summarize; operating decisions stay explicit
Kickoff readiness	Calculate gate from required fields	Override only with named accountable approver	Keep exceptions auditable

7. 30 / 60 / 90-day backlog

Next 30 days

Run the readiness gate on every new onboarding.
Measure founder escalations by reason.
Fix the two highest-frequency handoff omissions.

Days 31–60

Automate standard project creation.
Standardize scope-variance thresholds.
Train backup Ops owner on the same rules.

Days 61–90

Review cycle-time and exception trends.
Retire controls that do not change decisions.
Expand the same pattern to the next workflow.

What the buyer actually receives

A compact, editable operating package: workflow map, owner/escalation matrix, exception register, KPI/review cadence, three SOPs/checklists, automation shortlist, and next-step backlog—built around the real workflow and tools provided during the sprint.

See the 5-Day Operating Control Sprint →