How should the service desk handle a Microsoft 365 outage it cannot fix?

Treat a major cloud outage as a major incident, even though the fix sits with the supplier: log it, own it, and make communication your main job until service returns. Your service desk cannot repair Microsoft's platform, but it can control how quickly people know what is happening, what to do instead, and when they will hear next.

## Why it still belongs to you

When email and Teams stop working, users do not care whose data centre failed. They care that they cannot work. Treat it as somebody else's incident and you give up the one thing you can still manage: the experience of the people affected.

In The Journey to Service Excellence, John Sansbury makes the point when he discusses putting records on hold while waiting for a third party. That, he says, "is not normally a valid reason because it is outside the control of the user community and should be managed via contractual obligations with the third party." The supplier fixes the platform. You still own the incident.

## Practical steps

1. Declare it quickly. As soon as several users report the same symptoms, or the supplier's service health page confirms a problem, raise one major incident record and link every related call to it. John advises that every major incident record should include an estimate of the number of users affected.

2. Confirm from more than one source. In a big outage the supplier's admin portal and status pages can themselves slow down or fail under load. Agree in advance which other signals you will trust, such as public status channels and your own monitoring.

3. Tell people before they ask. Send one short message on a channel that does not depend on the failed service. That might be an intranet banner, a text message or a recorded message on the support line. Say what is affected, what still works, what to do instead, and when the next update will come.

4. Set an update rhythm and keep it. John's advice is plain: "It is good practice to keep consumers informed." Commit to updates at a fixed interval, even when there is no new news. Silence creates status chasing calls, which John, following John Seddon, describes as failure demand.

5. Offer workarounds, not repairs. Point people to what still works, such as phones, shared files or a paper process for urgent business work. Avoid local fixes, such as resetting accounts, that could make recovery harder.

6. Escalate through your contract. If you buy through a partner or hold a support agreement, open a case early and record the reference. That record is your evidence if you later discuss service credits.

7. Close it properly. When service returns, check with a sample of users that things really work, then send a final message. John notes that leading enterprises "raise a problem record for each major incident with the intention of preventing recurrence." With a supplier outage, that problem record is about your dependency: what you could not do, and what would reduce the impact next time.

## A short worked example

This is an illustrative example, not a client case. An organisation of 800 staff loses email and Teams on a weekday afternoon. Within ten minutes the service desk logs a major incident, links the first calls to it, and puts a banner on the intranet and a recorded message on the support line: "Email and Teams are down because of a Microsoft outage. Phones and shared files still work. Next update at 3.30pm."

Updates follow every thirty minutes, and calls fall away after the first message. When service returns, the desk checks with a few users, sends a closing message and opens a problem record. The review finds that the out of hours contact list lived only in Outlook, so an offline copy becomes an action.

The team then applies John's lost user time method (users affected, multiplied by the actual outage in hours, multiplied by the average hourly cost of employment), which gives the problem record a business case.

## Common mistakes

Waiting for the supplier to confirm before saying anything. As John puts it, "Certainly don’t wait until a service level is missed to have a conversation."

Announcing the outage on the service that is down. An email about an email outage reaches nobody.

Stopping the clock on users' incidents because the fault is with a third party.

Skipping the review because the supplier caused it. The dependency, the communication and the workarounds were yours.

## Where the standards fit

ITIL 4, now owned by PeopleCert, describes the purpose of incident management as minimising the negative impact of incidents by restoring normal service operation as quickly as possible. ISO/IEC 20000-1, the international standard for service management systems, expects organisations to manage incidents, including major incidents, and to control services that suppliers provide. Microsoft's own documentation (vendor material) explains how admins check service health in the Microsoft 365 admin center.

## Next step

For more on running the incident itself, read managing major incidents as business events or browse the incident management articles on ESM's Exchange.

If this helped, John Sansbury's The Journey to Service Excellence covers major incident management, incident costing and support centre practice in depth, and is available to Exchange members.