Onboarding
Part of Customer success plans
Linking each success milestone to an owner and date
Make an ongoing success-plan milestone actionable with a completion condition, accepted owner, feasible date, dependency and evidence.
For every ongoing success-plan milestone, record the completion condition, one accountable owner and a date that owner has accepted. Put the dependency and evidence beside it. Then a threatened date becomes a decision both sides can resolve.
Choose milestones that advance the current outcome
Start with the customer's agreed result and work after first use. Select points where evidence or a decision will change the route towards that result. A meeting scheduled, an email sent or a feature demonstrated can be useful work, but these are weak milestones unless completing them settles something material.
For a hypothetical approvals customer already using the product, a milestone might be “the operations owner approves the revised approval policy for the ongoing workflow”. The plan should say which policy version will be reviewed and what approval permits the team to do next. Detailed configuration tasks can stay in a delivery tracker.
Weak vs Strong Success Milestones
- Weak Milestone Example
- A meeting scheduled or email sent
- Strong Milestone Example
- Operations owner approves revised approval policy for ongoing workflow
Put ownership where the decision sits
A provider success manager can coordinate the plan without being able to approve the customer's policy, grant access or fix a technical fault. Name the person accountable for the milestone and the people whose input it needs. Confirm the assignment with the named owner, especially when that person was absent from the planning conversation.
A compact milestone line can read:
Field / Example for a hypothetical account
- Completion
- Operations owner approves the revised policy for the agreed workflow
- Accountable owner
- Named customer operations owner
- Dependency
- Provider explains any configuration changes the policy would require
- Target date
- Date accepted by the owner after the dependency is checked
- Evidence
- The owner's approval of the identified policy version
- Next check
- Agreed point before the target date to inspect the dependency
The table is a proposed way to record work, not a completed account plan.
Set a date the sequence can support
Work backwards from when the decision matters to the customer's work. Ask when the required input can be ready, who must review it and how much time the decision needs. If the dependency is unresolved, mark the date provisional and name who will settle it. A calendar entry alone does not show agreement.
Where a later milestone needs live workflow evidence, check when eligible work is likely to occur. Use an earlier readiness check if necessary and keep the live-evidence date separate. Label each check honestly.
Update the line when reality changes
At the next check, compare the evidence with the completion condition. If the milestone is blocked, record the cause, response owner and next update. If the customer changes the task or the owner leaves, confirm a replacement and revisit dependent dates. Retain a short note explaining the change so later readers can distinguish a revised plan from a missed commitment.
