Onsite IT Support Services: A Scope-of-Work Template You Can Copy

Quick answer: A scope of work (SOW) for onsite IT support services should define eight things: sites covered, the task catalog, technician authority limits, priority levels and response targets, site access requirements, parts handling, closeout documentation and pricing mechanics. Techmate works from scopes like this across 450+ US cities. The template below gives sample language for each.

Most onsite IT support problems are not technical. They are contractual. A technician arrives and is not sure whether they are allowed to replace the switch or just diagnose it. A site manager did not know anyone was coming. The invoice shows a two-hour minimum nobody remembered agreeing to.

A clear scope of work prevents nearly all of that. This guide walks through each section of an onsite IT support SOW, explains why it matters, and gives you sample language to copy, edit and send to any on site IT support company you are evaluating. It is written for IT leaders who manage multi-location IT support across offices, branches and stores, where one vague clause gets repeated at every site.

What is a scope of work for onsite IT support?

A scope of work for onsite IT support is the document that tells a provider exactly what physical IT work they will perform, where, how fast and to what standard. It usually sits under a master services agreement (MSA), which handles legal terms like liability and termination. The SOW handles the operational details.

Think of the MSA as “how we work together” and the SOW as “what we are actually doing.” You can have one MSA and several SOWs: one for ongoing onsite IT support services, another for a refresh project, another for a new office build-out. Our guide to SOW vs MSA for IT field support covers which terms belong in which document.

Which sites should the SOW cover? (Section 1)

List every location in scope. For each one, include:

Site name and full address
Site type (office, warehouse, clinic, retail, colocation, home office)
Business hours and time zone
Primary and backup site contact with phone number
Access notes (badge, escort required, loading dock, parking)
Location of network closet, MDF or IDF

Sample language: “Provider will deliver onsite IT support services at the locations listed in Appendix A. Customer will maintain Appendix A and notify Provider of additions or removals at least five business days before the change takes effect.”

Keeping the site list in an appendix means you can update it without renegotiating the SOW. Give each site a stable site ID and use it on every ticket, invoice and report so data lines up across systems. If you plan to open offices in new markets, ask the provider to confirm coverage for those cities before signing, not after.

What tasks belong in the task catalog? (Section 2)

This is the heart of the document. Instead of describing a role (“a desktop technician”), list the tasks. Group them into categories so it is easy to see what is in and out.

Category	In scope examples	Out of scope examples
End-user devices	Laptop and desktop diagnosis, component swaps, reimaging from provided image, peripheral setup	Personal devices, data recovery from failed drives
Printers and peripherals	Troubleshooting, toner and part replacement, driver installs	Printer lease management
Network	Switch, router, firewall and access point swaps; cable tracing and patching; console access for remote engineers	Network design, firewall policy changes
Audio/visual	Conference room troubleshooting, display and camera replacement	Custom AV system design
IMAC (install, move, add, change)	Workstation moves, new hire setups, desk reconfigurations	Furniture moves
Cabling	Patch cable replacement, labeling, minor cable management	New structured cabling runs (quoted as project)
Asset handling	Receiving, staging and returning hardware; asset tag updates	Asset procurement

Techmate’s services map closely to these categories: desktop IT support, IT network services, audio/visual IT support and onsite hardware support.

Two tips make the catalog more useful. First, add an “other” line that allows ad hoc tasks with approval, so a technician can help with an adjacent issue without a new SOW. Second, keep project work (refreshes, office openings, large cabling jobs) in a separate SOW or change order. Day-to-day break-fix and projects are priced, scheduled and staffed differently, and mixing them makes both harder to manage.

What can technicians change without approval? (Section 3)

This short section saves more headaches than any other. Spell out what technicians can decide on their own and what requires approval.

Sample language: “Technicians may perform physical diagnostics, reseat and replace components using customer-provided or pre-approved parts, and execute configuration steps provided in writing by Customer’s IT team. Technicians will not modify security settings, firewall rules, user permissions or production configurations without written approval from an authorized Customer contact. Any work expected to exceed the ticket’s estimated duration by more than 60 minutes requires approval before proceeding.”

That last line prevents scope creep from turning a one-hour ticket into a four-hour invoice.

Authority limits are also a security control. Third-party involvement in breaches doubled to 30% in the Verizon Data Breach Investigations Report, 2025, so anyone touching your equipment should have the least access needed for the task. Name who can approve changes (by role, with a backup), how approval is recorded (ticket note, email or chat in the ticket thread), and what the technician does if no approver can be reached.

How should you set priority levels and response targets? (Section 4)

Define priorities by business impact, not by how loudly someone complains. Then attach a target to each one. The targets below are sample contract language, not a promise from any specific provider:

Priority	Definition	Sample onsite target
P1 Critical	Site down or business-critical system unavailable	Technician onsite within 4 business hours
P2 High	Multiple users or a key function degraded	Onsite same or next business day
P3 Standard	Single user or non-urgent issue	Onsite within 2 to 3 business days
P4 Scheduled	Planned work such as installs and moves	Onsite on the scheduled date

Adjust the targets to your needs and your provider’s coverage. Response targets in major metros can be tighter than in remote areas, so ask whether targets vary by site. For more on what realistic response times look like, see IT support benchmarks for professional services firms.

Define when the clock starts (ticket creation, acceptance or confirmed parts arrival) and when it stops (technician onsite or issue resolved). These two definitions cause more SLA disputes than the targets themselves. If you want enforceable service levels, our guide to SLA governance for enterprise IT outsourcing explains how to measure and enforce them.

What does the customer need to provide? (Section 5)

Onsite IT support services depend on things only you can provide. Put them in writing so failed visits are not blamed on the wrong party.

A named site contact available during the scheduled window
Access to the work area, closet or rack
Parts delivered to the site before the visit when advance shipping is used
Remote support engineer available by phone for configuration-dependent tasks
Credentials or console access delivered through a secure method
Building approvals, such as a certificate of insurance, arranged in advance

Sample language: “If a technician arrives within the scheduled window and cannot begin work due to lack of access, missing parts or unavailable site contact, the visit will be billed at the minimum rate and rescheduled.”

A site readiness standard makes this section easier to meet. Our site readiness checklist covers what each office should have in place.

How should parts and old hardware be handled? (Section 6)

Clarify who sources parts, where they ship and what happens to the old hardware.

Customer-supplied: you ship parts to the site ahead of the visit. Most common for laptops, switches and access points with specific configurations.
Provider-sourced: the provider purchases parts and bills them with a markup or at cost. Useful for cables, adapters and commodity items.
Return handling: define whether technicians ship failed parts back (RMA), dispose of them or leave them onsite. If drives are involved, specify data sanitization requirements.

For sanitization, reference a current standard rather than writing your own. NIST updated its media sanitization guidance in September 2025 with SP 800-88 Rev. 2 (NIST, 2025), which supersedes the 2014 revision many older contracts still cite. State the required method, who performs it and what record (serial number, method, date, signature) comes back to you.

What should every ticket closeout include? (Section 7)

A visit is not finished when the problem is fixed. It is finished when the next person can understand what was done.

Require these in every ticket closeout:

Arrival and departure times
Summary of work performed and root cause if identified
Before and after photos for any rack, closet or cabling work
Serial numbers of parts removed and installed
Any follow-up needed and who owns it
Site contact confirmation

This is also what turns an onsite IT support company into a source of real asset data rather than just a vendor. If you want to go further, our piece on IT documentation as part of your outsourcing strategy covers building a documentation standard across providers.

Set a deadline for closeout notes (for example, within 24 hours of the visit) and make complete closeout a condition of billing. Incomplete notes are the first sign that quality is slipping.

How should pricing mechanics be written? (Section 8)

Even if the rate card lives in a separate document, the SOW should explain how billing works:

Pricing term	What to define	Why it matters
Rate type	Hourly, per visit, block of hours or fixed fee	Determines how you forecast spend
Minimum billable increment	First increment and each increment after	Short tasks can cost far more than expected
After-hours, weekend and holiday multipliers	When they apply and who must approve them	Prevents surprise premiums on routine work
Trip charges or travel radius	Which sites incur travel and how it is calculated	Rural sites often carry hidden costs
Cancellation window and fees	Notice period and charge for late cancellation	Protects both sides from wasted trips
Approved overages	How time beyond the estimate is approved and billed	Ties back to the authority limits in Section 3

Clear mechanics beat low rates. A slightly higher hourly rate with no minimum can cost less over a year than a lower rate with a four-hour minimum. For a deeper look at these terms, see outsourced IT support fees and minimums.

How do reporting and change control fit into the SOW? (Sections 9 and 10)

An SOW without reporting is a document you sign once and never check. Add a reporting section that defines what you receive and how often:

Monthly: tickets by site and priority, on-time arrival rate, first-visit resolution rate, repeat visits and closeout completeness.
Quarterly: trends, top recurring issues by site, cost by category, and recommended fixes such as closet cleanups or spare stock.

Ask providers what they measure today. Techmate, for example, reports a 97% resolution rate and 4.7 out of 5 CSAT across its technician network, and any serious provider should be able to share comparable figures for your account.

Then add a change process: who can request changes, how they are documented (a numbered change order), and how often the SOW is reviewed. For the review meeting cadence, see how to run a quarterly business review with your outsourced IT provider.

What security and compliance terms should an onsite SOW include?

Regulated industries need a few more clauses, and they are worth adding for everyone:

Technician screening: background check requirements and how they are verified.
Confidentiality: NDA coverage for every technician, not just the provider entity.
Escort and access rules: restricted areas, sign-in procedures and photo restrictions.
Credential handling: how temporary credentials are issued, used and revoked after the visit.
Data-bearing devices: chain of custody for drives, laptops and phones leaving the site.

Law firms usually focus on client confidentiality and after-hours work so attorneys are not disrupted. Banks and credit unions often require pre-approved technician lists and documented device handling for exam readiness. See our pages on legal IT services and IT services for banks for what changes in those environments.

Putting the template together

Here is the complete structure in order:

Purpose and relationship to the MSA
Sites covered (Appendix A)
Task catalog with in-scope and out-of-scope examples
Technician authority limits
Priority definitions and response targets
Customer site requirements
Parts sourcing and return handling
Documentation and closeout standards
Pricing mechanics
Reporting cadence and review meetings
Change process for updating the SOW
Security and compliance requirements

What mistakes make an onsite SOW fail?

Describing roles instead of tasks. “Provide a desktop technician” invites arguments about what that technician should do.
Undefined SLA clocks. Targets without start and stop definitions cannot be measured.
No customer obligations. If your side is not written down, every failed visit becomes a dispute.
Mixing projects and break-fix. Rollouts need their own scope, schedule and pricing.
Outdated standards. Citing superseded sanitization or security guidance weakens the clause.
Static site lists. If adding a site requires a contract amendment, the list will always be wrong.

How to use this template with a provider

Send the draft SOW early in the evaluation, not after you have picked a vendor. How an onsite IT support company responds tells you a lot. Strong providers will push back with specific questions (“What is your expectation for sites with no one onsite before 9am?”). Weak ones will just sign it.

Ask each provider to walk through how a ticket moves from your help desk to a technician at the site and back, and compare it to the SOW. You can see Techmate’s version on our how Techmate dispatch works page.

Techmate works from scopes like this with internal IT teams and MSPs who need consistent onsite IT support services across many locations. If you want a second set of eyes on your draft, reach out to our team.

How does an SOW improve onsite IT support services?

A written scope of work is what makes onsite IT support services predictable. It gives every technician the same task catalog, authority limits and closeout standard, and it gives you a document to measure performance against in every review.

Frequently asked questions

What should a scope of work for onsite IT support include?

It should include the site list, a task catalog with in-scope and out-of-scope examples, technician authority limits, priority levels with response targets, customer site requirements, parts handling, documentation and closeout standards, and pricing mechanics. Strong SOWs also add reporting, a change process and security requirements such as technician screening and device chain of custody.

What is the difference between an MSA and an SOW?

A master services agreement covers legal terms such as liability, confidentiality and termination. A statement or scope of work covers operational details: what work is done, where, how quickly and to what standard. One MSA can govern several SOWs, such as one for ongoing support and another for a refresh project.

How do I prevent scope creep in onsite IT support?

Add an approval threshold to the SOW, such as requiring approval before any task exceeds its estimated duration by more than 60 minutes, and clearly separate project work from day-to-day support. Name approvers by role with a backup, and record every approval in the ticket so invoices can be checked against it.

What response time should I expect for onsite IT support?

It depends on priority and location. Many contracts target a technician onsite within about four business hours for critical issues and within a few business days for standard requests, with scheduled work performed on the agreed date. Ask whether targets differ for remote sites, and define exactly when the SLA clock starts and stops.

Who is responsible when a technician cannot access the site?

That should be defined in the SOW. Many contracts bill the minimum visit rate and reschedule when the technician arrives on time but cannot start because of missing access, parts or site contact. Listing customer obligations clearly, and keeping site profiles current, prevents most of these disputes before they start.

Should parts be supplied by the customer or the provider?

Either works. Customer-supplied parts are common for configured equipment like laptops and network devices. Provider-sourced parts are convenient for commodity items like cables. The SOW should state which applies, how returns and RMAs are handled, and which sanitization standard applies to any drive or device that leaves the site.

Want a second opinion on your current scope, response targets and site coverage? Book a free 30-minute IT support audit and we will review your SOW, ticket history and locations with you.