IT support for small businesses: scope, costs and service-level agreements

1. Map the environment and the service boundary

List users, locations, laptops, desktops, servers, network equipment, printers, email, cloud services and business applications. Note manufacturer warranties and systems owned by another provider. Then map the processes that matter: billing, appointments, sales, design, shared files or remote access. A provider cannot make a credible commitment without understanding the assets and dependencies involved.

Specify whether the service includes remote help desk, onsite work, user onboarding, patching, inventory, backup, monitoring, procurement, vendor coordination or security. Labels such as “unlimited support” do not say whether projects, new deployments, data recovery, personal devices or after-hours incidents qualify. Write the boundary in ordinary language so managers and employees can understand it.

• Covered people, devices, sites and applications.
• Approved request channels and supported hours.
• Recurring tasks versus separately scoped projects.
• Responsibility for manufacturers and external providers.
• Conditions for onsite and after-hours work.

Compare providers with a scope matrix, not package names. Use the same device, task, coverage window and expected outcome in each proposal.

2. Understand what each pricing model rewards

Per-incident support can fit occasional demand, but expenditure varies and preventive work may be deferred. Prepaid hours offer a budget ceiling until the block expires or runs out. Per-user and per-device plans can simplify planning and recurring administration, while price changes with tools, hours, complexity and risk. Projects are better separated into deliverables, assumptions, change control and acceptance.

Ask each proposal to expose taxes, minimums, travel, tools, licenses, parts and out-of-scope rates. Clarify what happens when headcount grows or demand exceeds the assumption. Model representative months rather than comparing one headline fee. Include the employee time used for coordination and the downtime produced by exclusions. Cheap support is not inexpensive when nobody owns patching, recovery or vendor escalation.

• Time-and-materials or incident billing.
• Prepaid hours with expiration and consumption rules.
• Recurring plan per user, device or managed environment.
• Fixed project with named acceptance criteria.
• Specialist and out-of-coverage services.

3. Write service levels that can be observed

Build priority from impact and urgency. A billing outage affecting the company needs a different path from a cosmetic request affecting one person. Give examples for each priority and state when the clock runs. Define whether response means an automated receipt, a technician’s contact or the beginning of diagnosis; only the latter two tell the customer something about actual attention.

Where appropriate, add communication and restoration targets while separating restoration from permanent resolution. The provider may enable a temporary workflow while waiting for a vendor fix or replacement part. Describe legitimate waiting states, such as pending customer access or approval, and how timing resumes. Do not ask a support company to guarantee recovery dates for dependencies it cannot control.

• Objective definition and examples for every priority.
• Business hours, time zone and excluded dates.
• Human response and work-start targets.
• Update frequency and escalation path.
• Restoration objective and closure criteria.

“One-hour response” does not mean “one-hour resolution.” Every metric needs a start event, an end event and evidence.

4. Govern provider access and shared security

NIST advises small businesses to document service level, responsibilities and expectations in a formal agreement and emphasizes that accountability for protecting information remains with the business. Require named accounts, least privilege, multifactor authentication, access logging and approval for sensitive changes. Shared administrative passwords sent through email or chat prevent attribution and make revocation difficult.

Decide who owns configurations, documentation, domains, licenses, backups and logs. Define incident notification, evidence preservation, subcontractor use and relevant data locations. Joint CISA guidance asks MSPs and customers to understand their shared responsibilities because trusted provider access can magnify an intrusion. The agreement should let the customer verify controls without demanding sensitive information unrelated to its service.

• Named accounts, MFA and approved privileges.
• Logged access and configuration changes.
• Incident notification channel and timeframe.
• Ownership, location and retention of customer information.
• Complete access revocation at role or contract termination.

5. Review outcomes and prepare for exit

Agree on periodic reporting for ticket categories, priority-level performance, repeated incidents, problem assets, patch state, recovery and open risks. Closing a ticket does not prove that the employee is productive or the root cause is controlled. Sample completed work and collect short user feedback to evaluate diagnosis, communication and documentation—not just speed.

Hold service reviews and maintain an exit plan. The customer should be able to receive an accurate inventory, credentials under its control, configurations, documentation and usable data exports. Exercise escalation before a crisis and revisit the SLA when applications, offices or exposure change. A healthy agreement provides an orderly relationship even when the parties later choose different directions.

• Achievement by priority rather than one overall average.
• Recurring incidents and preventive actions.
• Asset, update and recovery status.
• Accepted risks with owner and review date.
• Handover deliverables and termination assistance.