Operations / Workflow design
Client onboarding: turn an approved handoff into assigned work
Create a clear boundary between what the client approved, what the team must do and what still needs a decision.
A new client can be sold correctly and still arrive in delivery with missing information. The scope sits in a document, access details are in email and the project manager hears the start date secondhand. An onboarding workflow should make those gaps visible before it creates a confident plan.
Define the handoff that starts work
Use a specific approved event as the trigger, such as the delivery lead accepting the completed handoff. A sales stage change alone may not establish that the scope, dates and responsibilities are settled. Keep a link to the approved source and its version.
Where your existing tools support approvals, use them. Microsoft's Power Automate documentation shows a "Start and wait for an approval" action followed by a condition that routes the result. That is one documented implementation option; the design below can also begin with a manual review in your current project tool. Read Microsoft's approval workflow tutorial.
Build a short, usable sequence
- Collect required fields. Record the client identifier, approved work, exclusions, delivery owner, client contact, dependencies and agreed dates. Mark unknown values explicitly.
- Draft the task list. Use a maintained template for the service. Let AI suggest which existing tasks apply, with a reference to the handoff for any proposed addition.
- Review assignments. Have the delivery owner check responsibilities and capacity. An assistant should not infer somebody's availability from their name appearing in a document.
- Create once. Use the client and engagement identifiers to detect an existing project. Store created task references so a retry does not build another copy.
- Confirm the handoff. Record the reviewer, approved version and missing dependencies. Send invitations or client requests only through the agreed communication process.
A fictional example
Cedar Studio signs a reporting engagement with Atlas. The handoff confirms the deliverable but leaves the data owner blank. The proposed workflow drafts internal preparation tasks and flags the missing owner. It does not guess a contact, request broad account access or promise a delivery date. The project manager resolves the gap with the account lead before releasing dependent tasks.
Test the awkward cases
Try a duplicate handoff, a revised scope and a missing start date. Confirm that the second run updates or stops appropriately rather than silently creating another project. Check that a rejected handoff cannot continue along the approved path.
Pause automation when the service itself has no stable template or the sales and delivery teams disagree about what acceptance means. Writing that agreement down is useful work.
Start with one handoff: Bring a redacted example of where onboarding stalls. We can discuss the missing decision and the smallest process change that would address it.
These are practical workflow guides, not claims of a tested client implementation. Examples are fictional. Features, plans and availability can change; check the linked documentation before setup.
Make the next handoff clearer.
Discuss one onboarding handoff and the approvals, owners and missing information around it.