What should businesses do during a Microsoft outage? An emergency guide for small businesses

What should a business do first during a Microsoft outage?

For a five-person company, the coordinator may be the owner or office manager. For a larger organisation, separate the technical investigation from operational decisions. Whoever takes the role should be able to contact your IT provider and the people who approve changes to working practices.

Do not wait for a perfect explanation before giving basic instructions. Staff can be told how to report urgent requirements, where updates will appear and what information must stay within approved systems. That reduces duplicated investigations and stops well-intentioned workarounds spreading without oversight.

What should your emergency checklist cover in the first 15 minutes?

1. Name the coordinator and deputy. Make sure both can be contacted without the affected platform.
2. Capture the symptoms. Record failed tasks, affected users and approximate start times.
3. Ask IT to check service health. Compare the provider advisory with what your business is seeing.
4. List urgent work. Identify customer commitments and decisions that need attention today.
5. Send one staff instruction. State the reporting route, approved workaround and next update.
6. Start a decision log. Record changes, approvals and work to reconcile later.

Keep this proportionate. A spreadsheet or controlled paper log may be sufficient if your business already permits it. The important point is that information has an owner and a destination. Avoid placing sensitive operational details in a public chat simply because it is easy to reach.

Check that the nominated deputy understands the arrangement. If the coordinator is dealing with a customer call or becomes unavailable, the response should continue without everyone having to make their own decisions.

How do you confirm whether Microsoft or your own IT is the problem?

Ask your administrator to review Microsoft 365 Service health and test a small sample of the actions that are failing. Microsoft explains how authorised administrators can review incidents and advisories in its service-health guidance. Use the public status page if the normal admin view cannot be reached.

Gather evidence without turning every employee into a troubleshooter. Does the same task fail on more than one approved device? Are remote staff and office staff affected? Can people open unrelated business systems? Record the results rather than repeatedly retrying the same action without a purpose.

These checks narrow the investigation; they do not prove a cause on their own. A wider Microsoft incident and a local network or account problem can exist together. Your remote IT support provider should distinguish them and explain which actions, if any, the business needs to take.

Who should make decisions if you do not have an internal IT department?

Assign three responsibilities, even when one person holds more than one. The business coordinator sets priorities and approves operational exceptions. The IT contact assesses technical evidence and proposed changes. A communications owner keeps staff and customers informed through an approved route.

Give the IT provider a contact who can make decisions. An engineer may identify a practical alternative but cannot decide which customer obligation your business prioritises. Agreeing that boundary prevents delay and avoids technical staff becoming the default owners of commercial decisions.

Which work should you prioritise in the first hour?

Choose activities by consequence and time sensitivity. Ask what becomes materially harder if it waits one hour, half a day or until tomorrow. Consider essential customer contact, delivery coordination, time-sensitive approvals and the information needed to keep existing operations safe.

Write down the minimum acceptable outcome for each activity. A customer may need confirmation by telephone rather than a fully formatted email. A supplier may need an agreed order reference rather than access to your whole procurement platform. This keeps the response focused on the business result.

Do not label every task critical. A short ordered list gives staff permission to pause lower-priority work and helps managers allocate attention. Revisit the list if the incident continues, because a task that could wait at nine o’clock may become urgent later in the day.

How can you communicate when Outlook and Teams are unreliable?

Use a channel your organisation has approved and can access independently of the affected service. That may be business telephony, a website notice or another established communication system. Confirm who maintains the contact list and avoid assuming that an internet calling service will work without testing it.

Separate general status information from confidential detail. A public page can explain delayed responses and provide your published telephone number. It should not contain account identifiers, client information or internal access instructions. Staff-only messages need an appropriate controlled route.

If the fallback is telephone contact, decide who takes calls and records urgent requests. Otherwise, colleagues may receive conflicting information or the same issue may be logged repeatedly. Check that remote workers and part-time staff know where the next update will appear.

What should your first staff message say?

Add the actual coordinator, contact route and update time before using the message. State which services you have tested and which remain uncertain. If staff cannot use the usual helpdesk portal, give them an approved alternative rather than asking them to submit tickets through a system that also fails.

Avoid implying that all problems are covered by the outage. Ask staff to report suspicious messages, unfamiliar authentication requests or unusual device behaviour separately. Clear instructions should reduce noise without hiding evidence of an unrelated security or technical problem.

How should you handle urgent customer enquiries?

Identify customers who need an immediate response and assign someone to contact them through known business details. Explain the impact on your communication, the next practical step and when they can expect an update. Do not promise a Microsoft recovery time your business cannot substantiate.

A brief website notice can reduce repeated enquiries if your public site remains available. Ask a colleague to check the notice from outside the normal working environment. Ensure that the telephone number or alternative form it provides is monitored and actually usable.

Record urgent requests in an approved location, with a reference, owner and follow-up time. When email returns, use that record to reconcile what was agreed. This matters particularly where staff discussed an order, appointment or specification that would normally be confirmed through email.

Can employees use personal email or messaging apps to continue working?

Not by default. A service loading successfully does not make it an approved place for company information. Personal accounts may fall outside your access controls, retention arrangements and normal oversight. Ask the authorised business owner and IT contact to assess an alternative before staff begin using it.

Consider the information involved, who receives it, access restrictions and the ability to recover the record afterwards. A general update that the office is experiencing delays is different from a payroll file or client case record. Apply the organisation’s existing information-handling rules.

If no suitable alternative is available, it may be better to pause a task than create an uncontrolled copy of sensitive information. Record the interruption and escalation. An emergency process should explain how exceptions are approved rather than rely on individual employees improvising under pressure.

Can staff work offline without losing control of documents?

Where approved files are already available on managed devices, staff may be able to continue preparing work. Confirm that the required material is actually local before relying on it. Offline access varies by application, settings and the information previously downloaded; it should not be assumed for every document or mailbox.

Agree a document owner and a temporary working location. Include a clear file name, date and version reference. Ask colleagues not to edit competing copies unless the process owner has arranged how they will be combined. A visible ownership rule is easier to reconcile than several files called final.

Keep devices protected and follow normal storage requirements. When service returns, compare the temporary work with the authoritative version before replacing anything. Our Microsoft 365 support services can help review the administration and working practices behind these arrangements.

What should finance teams do about payments and approvals?

Keep the normal authority and verification process in place. If an approval cannot be obtained through the usual system, use the documented alternative and confirm that the person approving has the right authority. A technical interruption does not make an unexpected bank-detail change trustworthy.

Do not repeatedly submit a payment, invoice or transaction just because a confirmation message failed. First establish whether the underlying action completed. The responsible finance colleague should check the appropriate system and record the outcome before deciding whether a retry is necessary.

Maintain a controlled list of items awaiting approval or communication, including owners and deadlines. Where a professional or regulatory obligation may be affected, escalate through the business’s established process. The specific requirements depend on the organisation and activity, so avoid treating a generic outage checklist as a substitute for that process.

What should operations, manufacturing and construction teams do?

Focus on the information needed to carry out current work safely and accurately. Confirm how supervisors receive urgent changes, whether approved instructions are available and who can authorise a temporary process. A working production or site system may still depend on email for an important approval or notification.

Use existing escalation and safety procedures where information is unavailable. Do not guess a specification, dispatch instruction or access permission because the normal confirmation route is down. Escalate the decision to the authorised person and record any approved alternative.

For multi-site businesses, check each location’s needs rather than send one assumption to everyone. A central office may be able to prepare paperwork offline while another location needs immediate supplier contact. Assign a local contact and use a shared incident coordinator to keep instructions consistent.

What should your IT team avoid changing during the outage?

Avoid speculative bulk changes that do not address established evidence. Reinstalling software for everyone, replacing mail profiles or changing domain records can introduce another problem and consume the time needed for coordination. Keep necessary incident actions separate from unrelated maintenance.

For each proposed intervention, ask what observation supports it, who approves it, which users it affects and how it can be reversed. Keep a record of the starting state and the result. That allows another engineer to understand the response without repeating the same experiment.

Do not turn off authentication or endpoint protections to work around a service error. Where a separate compromise or local fault requires action, treat that work on its own evidence. A provider incident should narrow inappropriate troubleshooting, not prevent justified technical investigation.

How do you protect the business from fake outage-support messages?

Give staff a known support route and remind them that unexpected callers cannot prove their identity by mentioning the outage. A familiar logo, a plausible explanation or knowledge of your software is insufficient. Verify a request through contact details your business already trusts.

Staff should not disclose passwords, approve unfamiliar sign-in prompts or install remote-access tools following an unsolicited instruction. Report the request through the established incident route. Preserve relevant details without forwarding harmful links widely through the business.

Keep payment and supplier checks intact when normal communications are disrupted. Our managed security services and incident response planning resources can support a wider review of how reporting, technical investigation and business decisions connect.

What should you record while the incident continues?

Keep a concise log that another authorised person can understand. Include the time, affected activity, evidence, decision, owner and next action. Mark estimates as estimates. A screenshot is more useful when it is attached to a specific task and time rather than left in an unstructured message thread.

Limit personal information and technical access details to what is necessary and appropriately protected. The log should help the response, not become an uncontrolled collection of client data or credentials. Agree its final storage location after the incident.

What changes if the outage lasts several hours?

Review priorities at agreed intervals. A workaround suitable for thirty minutes may be unsuitable for an entire working day. Check staff capacity, customer expectations and the volume of temporary records. Decide explicitly which activities should continue and which should pause.

Consider handovers between shifts or working days. The next coordinator needs the current impact, approved alternatives and outstanding decisions. Do not rely on one person’s memory or a conversation in an unavailable chat. Make sure the deputy can access the incident log through an approved route.

If necessary, update customer notices and explain revised response arrangements. Avoid sending a fresh message for every minor technical observation. Communicate when the business impact changes or the promised update time arrives, and distinguish confirmed information from pending investigation.

How do you restart safely after Microsoft services recover?

Use staged checks before declaring normal working. Confirm essential actions with representative users, then review processes that were paused or completed manually. Service access returning is a starting point for reconciliation, not proof that every delayed task finished successfully.

1. Test internal and external communication with authorised accounts.
2. Confirm access to required files and shared working locations.
3. Check the status of queued correspondence before resending it.
4. Review failed integrations and any work they completed before stopping.
5. Reconcile manual orders, approvals and customer commitments.
6. Update staff instructions and remove obsolete public notices.

Ask the relevant application owner to assess retries. A process may have created a record but failed at the notification stage. Replaying it without checking can create duplicates. Keep an owner for every recovery exception until it is resolved.

What should a small business improve before the next interruption?

Choose a few changes tied to the problems you experienced. Examples include an approved contact list available independently of email, a written customer-notice process and a clear owner for automation recovery. Avoid buying a new tool before you understand the working requirement.

Test the plan with a short discussion using fictional information. Can staff contact the coordinator without Microsoft services? Can they identify the right document owner? Can the deputy explain the recovery checklist? The exercise should not interrupt live systems or create real customer confusion.

Use our business continuity plan template to record the arrangement. Review it when people, applications or locations change. A maintained, usable process is more valuable than a lengthy plan that cannot be reached when needed.

What if you cannot contact your usual IT provider?

Use the alternative support details in your agreement and nominate one person to make contact. Record the attempted routes and times. If you seek another provider, explain the immediate requirement, the systems involved and who can authorise access. Do not send passwords or unrestricted administrator details in an initial enquiry.

Ask what assistance is available, what it costs and which responsibilities the provider can accept before work begins. A first conversation does not create an ongoing emergency-support agreement. Keep technical access transfers controlled, and ensure that your business retains a record of any accounts or permissions used during the intervention.

How can NetMonkeys help a business prepare and respond?

NetMonkeys can assess Microsoft 365 administration, support arrangements, security responsibilities and continuity processes. During a provider incident, the practical role is to clarify your impact, investigate separate local faults, support approved workarounds and organise recovery checks. An IT provider cannot promise control over Microsoft’s restoration timetable.

For small businesses, the starting point is a scoped conversation about users, applications, working hours and the tasks that cannot wait. Discuss managed IT support or small business IT support around those requirements rather than an assumption that every business needs the same package.

For the dated account of the November disruption, read our Microsoft 365 outage report. For current status, ask your administrator to check the applicable advisory or consult Microsoft’s public service-status page.