IT Helpdesk scope: What services are included, and which tasks must be separated?

11 hours ago

10 min read

Two vendors may both provide an "IT Helpdesk quote," but the actual scope can vary significantly. One may only receive and resolve end-user incidents; the other might include onsite support, Microsoft 365 administration, or certain infrastructure components.

Therefore, the crucial question before signing a contract is not merely what the IT Helpdesk supports, but rather: which tasks are genuinely included in the service fee, which tasks are only received and escalated, and which scenarios must be billed as add-ons or separate projects.

In principle, an IT Helpdesk typically focuses on users' daily IT operational requests, such as computers, software, accounts, office equipment, and basic connectivity. Items like system architecture changes, migrations, in-depth security administration, large-scale deployment projects, or hardware repairs under warranty should not default to being considered Helpdesk tasks.

Outsourced IT Helpdesk | Reliable SLA commitment | IPSIP Vietnam

IT Helpdesk scope should not just be a feature list

A Statement of Work (SOW) stating "support for computers, networks, email, and Microsoft 365" is insufficient to accurately define responsibilities.

For example, "network support" might just mean the Helpdesk checks the user's machine, IP address, Wi-Fi, and basic connectivity. It does not automatically imply that technicians are authorized to change routing, redesign VLANs, or reconfigure firewalls.

Similarly, "Microsoft 365 support" may include password resets, Outlook errors, and user guidance, but it does not necessarily cover changing tenant-wide policies, designing identity architecture, or handling a complex account security incident.

For a clear scope, businesses should determine at least five factors:

Supported subjects: which users, devices, sites, and systems are within the scope.
Types of work: incidents, service requests, configurations, or system changes.
Resolution levels: whether the Helpdesk handles up to L1, L2, or includes L3.
Support formats: remote, onsite, or a combination.
End points of responsibility: when to escalate to internal IT, specialized teams, vendors, or another service.

PeopleCert describes the Service Desk in ITIL 4 as a central point of contact between the service provider and users, while emphasizing the roles of processes, roles, partners, and suppliers in service delivery. This indicates that a Service Desk is primarily a communication and coordination point; it does not mean a Helpdesk team must independently resolve all arising technical tasks.

The Service Desk Institute (SDI) also views the service desk as part of a broader IT service management (ITSM) system, with criteria covering operations, people, processes, and service improvement. Therefore, the Helpdesk scope needs to be designed within an overall operating model rather than merely listing supported technology names.

If a broader overview of service roles and models is needed, businesses can refer to the article IT Support Services: A comprehensive solution for businesses in 2026. In this article, the focus is on the scope's boundaries before signing a contract.

Which tasks typically fall within the IT Helpdesk scope?

There is no single list applicable to all contracts. However, the task group most suitable for a Helpdesk usually consists of high-frequency requests that can be standardized and directly serve users' daily activities.

End-User Incidents and Requests

Common examples include:

Computers operating abnormally.
Inability to open applications.
Outlook or office software errors.
Inability to connect to Wi-Fi.
Printers not working.
Inability to log into accounts.
Password resets.
Installation of enterprise-approved software.
Usage instructions for IT tools within the supported catalog.

This is the typical task group for a Helpdesk because it can be received, categorized, processed according to procedures, and have its results recorded.

Onboarding, Offboarding, and Account Requests

The Helpdesk can also receive requests to create accounts, lock accounts, grant permissions, or provision machines for new employees.

However, "Helpdesk execution" does not mean technicians can arbitrarily determine access rights.

Microsoft divides Microsoft 365 and Microsoft Entra into multiple administrator roles corresponding to different task groups, and recommends using the least privilege necessary for the job instead of granting Global Administrator for all tasks. For instance, a password reset task does not necessarily require the highest administrative privileges.

Therefore, the SOW should clearly state which roles the Helpdesk is granted, what types of requests require approval, and which scenarios must be escalated to the system owner or an administrator with higher privileges.

Troubleshooting prior to Escalation

Another critical value of the Helpdesk is isolating issues prior to escalation.

For example, when a user reports a "network outage," the Helpdesk can check the device, IP address, Wi-Fi, network cables, and the scope of impact. If the fault is determined to be in the core network equipment or the Internet Service Provider (ISP) line, the ticket is routed to the correct responsible unit instead of leaving the user to find the provider themselves.

A comprehensive IT Helpdesk ticket makes this process more efficient because information about the user, device, impact level, occurrence time, and attempted steps are logged before escalation.

Scope Matrix: Which tasks belong to Helpdesk, are add-ons, or must be separated?

A practical way to assess the scope is not simply asking, "Does the Helpdesk do this?", but rather categorizing based on responsibilities.

Request Group	Core Helpdesk	Conditional / Add-on	Separate service or project	Vendor / Warranty
User laptop/desktop errors	Typically included	Onsite may depend on the package	–	Component repair/replaceme-nt may fall under the manufacturer
Password resets, account errors	Typically included	Special privileges require approval	–	–
Standard software installation	Typically included	Specialized software may require a specialist	Large-scale deployment may become a project	Vendor supports product errors
Outlook/Microsoft 365 user support	Typically included	Deep admin changes depend on the scope	Migration/tenant redesign	Microsoft/vendor when necessary
LAN/Wi-Fi troubleshooting	Typically included at the basic check level	Configuration changes depend on the SOW	Network redesign, large rollout	ISP/vendor if it's a service or equipment fault
Printers/office equipment	Typically included at the troubleshooting level	Onsite depends on the package	–	Hardware repair under warranty
Onboarding/offboarding	Typically included if it's a standard process	Depends on quantity and devices	Mass onboarding may require a project	–
Server administration	May only involve triage	Could be Managed IT	Major upgrades/migrati-ons	Vendor when related to the product
Firewall configuration	Typically not core Helpdesk	Minor changes if the SOW permits	Managed Firewall/project	Vendor support
Backup/restore	Helpdesk may receive tickets	Simple restores depend on the scope	Separate backup/Disaster Recovery (DR) administration	Vendor when it's a product error
Security alert investigation	Helpdesk receives/escalates	–	SOC/MDR or security team	Security vendor when appropriate
Cloud migration	–	–	Separate project	Vendor support based on the platform
Office relocation	Some user tickets	–	Separate deployment project	ISP/hardware vendor
Hardware repair	Initial diagnosis	Onsite depends on the package	–	Typically handled by warranty/vendor

Service scope exclusions: Which tasks should not default to Helpdesk?

An exclusion does not mean the provider refuses to support it. It means the task requires a different responsibility mechanism, capability, or quotation.

Major Changes and Projects

A request to install software for one employee might fall under Helpdesk. But deploying a new application to 200 computers, building a standard image, conducting compatibility testing, and planning a rollout takes on the nature of a project.

Similar scenarios include:

Office relocations.
Replacing the entire Wi-Fi network.
Cloud migrations.
Domain migrations.
Large-scale operating system upgrades.
Deploying new systems or applications.

Projects have their own scopes, deliverables, timelines, and risks, so they should not be "hidden" within an unlimited Helpdesk commitment.

In-Depth Infrastructure Administration

The Helpdesk can receive tickets related to servers, firewalls, backups, or the cloud, and perform initial troubleshooting.

However, if the contract requires the provider to be responsible for system health monitoring, patching, capacity, configuration, backup jobs, and regular infrastructure changes, the scope has moved closer to Managed IT Services.

This boundary is especially crucial when comparing quotes. An end-user Helpdesk package and a package that includes infrastructure administration are not equivalent products that can merely be compared by monthly price.

SOC and Cybersecurity Incident Handling

A user reporting a phishing email or a machine exhibiting abnormal behavior can absolutely create a ticket through the Helpdesk.

The Helpdesk can gather initial information, execute certain steps according to an approved playbook, or escalate the incident to the security team. However, continuous monitoring, threat detection, alert investigation, threat hunting, and in-depth incident response should not default to being considered Helpdesk functions.

This is the boundary between user support and security operations.

Warranty and Vendor Responsibilities

The Helpdesk should also not default to being the ultimate responsible party for all hardware or software faults.

For example, the Helpdesk can:

Diagnose laptop or device faults.
Collect serial numbers.
Open cases with manufacturers.
Track progress.
Support users during wait times.

But repairing or replacing components may fall under the manufacturer's warranty policy or support contract.

For instance, Cisco clearly distinguishes hardware warranties from operational technical support: warranties focus on the responsibility to repair or replace manufacturing defects according to the conditions of each product, whereas other technical support benefits may require a separate support contract.

This illustrates why a Helpdesk SOW should distinguish support ownership from repair responsibility. The Helpdesk can take responsibility for ticket coordination without becoming the entity that directly provides components or executes Return Merchandise Authorizations (RMAs).

L1, L2, and L3 Boundaries Should Be Defined by Processing Authority

L1, L2, and L3 are useful ways to describe escalation, but businesses should not assume all providers use the same definitions.

Atlassian notes that businesses can choose the number of support tiers suited to their models; many teams operate efficiently with two or three tiers rather than necessarily having a fixed structure. In the common tiering approach, L1 focuses on basic issues, while more complex tickets are escalated to groups with higher expertise.

A reference framework could be:

L1 receives tickets, verifies information, categorizes, resolves common errors, and executes standard procedures.
L2 performs deeper troubleshooting, handling configuration or system issues within the permitted scope.
L3 typically involves specialists, engineering teams, or vendors when in-depth knowledge or changes with a broader impact level are required.

More important than the L1/L2/L3 labels are authorities and escalation conditions.

The Service Desk Institute outlines scenarios requiring functional escalation, such as when an analyst lacks the expertise, permissions, responsibilities, or authority to resolve it; when the support model dictates another party must handle it; or when the time required exceeds the appropriate scope of the Service Desk.

Therefore, the SOW should specifically answer:

What changes is each tier permitted to make?
When must approval be requested?
What are the escalation conditions?
Who retains ownership of the ticket after escalation?
When escalated to a vendor, does the Helpdesk retain tracking responsibilities, or is the ticket closed?
How is third-party wait time calculated?

Alongside the scope, businesses should separate response and resolution time targets in an IT Helpdesk SLA.

PeopleCert describes Service Level Management as the practice of setting clear service targets based on business needs. Thus, it can be understood briefly: scope determines what is to be done; SLA defines the expected service levels for those tasks already within the scope.

Where does the Helpdesk stop when interfacing with Managed IT, Projects, SOCs, and Vendors?

A ticket can absolutely start at the Helpdesk but not end at the Helpdesk.

it-helpdesk-scope — Where can an IT Helpdesk ticket go?

For example, a user reports an inability to access a system:

The Helpdesk receives the ticket and checks the user's side.
L2 determines the issue lies with the server.
The Managed IT team checks the service or infrastructure.
If signs of compromise appear, the ticket can be escalated to the SOC.
If the root cause is a product defect, the vendor continues to handle it.

In this case, the Helpdesk's value remains significant: the user has a single point of contact, while multiple specialized groups may exist behind the scenes.

This model also aligns with the principle that a service desk must be capable of coordinating with partners and suppliers, rather than assuming all capabilities reside within the same team.

For businesses that already have internal IT, the division is similar. An external team might handle user support and L1 tickets, while internal IT retains business applications, critical change authorities, or projects. The article Having In-house IT staff: Should you still outsource your IT Helpdesk? analyzes this responsibility division model more deeply.

Which needs should use add-ons?

Not every task outside the baseline needs to be eliminated from the contract.

Many items can be designed as add-ons: the provider can still execute them but requires additional capacity, timeframes, or expertise.

For example:

Onsite support exceeding committed visits.
After-hours, weekend, or 24/7 support.
Dedicated engineers.
Addition of new branches.
Increases in user/device quantities.
Administration of an additional platform.
Execution of high-volume ad-hoc workloads.

It is necessary to distinguish:

Exclusions are items not falling under baseline responsibilities.

Add-ons are items that can be additionally provided if the business selects the corresponding scope or cost.

This definition is more transparent than using the phrase "unlimited support." It is meaningless when a service has "unlimited tickets" but fails to specify which types of tickets are in scope.

What should an IT Helpdesk Statement of Work state?

A good SOW must allow a person not involved in the sales process to read and understand the boundaries of responsibility.

Before signing a contract, businesses should clarify at least 10 points:

Supported users, devices, and sites: how many users, devices, and locations are supported.
Included services: what types of incidents and requests are covered in the baseline fee.
Excluded services: which items do not belong to the baseline.
Add-on or conditional work: which scenarios require approval or separate quotes.
L1/L2/L3 responsibilities: to what extent each tier is permitted to execute tasks.
Remote and onsite boundaries: which scenarios require onsite presence, and whether there are limits on visits or locations.
Change authority: which configurations technicians are authorized to change, and which changes require approval.
Escalation and vendor handoffs: who to escalate to, under what conditions, and who retains coordination responsibilities.
SLA dependencies: distinguish between response times, restoration/resolution times, and third-party dependent wait times.
Assumptions and limits: business hours, number of supported users, devices, sites, technologies, and other limitations.

Specifically for platforms like Microsoft 365, the change authority section should not broadly state "has admin rights." Microsoft provides multiple administrator roles for different tasks and recommends assigning the minimum necessary permissions. Thus, the SOW can explicitly stipulate to what extent the Helpdesk can reset passwords or manage users and licenses, but more sensitive changes must be escalated or approved.

For example, instead of merely stating:

Support for network issues.

The SOW could be clearer:

The Helpdesk performs L1/L2 troubleshooting for users' LAN/Wi-Fi connectivity at in-scope locations. Network architecture changes, redesigns, major configuration changes, and hardware replacements are processed according to corresponding change requests, projects, or warranty policies.

This second phrasing helps both the business and the provider know exactly where responsibilities begin and end.

In summary, when outsourcing an IT Helpdesk, businesses should not only ask "how many features are in this package?" or "are there unlimited tickets?".

Three more important questions are:

Which tickets are definitively included in the service fee?
Which tickets does the Helpdesk merely receive and escalate to another unit?
Which tasks must be processed as add-ons, Managed IT, projects, SOC, or by a warranty vendor?

Only when the scope, exclusions, escalations, and onsite models are equivalent can businesses reasonably compare two IT Helpdesk quotes.

Businesses unsure of how to scope servers, Microsoft 365, networks, onsite support, backups, or other items can schedule a consultation or request an IT Helpdesk quote to determine an appropriate scope tailored to their user count, current systems, and operating model.