Support operating model / Microsoft 365

Microsoft 365 support for businesses

A Microsoft 365 support agreement needs task ownership, covered hours and escalation rules. A list of Microsoft products is not a usable service description.

A small company rarely notices the boundaries of its Microsoft 365 support until a vital user cannot sign in. Someone can reset a password, but who is authorised to approve access, who owns a suspicious forwarding rule, and who tells the finance team when a shared mailbox has stopped receiving invoices?

Good support is not simply a person who knows where the admin centre lives. It is an agreement describing the request channel, authority to act, response expectations, and which security or business decisions remain the customer's responsibility. That agreement matters even more for organisations whose internal administrator handles IT alongside another job.

The operating principle

An acknowledgement is not a resolution

A response-time target says when a qualified person will examine a reported problem; it does not promise that Microsoft, a third-party supplier or a customer's own approver can resolve it inside the same window.

01

Define the incidents the service will actually own

Create a support catalogue organised around recurring work: user access and enrolment, mail routing, groups, Teams and SharePoint membership, licensing changes and configuration review. For each task specify the evidence the requester must provide, the approval owner, expected service hours, and whether it can be performed with delegated permissions rather than permanent global administrator access.

Exclude adjacent areas explicitly. Device repair, on-premises networks, bespoke application incidents, SOC monitoring, legal advice and Microsoft platform outages may require other teams. A vendor should be able to say how it coordinates such problems without pretending that a Microsoft 365 administration retainer makes it responsible for everything.

Request typeCan a managed admin act?Required customer decision
New employee accessProvision within approved role and templateEmployment status, required permissions
External SharePoint accessApply the authorised sharing policyWhether the external party should receive access
Mail-flow failureTriage tenant and routing configurationBusiness priority and escalation owner
Licence purchasePrepare allocation and price impactBudget and procurement approval
02

Write the severity model around business impact

A locked-out employee and a company-wide inbound mail failure should not enter exactly the same queue. Define the incident categories, contact channel and business hours that matter to your organisation. Name the person who can authorise out-of-hours work and how an emergency will be reported if Microsoft 365 itself is unavailable.

Clarify how dependent providers affect recovery. Microsoft may own the service platform; an ISP or DNS provider may own a separate failure; the customer may own a policy approval. The administrator should keep one readable incident log that distinguishes diagnosis from remediation and records who is waiting for whom.

Documented administration controls

  • Agree one request channel and an alternative for mail outages
  • Define severity by affected service and business impact
  • Specify covered hours, escalation and exclusions
  • Record approvals for access, retention and purchase requests
  • Agree how changes and incidents will be documented
03

Make handover and exit part of the package

The provider should start with a tenant inventory, named account owners, domain list and existing issues. Every changed permission or policy needs a record that survives staff turnover. Keep documentation in a customer-owned location with a process to remove provider access when the arrangement ends.

Review recurring tickets after the first operating period to distinguish genuine daily administration from one-off engineering. A small business might need a periodic review rather than a large monthly retainer; a complex tenant may need a specialist project before routine support can begin. The best commercial model reflects those differences.

04

A support service needs an explicit severity and ownership model

A single user unable to find a document and an organisation-wide inability to receive mail require different response processes. Define severity by business impact, not by how loudly a ticket is written. Identify the customer contact who can declare a business-critical event, the support channel available during agreed hours and when an issue moves to a specialist engineer, Microsoft support or the client's security response team.

Separate acknowledgement, first technical assessment, workaround, resolution and customer verification. None are interchangeable. If service targets are proposed, record the staffed operating window, permitted exclusions, major-incident process and how performance will be measured. Do not advertise 24/7 monitoring without a genuine staffed arrangement.

Request typeLikely first ownerAcceptance
User cannot access shared folderService desk plus data ownerUser has appropriate approved access
Tenant-wide external mail failureMessaging specialist / customer incident ownerExternal send and receipt independently verified
New joiner and licence changeApproved customer requester + administratorCorrect role, licence and sign-in tested
Unexpected privileged consentSecurity or identity escalationRisk assessed, approved remediation verified
05

Design the handover before the first ticket

Customer-owned documentation should cover the administrative contacts, supported products, existing incidents, privileged roles, apps, backup or retention responsibilities, approved requesters and renewal dates. Define how urgent requests are identified, how requests from unapproved people are handled and when customer consent is required for a change affecting other users.

A recurring service without an exit plan creates avoidable lock-in. Record how the client retains billing, domains, tenant ownership and emergency access; how unresolved tickets are exported; and how supplier privileges are revoked after a replacement provider takes over.

Documented administration controls

  • Severity tied to actual business impact
  • Supported hours and channels written down
  • Requester identity and approval verified
  • High-impact changes reviewed by accountable owner
  • Exit runbook and client-controlled administrator access documented
A support contract should be understandable to the people requesting help and to the person approving the monthly spend. If it cannot say who acts, who decides and when, its headline price is not useful.

Primary technical references

Check current feature and licence requirements before changing a tenant. A service description is not evidence that a customer has purchased or activated an option.

Commercial next step

Define the support boundary first

Share your user count, Microsoft 365 workloads, recurring issues and hours when cover matters. We can scope an administration assessment before discussing a service agreement.

Request an administration assessment