Start with a few tasks that matter to your business: a new employee needing access, a failed backup and a server outage outside office hours. Follow each one from the first request to completion with the MSP. Missing owners and exclusions tend to become clearer in a worked scenario than in a list headed “IT support”.
Make the MSP scope specific enough to use
Name the supported systems, routine tasks, exclusions and service hours. Device support might include troubleshooting and patching but exclude replacement hardware or a specialist business application. Monitoring may cover a server's availability without covering the application it hosts.| Area | Details the agreement should identify |
| Employee support | Supported users, devices, applications and contact channels |
| Systems and networks | Covered assets, monitoring, maintenance and authorised changes |
| Backup | Job checks, failure investigation, restores and recovery testing |
| Supplier coordination | Who opens third-party tickets, follows up and reports progress |
Backup is a useful test of the MSP agreement. Checking a completed job, restoring a file and recovering an application are separate activities. State which are included, how they are requested and what evidence confirms completion.
For an Asia Pacific MSP service, attach a site schedule. Identify the country, local support hours, time zone, applicable holiday calendar, support language and arrangements for site attendance. A regional agreement should make these differences visible. Do not assume a single “business hours” definition covers every office.
Read the SLA against a real incident
A service-level agreement defines measurable commitments. Its own wording controls what is measured, including when a clock starts, the coverage window, exclusions and any allowed pauses.| Term | Meaning to establish |
| Response | The required first action, such as acknowledgement or starting an investigation |
| Restoration | Returning the service to an agreed usable state, potentially through a workaround |
| Resolution | The defined completion of the issue, which may involve a permanent correction or a separate change |
Some MSP contracts define these terms differently. A response target alone does not tell you when service will return. Likewise, a workaround can restore service while the cause remains under investigation.
Ask how priority is assigned and changed. An outage affecting every branch usually has a different business impact from one person's access problem, but the MSP needs an agreed way to identify that impact. Confirm the update frequency and escalation contact when progress stalls.
“24/7 monitoring” also needs unpacking. Does it include an engineer investigating at night, authority to perform a recovery action and someone attending the site? Record each coverage separately.
Keep approval and execution connected
An MSP can carry out a change without being the right party to decide whether the business needs it. Your manager approves an employee's access; the provider may create it. Your operations owner approves an interruption; the provider may restart the server.| Activity | Provider work where included | Customer decision or input |
| Account changes | Implement authorised access and record the result | Approve permissions and supply start, move or leaving dates |
| Maintenance | Assess and perform agreed work | Approve disruption and identify business constraints |
| Incident handling | Investigate, coordinate and communicate within scope | Explain business impact and make required decisions |
| Recovery | Execute the agreed restoration procedure | Set priorities and confirm that business work can resume |
The table is a discussion aid. Actual authority follows the MSP agreement. Name a backup approver and define what the provider should do when neither approver can be reached. Otherwise a night-time response may end with a ticket waiting for the morning.
Plan for changes and the end of the service
New offices, applications and employees can change the workload and cost. Agree how they enter the supported scope, whether onboarding work is charged separately and how records are updated.Also ask what you receive if the MSP service ends: configuration records, asset information, administrative access and an agreed handover. Review the handling of provider access and customer data as part of that exit process.
When reviewing MSP services with advange, use the same task scenarios to test the proposed scope. The useful outcome is an arrangement that someone can follow during an incident: who acts, what they may do, when approval is needed and how completion is confirmed.
