Operations rejects the handover pack. How do we resolve it?
Unagreed handover acceptance criteriaCompare the rejection reasons with the service's operating needs and any agreed handover criteria. Assign specific gaps to owners and arrange a practical acceptance review. Avoid treating operations as a late obstacle when its responsibilities were never included in delivery planning.
What to do now
- List the rejected items and their operational impact
- Agree objective handover acceptance criteria
- Close the gaps with evidence
- Obtain acceptance or a documented conditional decision
When to escalate
No responsible team can operate the service safely.
The service owner and authorized operational decision maker
Example
Operations accepts the service after support access and incident routing are demonstrated, not just documented.
Mistake to avoid
Calling the handover complete because files were emailed.
Prevent a repeat
Test whether receiving teams can operate and recover the service without depending on informal project-team support.
Suggested ApprovedFlow setup
- Tasks
- Documents
- Approvals
Keep handover tasks, operating evidence and the acceptance decision linked to the project while retaining monitoring and incident control in the actual service tools. See the platform
Related cases
- Our runbook is long, but operators cannot use it. What should we change?Untested operational documentation
- Hypercare keeps extending. When should it end?Undefined hypercare exit criteria
- Our acceptance criteria change after delivery. What should we do?Moving acceptance boundary
- How do we define supplier acceptance criteria before signing?Unclear commercial verification