Customer Onboarding Automation: Make the Handoff Verifiable Before It Becomes Fast

# Customer onboarding SOP

Version: 1.0

Owner: Customer success or implementation operations

Effective date: [YYYY-MM-DD]

Review cadence: [cadence and owner]

## Purpose and scope

Move one accepted commercial handoff into an owned onboarding case, complete agreed setup and milestones, and transfer an evidence-backed operating record to steady-state customer success. This procedure does not change contract scope, authorize access, or replace customer and internal decision owners.

## Trigger, inputs and prerequisites

- Trigger: accepted closed-won or equivalent handoff event with a stable event ID.
- Identity: customer ID and accepted agreement/order ID.
- Required inputs: outcome, scope version, exclusions, stakeholders, owners, dependencies, milestones, data-purpose fields and acceptance authority.
- Prerequisites: approved onboarding profile, message templates, access policy, retention rule, exception queue and steady-state owner.

## Roles

- Commercial owner: supplies and corrects the handoff packet.
- Onboarding owner: accepts the packet and owns the case.
- Customer sponsor/operator: supplies declared actions and accepts agreed evidence.
- Specialist owner: resolves product, data, security or other scoped dependencies.
- Steady-state owner: accepts the final operating record and open items.

## Procedure

1. Receive the trigger and find or create the case with an idempotency key.
2. Validate packet version, identity, required fields, data purpose, owners and duplicates.
3. Return every missing or conflicting field to its named owner; do not default scope or outcome.
4. Create the milestone plan from the approved onboarding profile.
5. Have the onboarding owner approve plan, access, recipients and any customer-facing date.
6. Collect evidence for each milestone and record source, time and actor.
7. Send only approved reminders; route expiry or blockers to the owned exception queue.
8. Reopen rejected evidence without overwriting the prior decision.
9. Assemble the steady-state packet: accepted milestones, owners, open items, risks and correction path.
10. Record acceptance by the receiving owner and customer role where the contract requires it.

## Decisions, exceptions and approvals

- Duplicate trigger: reuse the case and attach the new event.
- Conflicting scope: pause plan generation for the commercial/scope owner.
- Sensitive or unexpected field: remove it from generated context and route a purpose/access review.
- Missing customer action: follow the approved cadence, then escalate to the onboarding owner.
- Changed outcome, scope, access or external commitment: named human approval required.
- Rejected milestone: retain the rejection, correction and new acceptance as separate events.

## Output and completion

Completion requires an accepted steady-state packet, not a task percentage. Store case ID, input versions, milestone evidence, decisions, exceptions, approvers, external effect IDs and receiving-owner acceptance.

## Service measures

Track returned handoff rate, time waiting for missing inputs, milestone reopen rate, exception age, unsupported-summary corrections and cases transferred with open unowned items. Set targets from observed baselines rather than this template.

## Worked example (simulated)

A case contains contacts, package and kickoff week but no first-value outcome or dependency owner. Validation returns both gaps before any welcome message. After the commercial and implementation owners correct them, the onboarding owner approves the generated milestone plan. Completion occurs only after the receiving owner accepts the sample-run evidence and open-item list.

## Revision log

| Version | Date | Change | Approver |
| --- | --- | --- | --- |
| 1.0 | [YYYY-MM-DD] | Adapted from public template | [name/role] |

# Customer onboarding workflow blueprint

## Trigger and termination

- Trigger: accepted handoff event `{event_id, customer_id, agreement_id, handoff_version}`.
- Success: steady-state packet accepted with every required milestone evidenced and every open item owned.
- Stop: revoked authority, disputed scope, invalid data purpose, unrecoverable identity conflict or owner-issued stop.

## State model

`received -> validating -> returned | planning -> awaiting_plan_approval -> active -> blocked | awaiting_milestone_acceptance -> awaiting_transfer_acceptance -> complete`

Terminal alternatives: `stopped`, `superseded`. Rejections create new events; they do not erase prior state.

## Data contract

Required: case/customer/agreement IDs, source version, outcome, scope/exclusions, stakeholders, owners, dependencies, milestone evidence contracts, data fields with purpose/access/retention, acceptance authority. Generated summaries store source record IDs and spans.

## Ordered steps and actors

1. **Trigger:** receive accepted handoff.
2. **Code:** deduplicate by event ID and case key; validate schema and ownership.
3. **Code:** return named gaps or create the milestone draft.
4. **AI (bounded):** summarize supported dependencies and risks; unknown is valid.
5. **Human:** approve plan, access, recipients, dates and commitments.
6. **Code:** create tasks, collect evidence and send approved reminders.
7. **Human:** resolve exceptions and accept milestone evidence.
8. **Code:** assemble versioned steady-state packet.
9. **Human:** accept transfer and unresolved-item ownership.

## Idempotency, retry and rollback

- Keys: `handoff:{event_id}`, `case:{customer_id}:{agreement_id}`, `task:{case_id}:{milestone_version}:{task_key}`, `message:{case_id}:{template_version}:{recipient}:{purpose}`.
- Retry reads and internal writes with bounded backoff. Reconcile an external effect by its returned ID before retrying.
- Rollback cancels only unexecuted tasks/messages. Correct completed effects through compensating events; never delete history.

## Permissions and sensitive data

Use least-privilege service roles. Exclude undeclared sensitive fields from model context and test fixtures. Record purpose, allowed roles, retention event and disposal owner for every copied dataset.

## Exception routes

- Duplicate/conflicting identity -> identity owner.
- Missing scope/outcome -> commercial owner.
- Access/data-purpose issue -> privacy/security owner.
- Customer dependency expiry -> onboarding owner.
- Rejected evidence -> milestone owner.
- No exception owner -> safe stop.

## Acceptance tests

1. Duplicate trigger creates no duplicate case or task.
2. Missing outcome blocks communication and names its owner.
3. Conflicting scope blocks plan approval.
4. Model returns unknown when a dependency lacks evidence.
5. Expired approver cannot resume the workflow.
6. Rejected milestone preserves the prior evidence and decision.
7. Partial message failure retries only the missing effect.
8. Completion is impossible without receiving-owner acceptance.

## Audit record

Retain event/run IDs, definition and input versions, state transitions, source references, approvals/rejections, external effect IDs, exceptions, retries, corrections and final acceptance.