Handoff etiquette
"It's Microsoft's fault" is sometimes true - and never the end of the conversation.
Some requests are blocked by a vendor, an ISP, or a piece of hardware nobody in the relationship controls. Whose case it is, and what still happens while it is open, needs to be as clear as any routine request.
Whose case is it?
Entitlement usually stays where the contract is.
| Dependency | Who typically holds the entitlement | What delivery can still do meanwhile |
|---|---|---|
| Microsoft 365 service incident | Whoever holds the tenant's support entitlement - usually the partner or the client's existing agreement. | Confirm the incident against service health and communicate what is known. |
| ISP or connectivity outage | The account holder of the connectivity contract. | Rule out what is inside the qualified lane and report the outage plainly. |
| Third-party SaaS vendor | Whoever owns that vendor relationship - often the client directly. | Gather reproducible detail and route it to the right owner. |
| Hardware manufacturer warranty | The device owner, per the endpoint boundary already qualified. | Confirm whether the device is in or out of the supported pattern. |
The etiquette
Five steps keep a vendor-blocked request from stalling silently, without pretending delivery controls a vendor's own timeline.
- IdentifyConfirm the dependency is genuinely outside the qualified lane - not just unfamiliar.
- ReproduceCollect the reproducible detail a vendor case actually needs, without inventing a diagnosis.
- RouteSend it to whoever holds the entitlement, named in the boundary table above.
- CommunicateTell the partner what is known, what is not, and who is waiting on whom - plainly, without inventing a vendor timeline.
- RecordClose the loop in the operating review so a repeated vendor gap becomes a visible pattern, not a recurring surprise.
What not to imply
A vendor dependency is not licence to overpromise.
- A response time or SLA that delivery does not control
- That "we're escalating it" means a resolution is imminent
- A specific vendor case number, timeline, or outcome that has not actually been confirmed
- That connectivity troubleshooting includes authority over the ISP's own contract or account
Naming a boundary honestly, mid-incident, protects the partner relationship more than a reassuring guess ever does.
Read the correction protocol for when delivery itself gets it wrong →
Related decision
Microsoft 365 vendor cases are the most common version of this.
Licensing decisions, tenant health, and vendor case ownership already have their own qualification path - this etiquette is what happens the day an incident actually blocks a request.
Bring one vendor-blocked example, if you have one.
A single real, or plausible, case - what was blocked, and who needed to act - tests this etiquette better than a hypothetical policy discussion.