Working Start something skill
Recover a failed onboarding
Diagnose and recover a stalled customer onboarding while preserving access, data, commitments, and trust.
Restore progress from the customer's actual blocked state rather than restarting a generic checklist. Define first value jointly and reduce the path to the smallest safe sequence.
Inputs
- Gather the agreed outcome, onboarding plan, timeline, owners, product state, support history, and commitments.
- Confirm access, configuration, migration, integration, training, security, and procurement dependencies.
- Identify customer impact, cancellation or renewal risk, and any irreversible or regulated operations.
Procedure
- Acknowledge the stalled outcome and assign one recovery owner with authority to coordinate.
- Reconstruct the onboarding chronology, expected milestones, observed failures, and unresolved promises.
- Define first value with the customer as an observable result, not a completed internal task.
- Diagnose the blocking layer using product evidence and short verification checks.
- Separate critical-path work from optional configuration, customization, and future optimization.
- Build a dated recovery plan with owner, dependency, proof, fallback, and customer decision for each step.
- Fix access or data problems through approved channels without asking for shared credentials.
- Run a small end-to-end success case before scaling migration, users, or automation.
- Confirm the customer can repeat the key workflow and knows where support and ownership sit.
- Review the failed onboarding for reusable product, process, documentation, or expectation fixes.
Boundaries
Do not conceal failure, reset customer data, weaken security, or change production configuration without permission and rollback. Never ask the customer to share credentials or regulated data in ordinary messages. Keep commercial remedies and contractual commitments with authorized owners.
--- name: recover-a-failed-onboarding category: start description: Diagnose and recover a stalled customer onboarding while preserving access, data, commitments, and trust. Use when a new customer cannot reach first value because setup, migration, integration, training, or ownership has failed. --- # recover-a-failed-onboarding Restore progress from the customer's actual blocked state rather than restarting a generic checklist. Define first value jointly and reduce the path to the smallest safe sequence. ## Inputs - Gather the agreed outcome, onboarding plan, timeline, owners, product state, support history, and commitments. - Confirm access, configuration, migration, integration, training, security, and procurement dependencies. - Identify customer impact, cancellation or renewal risk, and any irreversible or regulated operations. ## Procedure 1. Acknowledge the stalled outcome and assign one recovery owner with authority to coordinate. 2. Reconstruct the onboarding chronology, expected milestones, observed failures, and unresolved promises. 3. Define first value with the customer as an observable result, not a completed internal task. 4. Diagnose the blocking layer using product evidence and short verification checks. 5. Separate critical-path work from optional configuration, customization, and future optimization. 6. Build a dated recovery plan with owner, dependency, proof, fallback, and customer decision for each step. 7. Fix access or data problems through approved channels without asking for shared credentials. 8. Run a small end-to-end success case before scaling migration, users, or automation. 9. Confirm the customer can repeat the key workflow and knows where support and ownership sit. 10. Review the failed onboarding for reusable product, process, documentation, or expectation fixes. ## Boundaries Do not conceal failure, reset customer data, weaken security, or change production configuration without permission and rollback. Never ask the customer to share credentials or regulated data in ordinary messages. Keep commercial remedies and contractual commitments with authorized owners. ## Done - The recovery plan identifies the verified blocker, critical path, owners, dates, and fallbacks - A representative first-value workflow has been tested end to end - Access, migrated data, configuration, and customer commitments are reconciled - The customer confirms the next state, and prevention actions have named owners