Operations · Free implementation template
Client Onboarding Workflow
Map client onboarding from signed agreement through intake, access, kickoff, delivery setup, and first success milestone.
Introduction
What the Client Onboarding Workflow is for.
Map client onboarding from signed agreement through intake, access, kickoff, delivery setup, and first success milestone.
A completed operations template is the definition of done for a cross-functional workflow: the trigger, the authoritative records, the owner at each step, the exception path, and the point at which the work is genuinely finished. This one covers intake, setup, kickoff, success, and it is written for agencies, consultants, professional services. Each section is a decision that has to exist before the workflow can be built or automated — the prompts are there to force the decision, not to be filled in for their own sake.
A completed template is also a structured brief. ARIA can read it as the objective, the systems involved, and the constraints that apply, which is what turns the specification into something that runs rather than something that gets filed.
- Category
- Operations
- Sections
- 4
- Format
- Markdown, no signup
- Best for
- Agencies, Consultants, Professional services
The problem
Specifications fail on the decisions nobody wrote down.
Most operating workflows fail on the last item. Nobody wrote down the observable condition that means the work is complete, so cycle time cannot be measured, the workflow cannot be automated, and "done" is whatever the last person to touch it believed.
The second failure is shared ownership. A step owned by a team is a step owned by nobody, and it is reliably where the workflow stalls.
The third is that the failure path is discovered rather than designed. The happy path gets specified and built; the exception path gets improvised the first time a record is ambiguous, usually by dropping it.
You're likely here because
- Onboarding quality depends on who runs it
- Clients ask for things that were already agreed in the sale
- Time-to-first-value is unmeasured
How it works
From a blank Client Onboarding Workflow to a running workflow.
Each stage is a decision that has to be made once. Making them in this order is what keeps the later ones answerable — you cannot set an automation boundary before you know who owns the record.
Step 01
State the trigger
Name the event that starts the work and the system that emits it. A workflow triggered by "when someone notices" cannot be operated.
Step 02
Assign single ownership
One accountable owner per step, with a named backup and a response expectation. This is the step most templates skip and most workflows fail on.
Step 03
Declare record authority
Where two systems hold the same field, record which one wins, so an automated write cannot quietly overwrite the authoritative value.
Step 04
Design the exception path
Specify who receives a failed or ambiguous item, what the retry behaviour is, and when it escalates — alongside the happy path, not after it.
Step 05
Define completion
Write the observable condition that marks the work finished. Everything downstream — measurement, automation, SLA — depends on this one sentence.
The template
Every section, with the prompts that force the decision.
Section 01
Intake
Section 02
Setup
Section 03
Kickoff
Section 04
Success
After it is filled in
What the completed specification is actually consumed by.
Filling in the Client Onboarding Workflow produces an artifact, and an artifact on its own changes nothing. What matters is what consumes it afterwards.
Handed to the runtime, the completion condition in an operations specification becomes the thing the workflow actually measures. That single field is why cycle time becomes reportable and why the workflow can be automated at all — an observable end state is what lets a system decide it is finished instead of waiting for a person to say so.
The exception path is the other half. Most operating workflows are not slow in the normal case; they stall on the ten percent nobody specified, where the work sits unowned because the document only described the happy path. Naming the exception owner is a smaller change than it looks, and it is usually where the recovered time comes from.
Implementation path
How to actually fill it in.
- 01
Map the workflow as it actually runs today, including the undocumented steps people perform to make it work.
- 02
Assign a single owner to each step, and confirm with that person that they accept it.
- 03
Write the completion condition before writing any automation, and check it can be evaluated from data.
- 04
Run the exception path deliberately during the pilot — introduce an ambiguous record and see where it lands.
- 05
Measure cycle time and exception rate from the first week so later improvement has a baseline.
Controls this specification sets
Controls that matter.
Control 01
Consequential steps stay behind explicit human approval.
Control 02
Failed or ambiguous items land in a queue with their source context preserved; a silent drop is treated as a defect.
Control 03
Access to each system is scoped to the specific workflow rather than the full capability of the connection.
Control 04
Every automated step records what triggered it and what it changed.
Worked examples
When teams reach for this one.
After a churn review
Early churn frequently traces to onboarding steps that were skipped rather than to the product itself.
Handing off from sales to delivery
The context-transfer section is where most onboarding failures originate, and it is usually the least specified.
Scaling the delivery team
A specified onboarding is what makes a new hire’s first client look like an experienced one’s.
Limitations
What this template does not do.
- A standard workflow will not fit every client; specify where deviation is permitted.
- Time-to-value targets need a baseline before they mean anything.
- It assumes the commitments made during the sale were recorded somewhere retrievable.
- Enterprise onboarding often has procurement and security stages not modelled here.
FAQ
Questions about the Client Onboarding Workflow.
Who should fill in the Client Onboarding Workflow?
The people who own the outcome, together. This template is written for agencies, consultants, professional services, and the value comes from surfacing disagreement between them rather than from one person completing it alone.
How long does it take?
A focused session, usually one to two hours for a first pass. Sections that take much longer are normally pointing at a real disagreement, which is the template doing its job rather than failing.
Is it free, and is there a signup?
Free, with no gate. The Markdown download link at the top of this page returns the full template immediately.
What happens after it is filled in?
The completed template becomes the specification the build works from. You can hand it to ARIA to resolve into an objective and an execution path, hand it to an internal team, or use it to brief a vendor — the artifact is the same in each case.
Does this replace the tooling?
No. It specifies what the tooling has to do. Operations tools differ in how much of this they can enforce, which is itself useful information when you are comparing them.
How often should it be revisited?
When the process it describes changes, and on a scheduled review otherwise. A specification that no longer matches what runs is worse than none, because people still trust it.
More operations templates
Other operations specifications.
Business Workflow Discovery Template
Document one workflow from trigger to completed outcome, including systems, handoffs, exceptions, ownership, and measurable baseline.
Open the template →
AI Automation Readiness Checklist
Score whether a workflow is ready for automation based on repeatability, data quality, permissions, exception rate, and consequence level.
Open the template →
Approval Workflow Template
Design approvals with explicit thresholds, owners, evidence requirements, escalation, and auditability.
Open the template →
Keep exploring
Related reading and next steps.
Start with ARIA
Hand the brief to ARIA.
A completed template is a structured brief. Tell ARIA the objective and it resolves the systems involved and the execution path — so the specification becomes a running workflow, not another document.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Fill it in, then hand it to ARIA.
A completed template is a structured brief. ARIA can resolve it into the objective, the systems involved, and the execution path — so the specification becomes a running workflow rather than another document.