Onboard a Customer

Turn accepted customer outcomes and commitments into an owned, evidence-based path to first value.

Reconcile what was sold, what the customer expects, and what the product and delivery organization can currently provide before presenting the onboarding plan as committed.

The onboarding plan should be shaped around customer value—not a generic product tour or arbitrary timeline.

1. Establish the accepted customer outcome

Identify:

• account;
• purchased product, package, or scope;
• business goals;
• intended users;
• customer stakeholders;
• internal stakeholders;
• decision owners;
• implementation owner;
• target dates;
• accepted success measures;
• relevant constraints;
• immediate next milestone;
• expected first-value event.

Use authoritative sources such as:

• signed contract or order context;
• approved proposal or statement of work;
• approved sales notes;
• solution design;
• handoff material;
• previous customer meetings;
• relevant email;
• CRM records;
• implementation records;
• approved technical documentation.

Separate:

• signed or formally accepted terms;
• approved commitments;
• informal discussion;
• sales expectations;
• working assumptions;
• unresolved questions.

Never convert an optimistic sales note, informal conversation, roadmap comment, or unapproved expectation into a product or delivery commitment.

When sources conflict, surface the conflict before building the plan around it.

2. Reconcile readiness, dependencies, and gaps

Determine what must be true for the customer to reach the accepted outcome.

Check readiness across:

• people;
• product access;
• roles and permissions;
• data;
• configuration;
• integrations;
• technical prerequisites;
• security review;
• privacy requirements;
• legal requirements;
• billing state;
• training;
• enablement;
• change management;
• support model;
• internal staffing.

For each dependency, identify:

• customer owner;
• internal owner;
• required specialist;
• prerequisite;
• current state;
• blocker;
• target timing when accepted.

Keep credentials, tokens, sensitive customer data, and restricted information inside approved systems.

Do not copy secrets into onboarding documents, chat messages, or general task trackers.

If access, security, privacy, legal, billing, data movement, custom development, or technical feasibility is unclear, route the issue to the responsible specialist before representing the onboarding plan as ready.

3. Build the onboarding path around customer value

Create a practical plan designed to reach meaningful customer value.

Include:

Accepted outcome

State the business outcome and success measures that have actually been accepted.

Stakeholders and ownership

Identify:

• customer sponsor;
• customer implementation owner;
• key users;
• internal owner;
• specialists;
• reviewers;
• escalation path.

Milestones

Define meaningful milestones and dependencies rather than arbitrary calendar checkpoints.

For each milestone, capture:

• intended result;
• owner;
• dependencies;
• target date where accepted;
• completion evidence.

Required implementation work

Include only work genuinely necessary for the accepted outcome, such as:

• account setup;
• configuration;
• integrations;
• data preparation or migration;
• user provisioning;
• training;
• workflow setup;
• enablement;
• adoption activities.

Risks and decisions

Track:

• assumptions;
• blockers;
• risks;
• unresolved decisions;
• dependencies;
• escalation conditions.

First-value checkpoint

Define the earliest meaningful evidence that the customer is receiving value.

Make the evidence observable where possible.

Do not impose a fixed 30/60/90-day onboarding structure unless it matches the actual product, customer, and implementation model.

Adapt sequencing and pace to the customer's situation.

4. Prepare the kickoff and customer interactions

Route kickoff and subsequent meeting preparation through the appropriate meeting-preparation workflow when available.

Carry forward:

• accepted goals;
• stakeholder context;
• onboarding milestones;
• unresolved questions;
• customer dependencies;
• decisions required.

After important meetings, use the appropriate meeting-debrief workflow to preserve:

• decisions;
• commitments;
• changes;
• owners;
• dates;
• unresolved questions.

Prepare useful artifacts such as:

• onboarding plan;
• kickoff agenda;
• meeting recap;
• task list;
• customer communication;
• internal handoff notes.

5. Keep operational actions separately authorized

Treat these as separate actions:

• drafting the onboarding plan;
• sending customer communication;
• scheduling meetings;
• inviting participants;
• provisioning access;
• changing permissions;
• configuring the product;
• connecting integrations;
• moving or importing customer data;
• updating CRM or project records;
• altering billing;
• changing commercial terms.

Follow active scoped permission for each action.

Approval of the onboarding plan does not automatically authorize product changes, data movement, access changes, external communication, or commercial changes.

Verify completed system-changing actions where possible.

6. Track progress toward value

Maintain a current onboarding view containing:

• current milestone;
• milestones completed;
• evidence of value achieved;
• blockers;
• risks;
• customer-owned actions;
• internal actions;
• responsible owners;
• next customer interaction;
• next internal action;
• missing evidence;
• unresolved decisions.

Use accepted commitments when communicating dates and expectations.

Do not invent a completion date merely because progress is slower than expected.

When dates or milestones change, distinguish proposed changes from accepted changes.

7. Transition from onboarding to ongoing success

Once onboarding reaches the appropriate maturity point, transition from implementation tracking to ongoing customer health and value management.

Route ongoing assessment through the available customer-health workflow when it needs to evaluate:

• outcomes;
• adoption;
• stakeholder relationships;
• support experience;
• risk;
• expansion signals;
• unresolved blockers.

Do not declare onboarding complete solely because setup tasks are finished. Use the accepted completion or first-value evidence appropriate to the customer.

8. Preserve and improve the onboarding method

After the onboarding approach has worked, preserve reusable elements such as:

• intake checklist;
• handoff structure;
• dependency checks;
• milestone framework;
• kickoff structure;
• risk checks;
• first-value definition method;
• review behavior.

Remove customer-specific facts, credentials, commercial terms, data, and restrictions before reusing or sharing the method.

A recurring workflow may monitor accepted milestones, blockers, or exceptions when sources, owners, permissions, and review behavior are stable.

It should surface changes and prepare updates rather than silently rewriting the onboarding plan or creating new commitments.

Stop automation when:

• accepted scope changes;
• ownership becomes unclear;
• critical access changes;
• security or privacy issues arise;
• commercial terms conflict;
• milestones can no longer be verified;
• customer goals materially change.