Microsoft 365 Help Desk: Setup, Support Tiers and SLAs

It's 8:47 a.m. and three people can't sign in, Outlook is stuck for the finance lead, and someone in operations has just approved a sign-in prompt they don't remember requesting. Your Microsoft 365 help desk has to decide, in minutes, which of those tickets is routine and which one could be an account takeover. If your team treats them in queue order, you'll fix the printer-adjacent problem first and contain the main risk last.

That's the operational shift this guide lays out. A well-run Microsoft 365 help desk restores service fast, but it measures itself on containment and evidence preservation when identity is involved, not only on closure speed.

Which Support Tier Handles Each Microsoft 365 Request

A Microsoft 365 fault rarely stays with one user for long. When identity, email, file storage or Teams breaks, whole teams lose the tools they use to approve work, share files and talk to clients. Statistics Canada reported that 48% of Canadian businesses used cloud computing in 2023, up from 45% in 2021, making it the country's most widely used information and communications technology, according to the Statistics Canada release on digital technology use. Adoption reached 81% in information and cultural industries in 2023.

That spread explains the breadth of help desk work. You're supporting Entra ID sign-in, Outlook, Teams, SharePoint, OneDrive, permissions, device access and service availability, often in the same ticket. A password problem can be a sync fault, a Conditional Access policy, a non-compliant device, or the first sign of compromise.

Unclear ownership turns that complexity into delay. Tier 1 should resolve what's repeatable and reversible, Tier 2 should own tenant configuration and policy, and named business or security owners should approve changes that affect money, access or personal information.

Support Tier and Owner by Request Type

Agree on this matrix before go-live and print it where triage staff work. I would not launch a help desk where Tier 1 can grant admin roles, change forwarding rules, or close an unusual sign-in as a password reset. Those aren't speed wins, they're control failures.

Practical rule: If a request changes who can access data, it needs a named approver outside Tier 1, even when the technical step takes thirty seconds.

How to Set Up the Help Desk in Six Phases

Set-up fails when teams buy a ticketing tool first and invent process later. Work in phases, and don't move on until the current phase produces something a technician can use on a live ticket.

Phases 1 to 3

1. Discovery: Inventory your licences, Microsoft 365 tenant, line-of-business applications and current ticketing method. We assess a client's existing stack during discovery and integrate tools that work well, such as Microsoft 365, line-of-business applications or CRM systems, but we require our standardised stack for security-critical components like endpoint protection, password management and MDR. Keeping a working CRM is sensible, keeping three overlapping endpoint tools isn't.
2. Access model: Decide who gets admin rights before anyone needs them in an incident. We typically get admin access to endpoint management, security tools and infrastructure monitoring, while access to ERP, CRM and line-of-business systems stays with the client's team unless explicitly delegated. Document every grant, audit it and review it quarterly.
3. Policies: Write your Acceptable Use, MFA, Device, Remote Work, Incident Response and Disaster Recovery policies before the first ticket. The help desk needs rules to point to when a user asks for an exception, a personal device or a mailbox forward. Without written policy, every refusal looks personal and every approval sets a precedent.

Phases 4 to 6

1. Intake: Set up one primary channel plus a one-click button, and decide who can submit tickets on behalf of others. Multiple inboxes, chats and hallway requests guarantee lost work and unmeasurable response times. One front door doesn't mean one rigid form, it means every request lands in the same queue with the same priority fields.
2. Parallel run: Keep the old channel open for two to four weeks so users and both teams can hand off open tickets cleanly. In Week 5 of the transition, we take over support and the client's team gets a new "Help" button. Closing the old route on day one feels decisive and usually just drives requests underground.
3. Training and go-live: Walk managers through the reporting, teach staff to use the button, and run a short session on MFA and phishing reporting. People don't need a product tour, they need to know how to ask for help, how to report a suspicious prompt, and what happens next.

Finish with three checks. Every open ticket has an owner, the first week's tickets were routed correctly, and managers can see the dashboard. If any of those fails, you're not live, you're just receiving email in a new place.

Triage Tickets by Risk Instead of Queue Order

A suspected account takeover should outrank a routine mailbox request, even if the mailbox ticket arrived first. The Government of Canada's Microsoft 365 security playbook guidance supports assessing Microsoft 365 issues by security risk. Apply that principle consistently: prioritize potential harm and urgency, then use arrival time to order tickets at the same priority.

Priority Levels

• P1: Suspected account compromise, ransomware indicators, data exposure or privileged-account failure. Begin containment immediately and preserve evidence.
• P2: A department-wide disruption, such as shared mailboxes being unavailable or a team losing SharePoint access.
• P3: One user is blocked, but a workaround allows work to continue.
• P4: Licence, mailbox and setup requests that can be scheduled.

The support workflow has four steps: a user submits a ticket through the IT Button or the client's ticketing system; triage routes it to internal IT or CloudOrbis according to the responsibility matrix; the assigned team resolves it; and the team adds post-incident documentation to the runbook. Clear ownership matters: for end-user tickets, CloudOrbis handles device support and Tier 1/2, while the client's team handles internal escalations.

For P1 and P2 tickets, capture the tenant, user, device, timestamp, affected service, business impact and correlation ID at intake. Then separate service restoration from evidence preservation. Save relevant logs before deleting messages, reimaging a device or resetting an account. Speed matters, but an early cleanup can erase evidence needed to understand an identity or session incident.

Automation can speed up routing and collect required fields, while a person assesses risk and decides what to do next. That balance supports scaling small business support without losing people. Measure median time to acknowledge, median time to contain, the share of privileged accounts protected by phishing-resistant MFA, the share of incidents with complete evidence, and repeat-incident rate. Ticket closure counts alone cannot show whether the team contained risk or preserved evidence.

Ticketing Integration and Leaver Workflows

Connect Microsoft 365 and Entra ID security alerts directly to your ticketing tool. A P1 alert should open a ticket automatically, page the on-call identity engineer and carry the tenant, user and correlation ID into the record without anyone retyping them. If a technician has to spot the alert in a separate portal, your response time depends on who happens to be looking.

Set SLA timers from the priority field so the acknowledge and contain clocks start at creation, not when someone reads the ticket. If you're reviewing your tooling, our guide to choosing a help desk ticketing system that supports structured intake covers what to test before you commit. Review integration failures monthly, because a broken connector can stop P1 alerts while the dashboard still looks calm.

Four Checklists Worth Building First

1. Password reset: Push self-service first, with a verified callback as the fallback. Never verify identity through the same email thread that raised the request.
2. Sync fault: Start Outlook, Teams and OneDrive faults with a service health check, then a client reset. Tenant changes come after you've ruled out a Microsoft-side incident.
3. New starter: Assign the licence, groups, shared mailboxes and device enrolment before day one. A starter who spends their first morning waiting for access learns to work around IT.
4. Leaver: Block sign-in, revoke sessions, convert or forward the mailbox to the manager under the retention rule, review OAuth apps and group memberships, and release the licence only after the retention period ends.

Store each checklist in the runbook and configure the ticket so it can't close until every item is marked done. The leaver workflow matters most here. Blocking sign-in while leaving an OAuth consent or forwarding rule active gives you a closed ticket and an open door.

Escalate Identity Incidents as Security Events

A user reports an unexpected sign-in, and the help desk resets the password. If the attacker still has an active session, an inbox rule, or an OAuth grant, that reset has not contained the incident. Treat identity and session alerts as security events, with response measured by containment and evidence preservation as well as ticket closure. The Government of Canada's Microsoft 365 security playbook recommends enforcing MFA through Conditional Access, disabling SMS-, email- and voice-based legacy MFA, and using phishing-resistant MFA where feasible.

The Six Step Escalation Sequence

1. Verify independently: Call the user on a known number. Do not rely on the email thread, Teams message, or signature details from a potentially compromised account.
2. Inspect sign-in logs: Check Entra ID for unfamiliar locations or devices, impossible travel, repeated MFA prompts, and legacy authentication attempts. Preserve relevant evidence before taking actions that could affect the investigation.
3. Revoke, then reset: Revoke active sessions and refresh tokens before resetting credentials. Otherwise, an existing session may remain active after the password changes.
4. Require phishing-resistant MFA: Where possible, move the user to FIDO2 security keys or passkeys and away from SMS, email, and voice codes.
5. Hunt for persistence: Review mailbox forwarding rules, OAuth app consent, SharePoint and OneDrive sharing links, and privileged role changes. Check mail flow exposure as part of the investigation; a DMARC test from mailX can help identify domain spoofing exposure relevant to follow-on phishing.
6. Document for review: Record indicators, containment actions, evidence preserved, and user impact so privacy and security leads can assess the incident.

A password change alone is not containment. Revoke sessions, inspect mailbox rules and app consent, and document what was found before closing the incident. Repeated Authenticator prompts also need investigation. Do not approve them automatically; review the login context and treat unexpected prompts as a possible sign of account compromise.

A clear identity and access management policy defines who can investigate, revoke sessions, change authentication requirements, and approve recovery. See these Microsoft 365 identity and access management controls when setting escalation responsibilities.

CloudOrbis provides 24/7 coverage for security incidents and infrastructure issues. The useful measure is whether the response contains phishing, session theft, or failed recovery attempts and preserves evidence, including outside business hours. A ticket closed after a password reset can still leave an attacker with access.

Permissions and Copilot Readiness Checks

Copilot doesn't create a new permission breach. It makes an existing one far easier to find, by letting any authorised user ask natural questions across everything they can already access. Canadian reporting based on Statistics Canada data notes that 19.2% of Canadian businesses used AI to produce goods or deliver services in the previous 12 months, up from 6.1% in 2024, with cybersecurity and privacy concerns identified as the most common barrier by 13.4% of businesses, as summarised in this overview of Microsoft 365 Copilot for Canadian organisations.

Pre Deployment Checks

• Overshared sites: Inventory SharePoint sites and Teams where membership has grown by accretion rather than design.
• Anyone links: Find anonymous sharing links and check which ones point to sensitive folders, then remove what has no current purpose.
• Stale guests: Remove guest accounts with no remaining business reason, and confirm owners for the rest.
• Inherited permissions: Check document libraries where a top level change exposes content below.
• Inactive Teams and delegation: Archive inactive Teams that still hold sensitive files, and remove mailbox delegations that no longer match roles.
• Retention labels: Confirm labels are applied to records that must be kept or deleted on schedule.

Then answer the policy questions in writing. Where is data stored and processed, what does your contract say about Canadian data residency, what are the acceptable use rules for generated content, who reviews AI output before it reaches a client, and how do you handle prompt injection through malicious documents. Our notes on Copilot privacy considerations for business use cover the contractual questions to ask.

If a sensitive file is found overshared, restrict it first, log the change, then review who accessed it. Investigation before restriction leaves the exposure running.

Treat readiness as an access governance and information lifecycle project, not a training task with a licence purchase attached. Training helps after permissions are right. Before that, it just teaches people to search a broken structure faster.

SLA Template and Reporting Targets

Use the targets below as a starting template, then tune them after the first 60 days of real tickets. Targets set without baseline data are either unachievable or so loose they hide problems. Our guide to SLA monitoring and reporting discipline explains how to keep the numbers honest once you're live.

Starter SLA Template by Priority

There's a Canadian benchmark worth building into your P1 and P2 escalation path. Federal institutions must report a material privacy breach to the Treasury Board of Canada Secretariat and the Office of the Privacy Commissioner of Canada no later than seven days after determining that the breach is material, under the Treasury Board breach management guidance. Provincial and sector rules may apply to private organisations, but that seven day threshold tells you how fast a compromised mailbox or malicious forwarding rule must reach your privacy lead. It can't sit in a queue for a week first.

Reporting should match that seriousness. Leadership receives three tiers from us, a Monthly Operational Report covering tickets, recurring issues, asset inventory and response times, a Strategic Technical Review for quarterly budget forecasting and hardware lifecycle planning, and a Cybersecurity Compliance Report covering training completion, phishing results, patch compliance and insurance-ready documentation, all through a manager dashboard. If your monthly report only counts closed tickets, it can't support a cyber insurance renewal or a budget conversation.

Decide Between In-House and Outsourced Support

Make the decision against criteria, not habit. The honest questions are uncomfortable, which is why teams skip them.

• After-hours coverage: Who responds to a security incident at night, and is that arrangement sustainable or just one person's mobile phone.
• Identity depth: Do you have a specialist who can run an Entra ID escalation at 6 p.m. on a Friday, including session revocation and OAuth review.
• Scale: How many Microsoft 365 users depend on the service, and how lumpy is demand around onboarding and month end.
• Data residency: Does any client contract require support or data handling in Canada. We provide live support 24/7/365 from a Canadian-based team.
• Delegation comfort: How much admin access you're willing to grant, and how you'll audit it.

Most small and mid-sized teams land in the middle, and I'd recommend that split for the typical case. Keep business owner decisions in-house, such as licence approval and access to line-of-business systems, and outsource triage, monitoring and after-hours response where coverage is thin. If email volume itself is part of the problem, Sickle's guide to email management is a useful companion read on reducing mailbox load before it becomes ticket load. Our comparison of break-fix support versus managed services lays out the cost trade-offs in more detail.

Review the choice after the first quarter using SLA results and repeat-incident rate, not gut feel. This week, list your current Microsoft 365 licences, admin roles in use and open ticket volume for the last 90 days, then bring those figures to a Discovery Call, where we offer a personalised walkthrough of our support platform, policies and reporting. You can also reach us at 1-888-755-3022.

If your Microsoft 365 help desk is closing tickets quickly but can't show containment times, evidence records or who approved the last admin role change, it's time to rebuild the model rather than add headcount. CloudOrbis Inc. runs a 24/7 Canadian-based help desk with structured triage, identity incident escalation and reporting your leadership and insurers can use. Visit CloudOrbis Inc. to book a Discovery Call and compare your current support against the tier map and SLA targets in this guide.