What does a Microsoft 365 IT Helpdesk Support, and where should the boundary be?
A Microsoft 365 IT Helpdesk typically handles day-to-day user support such as account access, basic licensing issues, Outlook, Teams, OneDrive, SharePoint, and selected repeatable admin tasks. However, areas such as tenant architecture, security engineering, incident response, migration, and major configuration changes usually require escalation or a separate project scope. The key is to define the boundary between user support, admin tasks, security escalation, and project work from the beginning.
Microsoft 365 sits at the center of daily work for many businesses. Employees use Microsoft accounts to sign in, Outlook for email, Teams for communication and meetings, OneDrive for personal file storage, and SharePoint for collaboration.
That is why “Do you support Microsoft 365?” is often one of the first questions businesses ask when evaluating an outsourced IT Helpdesk.
But that question is still too broad.
A provider may support Outlook for end users without administering Exchange Online. It may perform approved account changes without being allowed to modify Conditional Access. It may receive a suspected compromise ticket without being responsible for security investigation.

The more useful question is: How far should the Microsoft 365 IT Helpdesk go, when should work be escalated to an administrator or security team, and what should be treated as a separate project?
If the business is still defining the broader Helpdesk scope, the article on IT Helpdesk & IT Support for businesses can help establish the overall service boundary before Microsoft 365 is broken down into more detailed responsibilities.
Why should Microsoft 365 support boundaries be defined up front?
Behind the user experience are several different layers:
identity and authentication;
licensing;
Exchange Online;
Teams;
SharePoint;
OneDrive;
security policies;
tenant administration;
compliance;
migration.
Microsoft itself separates end-user resources from administrator and IT professional documentation. OneDrive, for example, provides different resources for end users and for IT professionals/admins, while Teams also separates user help from administrator documentation.
That distinction matters when Helpdesk is outsourced.
Not every Microsoft 365 ticket is the same type of work
A ticket such as: “I cannot sign in to Outlook.”
is fundamentally different from: “Please redesign the tenant-wide mail flow rules.”
Likewise: “Assign this approved Microsoft 365 license to the user.”
is different from: “Redesign the company’s licensing strategy.”
If both sides simply write “Microsoft 365 Support” into the service scope, expectations can become unclear very quickly.
The boundary directly affects SLA design
The Helpdesk can usually control how quickly it:
receives a ticket;
performs initial triage;
runs first-line troubleshooting;
escalates the issue.
But it may not control final resolution time if the issue depends on a Microsoft 365 Administrator, the Security team, or Microsoft Support.
For this reason, scope and escalation should be defined before resolution targets are agreed. Businesses can also review IT Helpdesk SLA when setting service targets across multiple support tiers.
What Does a Microsoft 365 IT Helpdesk Typically Support?
At the day-to-day operational level, a Microsoft 365 IT Helpdesk is usually best suited to requests that are:
repeatable – procedural – close to the user experience.
The scope can be grouped into five main areas.
1. Accounts and sign-in
This is one of the most natural Helpdesk responsibilities.
Common cases include:
users unable to sign in;
password resets;
locked accounts;
basic MFA support;
checking account status;
determining whether the issue is authentication-related or application-related;
helping users sign back in to Microsoft 365 applications.
Microsoft Entra separates administrative roles by task, including password reset, authentication methods, licensing, user administration, and security, rather than assuming one all-powerful administrator role.
This aligns well with a Helpdesk operating model:
The Helpdesk should only have enough privilege to perform the tasks within its approved scope.
2. Microsoft 365 licensing
Licensing can also sit within the Helpdesk scope when the workflow is clear.
Examples include:
checking whether a user has a license;
assigning a license after approval;
removing a license during offboarding;
identifying access issues caused by missing licensing;
routing unusual license requests to the correct owner.
Microsoft Entra defines roles such as License Administrator for license-related tasks.
However, Helpdesk should not automatically be responsible for:
deciding which license portfolio the organization should buy;
long-term licensing strategy;
tenant-wide cost optimization;
entitlement design across the organization.
Those are different responsibilities from fulfilling standard user requests.
3. Outlook and exchange online
For end users, Microsoft 365 email is commonly experienced through Outlook.
Helpdesk may support issues such as:
mailbox access problems;
common Outlook errors;
profile issues;
basic send/receive troubleshooting;
shared mailbox access where permission is already approved;
calendar or mailbox usage issues;
guidance across Outlook desktop, web, and mobile.
However, Outlook sits on top of Exchange Online.
Exchange Online administration includes more specialized areas such as mail flow, migration, and deeper service configuration.
Therefore, issues such as:
mail flow architecture;
connectors;
complex transport rules;
hybrid Exchange;
migration;
tenant-wide mail policy changes;
should not automatically be treated as standard Helpdesk work.
4. Microsoft Teams
At the user-support layer, Helpdesk may handle:
sign-in issues;
common meeting problems;
microphone or camera troubleshooting;
access to teams and channels;
membership requests based on approved procedures;
common file-sharing or collaboration issues;
guidance on standard Teams features.
But Microsoft also has a separate administration layer for Teams.
Areas such as:
tenant-wide Teams policy;
external access governance;
voice and calling architecture;
organization-wide configuration;
compliance-related changes;
typically require a Teams Administrator, internal IT, or a more specialized scope.
5. SharePoint and OneDrive
For OneDrive and SharePoint, Helpdesk can typically support:
file access problems;
OneDrive sync issues;
sharing guidance;
basic permission checks;
access to an existing SharePoint site;
common troubleshooting;
document library usage.
However, SharePoint administration can extend much further.
Areas such as:
SharePoint information architecture;
complex permission models;
governance;
taxonomy;
large-scale site redesign;
migration;
are generally outside normal Helpdesk BAU.
Can the IT Helpdesk perform Microsoft 365 admin tasks?
Yes, but “admin task” should be defined by specific responsibilities, not by giving the Helpdesk broad tenant-level privileges.
Some admin tasks may be suitable for Helpdesk if they are:
repetitive;
documented;
approval-based;
low-risk;
clearly permissioned;
auditable.
Before admin tasks are assigned to the Helpdesk, the business should define:
which tasks are allowed;
which role is required;
what scope applies;
who approves the action;
whether MFA is mandatory;
when elevation is allowed;
which actions must be audited;
which tasks are explicitly excluded.
When should a ticket be escalated to security?
Helpdesk may be the first team to hear about a security concern because users often report suspicious activity through normal support channels.
Examples include:
suspected account compromise;
unusual sign-ins;
phishing;
suspicious mailbox activity;
unexpected MFA changes;
risky file sharing;
suspected credential exposure.
The Helpdesk may be responsible for predefined steps such as:
Receive → Record → Initial Triage → Follow approved containment step → Escalate
That is different from performing:
full security investigation;
tenant-wide compromise assessment;
Conditional Access redesign;
security remediation decisions;
forensic analysis;
authentication architecture redesign.
A good scope should therefore answer: At what point does the Helpdesk stop, and at what point does Security or Internal IT take ownership?
Microsoft 365 Scope Matrix: how should responsibilities be split?
A practical way to define the scope is to separate each request category across four responsibility layers:

This matrix is a practical editorial framework, not an official Microsoft or ITIL taxonomy.
Its purpose is to force both sides to answer: “Who owns what?”
instead of relying on a vague line such as: “Microsoft 365 Support – Included.”
What should normally be outside the Microsoft 365 IT Helpdesk scope?
Some areas should usually be defined as exclusions or separate scopes.
Tenant Architecture
Examples include:
identity architecture design;
tenant redesign;
hybrid architecture;
administration model redesign.
Security Engineering
Examples include:
Conditional Access design;
security hardening;
advanced authentication architecture;
security governance;
DLP or compliance architecture.
Security Incident Response
Helpdesk may receive and escalate the ticket, but deeper investigation and containment should sit with the appropriate security owner.
Migration and Rollout Projects
Examples include:
tenant-to-tenant migration;
mailbox migration;
file migration;
company-wide Teams rollout;
SharePoint redesign;
large-scale data movement.
Complex Automation and Custom Development
Examples include:
custom integrations;
automation workflows;
PowerShell projects;
bespoke provisioning solutions.
The same provider may still deliver these services, but they should normally be governed and priced as separate project or specialist scopes, not assumed to be part of the monthly Helpdesk fee.
What should a business define before outsourcing Microsoft 365 IT Helpdesk Support?
Item to Define | What Should Be Clarified |
Applications in scope | Outlook, Exchange Online, Teams, OneDrive, SharePoint, and Entra-related support |
Helpdesk tasks | Troubleshooting, user guidance, and recurring service requests |
Admin tasks | Which tasks are allowed and which require approval |
Access & permissions | Roles, scope, MFA, audit requirements, and privileged access |
Escalation | When to escalate to the M365 Admin, Security team, or Microsoft Support |
SLA | Response time, resolution target, dependencies, and pause conditions |
Exclusions | Security engineering, architecture, migration, and project work |
Project boundary | Which activities must be handled as separate projects |
Applications in Scope
For example:
Exchange Online;
Outlook;
Teams;
OneDrive;
SharePoint;
Entra-related user support.
“Microsoft 365” alone is too broad.
Types of tasks allowed
The business should distinguish:
Troubleshooting
from:
Administrative Change
For example, checking a license problem does not automatically mean the Helpdesk can change the user’s license without approval.
Access and permissions
Define:
required roles;
scope;
privileged tasks;
MFA;
approval;
expiry where applicable;
audit.
Escalation
For every issue outside Helpdesk scope, define:
who owns the next step;
how quickly it should be escalated;
whether Helpdesk remains responsible for user communication;
which internal team owns the issue;
when Microsoft Support is required.
SLA
Businesses should distinguish: IT Helpdesk SLA from: dependency resolution time outside the Helpdesk.
If the vendor escalates correctly but is waiting for an internal administrator or Microsoft Support, that dependency should be reflected in the SLA model rather than debated after an incident occurs.
Exclusions and project boundaries
The proposal should clearly distinguish:
BAU support;
BAU admin;
security escalation;
project work;
migration;
consulting.
The clearer the boundary, the easier it is to compare providers on the same baseline.
How should Microsoft 365 scope be split when internal IT is already in place?
For many organizations, outsourcing Helpdesk does not mean outsourcing all Microsoft 365 ownership.
A practical operating model may look like this:
IT Helpdesk
user-facing support;
repeatable incidents and requests;
standard troubleshooting;
approved recurring admin tasks;
triage and escalation.
Internal IT/Microsoft 365 Admin
tenant configuration;
privileged administration;
complex Exchange, Teams, or SharePoint issues;
platform governance;
architecture.
Security
compromise investigation;
security incidents;
security policies;
risk decisions.
Project Team/Specialist
migration;
rollout;
major redesign;
complex integration.
This model allows internal specialists to spend less time on repetitive user-facing tickets while retaining control over higher-risk or wider-impact changes.
If the business already has an internal IT team and is deciding which responsibilities to outsource, see Should businesses with internal IT still outsource IT Helpdesk?.
How Does IPSIP Vietnam Help Businesses Define Microsoft 365 Helpdesk Scope?
A practical Microsoft 365 scope should not start with:
“Support everything in Microsoft 365.”
It should start with the actual operating environment:
which applications are in use;
number of users;
common ticket types;
level of end-user support required;
current responsibilities of internal IT;
recurring admin tasks that can be standardized;
permissions that can safely be delegated;
security events that require escalation;
which work is BAU and which work is project-based.
From there, Microsoft 365 can be brought into the Helpdesk scope by responsibility layer instead of being defined as one broad and difficult-to-measure service.
Businesses can review IPSIP Vietnam’s IT Helpdesk & IT Support service to understand the broader support model before defining a Microsoft 365-specific scope.

Before outsourcing Microsoft 365 Helpdesk support, the business should standardize the applications in use, recurring requests, admin tasks, access requirements, and escalation cases. Once those boundaries are clear, it becomes easier to define scope and compare proposals on a like-for-like basis.
Businesses can review IPSIP Vietnam’s IT Helpdesk & IT Support service or request an assessment to build a support model aligned with the current Microsoft 365 environment.
References












