An onboarding plan that responds to where each client is, and tells the owner when one is stuck.
Problem
Onboarding runs from a fixed checklist. Every client gets the same steps in the same order, whatever they have already done, and a client who stalls is noticed only when someone thinks to look.
The cost is slow time to value for the client, and an onboarding team that spends its effort chasing status.
Typical applications: customer onboarding.
Shape
The steps below are platform-neutral. A platform page shows which vendor capability carries each one.
- Define the onboarding plan as steps with entry conditions, not only an order.
- Track each client's progress from the systems where the work happens.
- Adjust the remaining steps to that progress: skip what is done, add what is needed.
- Send follow-ups for the client's outstanding steps, in wording the owner has approved.
- Escalate to the named owner when a client stalls past an agreed period.
- Close onboarding against stated completion criteria.
Control set
The control set is part of the design, not a follow-up. Each control is agreed with the process owner before the build starts.
| Control | How it is met |
|---|---|
| Review | Message templates sent to clients are approved by the owner in advance. Anything outside the approved templates is drafted for the owner to send. |
| Data | The workflow reads onboarding status and the client contact details needed for follow-ups. It does not read client content beyond what the plan requires. |
| Monitoring | Time in each step, stalled clients, follow-ups sent and escalations raised are tracked per client. |
| Off switch | Follow-ups can be paused per client or for all clients. The plan and its status remain visible. |
| Correction | A wrong step or message is corrected with the client by the owner, and the entry condition that caused it is fixed. |
Measures
Reference design. This pattern has not yet produced measured results in a C9D Consulting engagement. The targets below are examples of the shape, not results and not promises. Real targets come from the baseline measured in the diagnostic.
| Baseline | Metric | Example target |
|---|---|---|
| Days from signature to completed onboarding | Median onboarding duration | Shorter than the measured baseline, by an amount set in the diagnostic |
| Clients stalled without anyone knowing | Stalls detected by the owner before the client raises them | All of them |
| Owner time spent chasing status | Hours per week on status follow-up | Most follow-up handled without the owner |
Handoff
At the end, the client team owns:
- The onboarding plan with its entry conditions and completion criteria
- Approved message templates and the rule for changing them
- A runbook for pausing follow-ups and handling escalations
- Champions in the team that owns client onboarding
Where it applies
| Platform | Application |
|---|---|
| monday.com | AI Enablement on monday.com |
A platform that is not listed has no published application yet. The pattern itself does not depend on any one vendor.
Engagement
This pattern is not sold on its own. It is delivered through the engagement shapes in the Engagement Specification.
- E-01 Decision Advisory. Settles whether this pattern is the right first move, on which process and on which platform. It starts with a diagnostic and ends with the playbook handoff.
- D-01 Delivery Engagement. Where the client wants the workflow built, the build ends with working software and its playbook.
Read the Engagement Specification, or request a conversation.