Three onboarding workflows. One customer. No owner.
This case shows the intake-to-decision system doing its actual job: taking three well-intentioned, overlapping requests and turning them into one accountable decision. It is a sanitized illustration. The pattern is real and common; the organization depicted is a composite, and no outcomes are claimed.
- Type
- Sanitized application
- What this is
- An illustrative application of the intake-to-decision system. No client or employer identities; no outcome claims.
- Scope
- Three overlapping customer-onboarding workflows, six functions, one decision.
- The system applied
- Intake-to-Decision, 8 stages
- Overlapping workflows
- Decision gate, human-owned
- One governed path, six functions
Customer onboarding had grown three separate workflows: one built by Product inside the application, one run hands-on by Customer Success, one assembled by Engineering for enterprise integrations. Each was locally reasonable. Together they meant a new customer could enter three pipelines with different steps, different owners, and different definitions of “onboarded.”
The overlap surfaced the way it usually does: as three separate improvement requests, each framed as a solution, each with a sponsor, each plausibly fundable on its own. An organization without intake discipline would have funded all three, deepening the fragmentation it was paying to fix.
Product
Owned one of the three workflows and the customer-experience framing of the problem.
Engineering
Maintained the integration surfaces of all three workflows, and the duplicated build effort between them.
Customer Success
Ran a second workflow hands-on and held the clearest view of where customers actually stalled.
Legal
Held data-handling and contractual-review obligations that two of the three workflows had been routing around differently.
Security
Owned access-review requirements that consolidation would concentrate into a single path.
Analytics
Measured onboarding three different ways, meaning no consolidated view of the funnel existed at all.
Intake revealed the overlap
Routed through one intake format, the three requests stopped being three projects and became three descriptions of the same customer problem. The duplication was visible before any money moved, the cheapest moment to find it.
Triage reframed solutions as a problem
“Rebuild our onboarding flow” became “onboarding is fragmented across handoffs between six functions.” One sponsor was named, and two requests were closed as duplicates in the open.
Capacity was estimated as a range
Consolidation was sized best-case to worst-case, with delivery history for integration-heavy work arguing for the wide end. The commitment was sized to the delivery evidence.
Risk review changed the design
Legal and Security surfaced data-handling and access-review dependencies before design started. Analytics flagged that three different onboarding metrics would corrupt any consolidated funnel, so an instrumentation fix entered the scope before launch.
Three real options were priced
Consolidate fully; standardize the interfaces between the workflows first; or defer with the cost of continued fragmentation stated. Each option carried its capacity impact across all six functions, including the cost of doing nothing.
One packet replaced three decks
A single decision packet (recommendation, risks, capacity impact, open questions) replaced the three competing slide decks the functions had been maintaining for their own versions of the initiative.
A person decided, and wrote down why
An accountable executive chose interface standardization first, deferred full consolidation, and recorded the conditions under which it would be revisited. No score made the call; AI had prepared everything and decided nothing.
The system learned
After the first delivery increment, actuals were compared against the committed range, and the intake template itself changed, gaining the overlap-check field all three original requests had lacked.
Overlap is an intake problem
Duplication is cheapest to catch before scoping. It takes a shared request shape to see that three asks are one problem.
Functions validate their own risks
Legal, Security, and Analytics changed the design because they were asked before commitment, while the decision could still absorb what they knew.
Options preserve executive judgment
A single proposal would have made the decision a rubber stamp. Three priced options made it a genuine tradeoff an executive could own.
The loop closes into the template
The lasting artifact is the improved intake system that catches the next overlap automatically.
The full operating system behind this case, all eight stages with their AI placements and human checkpoints, is documented separately.