Handoff and escalation
A request should arrive with enough context to act-and a clear route when it cannot.
Discretion depends on operating clarity. The handoff defines what delivery may do, what must return to the partner, and how the client experiences an exception.
The minimum useful handoff
A ticket number is not context. Before recurring delivery begins, the teams should agree on a small set of fields that let routine work proceed without exposing unnecessary client information.
- Identity
- How intake and replies represent the partner firm.
- Entitlement
- Which users, environments, and request types belong in the lane.
- Context
- The user impact, relevant history, and safe technical facts needed for the task.
- Authority
- What delivery can change and what requires partner or client approval.
- Return path
- Who receives exceptions and how the decision comes back.
Escalation matrix
Route by decision type, not by whoever replies first.
| Situation | Delivery action | Partner action | Client-facing treatment |
|---|---|---|---|
| Routine included request | Work within documented scope and access. | Remain informed through the agreed record. | Consistent partner identity and approved language. |
| Scope is unclear | Pause the uncertain portion and state what is missing. | Confirm entitlement, approval, or a separate quote. | No improvised promise while ownership is unresolved. |
| Material change | Describe impact, dependencies, and rollback considerations. | Own approval and any commercial conversation. | Decision is presented through the partner relationship. |
| Security-sensitive event | Contain only within agreed authority and escalate promptly. | Coordinate the response owner and client decision path. | No unsupported incident-response or recovery claim. |
| Vendor dependency | Collect reproducible context and identify the dependency. | Own vendor entitlement when it sits outside delivery scope. | Set expectations without inventing vendor timelines. |
What a healthy escalation sounds like
It names the blocked decision, the known impact, the information already checked, and the person who must decide next. It does not quietly transfer accountability or make the delivery team the new account owner.
- StateWhat is happening and who is affected.
- BoundaryWhy the next action is outside routine authority.
- OptionsPractical choices and their dependencies.
- OwnerThe named person who approves or communicates.
- CloseThe decision and the resulting record.
Questions to resolve before launch
- Which changes can proceed without a separate approval?
- Who owns after-hours or urgent expectations?
- How are identity mistakes corrected and disclosed?
- Which vendor relationships stay with the partner?
- What evidence is retained without collecting unnecessary secrets?
Place these decisions in the onboarding sequence →
Read the after-hours and urgent-request etiquette →
Read the mistake-and-correction protocol →
Read the vendor and third-party escalation etiquette →
Decide which support tier owns a request before it escalates →
Bring one routine request and one exception.
Those two paths reveal more about fit than a generic promise to collaborate.