# 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] |