Almost every managed service agreement in Australia includes an SLA table with response and resolution targets. Almost every client signs it without understanding the delta between what the numbers say and what they experience when something breaks. The problem isn't that MSPs are dishonest about their SLAs, it's that the terminology isn't standardised, and the definitions buried in the contract do a lot of work.
Response time versus resolution time
The most important distinction in any SLA is between response and resolution. They are not the same thing and a low response-time commitment means very little without a resolution-time commitment alongside it.
Response time is the period between a ticket being logged and a human (or sometimes an automated acknowledgement, check this) touching the ticket. A 'response within 4 hours' commitment can be satisfied by an email saying 'we've received your request and will be in touch.' The clock stops. The problem hasn't moved.
Resolution time is the period between logging and the issue being closed. This is the number that actually affects your business. Australian MSPs rarely publish resolution benchmarks publicly, they vary too much by issue type, but you should negotiate them explicitly for P1 and P2 incidents.
What the Australian market looks like
Based on Frontrow's experience reviewing competitor agreements during RFP processes, the following response-time commitments are broadly representative of the Australian MSP market across three tiers:
- P1 (complete outage, service down): response 15 to 30 minutes, resolution target 4 hours, this is the standard claim; check whether 'resolution' means fixed or 'workaround in place'
- P2 (significant degradation, key user affected): response 1 to 2 hours, resolution target 8 hours, commonly business-hours only, meaning a P2 logged at 4:30pm resolves the next morning
- P3 (single user affected, workaround available): response 4 to 8 hours, resolution target 24 to 48 hours
- P4 (low-impact request, no user blocked): response next business day, resolution 5 business days
These are headline numbers. The actual service experience depends on what's excluded, what 'business hours' means, and whether the contract includes on-call coverage or after-hours callout fees.
The clauses that change the calculation
Four clauses are worth reading carefully before signing any managed service agreement:
- 1Business hours definition, 'response within 2 hours' during business hours (typically 8am to 5pm AEST or AEDT Monday to Friday) is a materially different commitment than a 24/7 target. If your business operates across time zones or outside standard hours, confirm what after-hours support costs and how it's triggered.
- 2Clock pause for client response, some agreements stop the SLA clock if the MSP is waiting on a response from the client. This is legitimate, but when a helpdesk engineer emails a user rather than calling during a P1, the pause can sit for hours. Ask how escalation works when a client isn't responding.
- 3Exclusions from SLA measurement, third-party outages (ISP, Microsoft Azure, carrier) are nearly always excluded. These are reasonable exclusions. Less reasonable is 'issues caused by changes outside the managed service scope', this clause, written broadly, can exclude any incident that touches the client's own internal changes.
- 4Credits for SLA breaches, most agreements include a credit mechanism for missed SLAs. The credit is usually a small fraction of the monthly fee (sometimes one day's fee per breach). If uptime and response time are business-critical, the credit won't come close to covering the impact. SLA credits are not compensation, they're an acknowledgement that something went wrong.
What good looks like at the P1 level
A P1 incident affecting a client's M365 environment, complete Teams or Exchange outage, a security incident, a ransomware trigger, should produce a named engineer on a call within 15 minutes, not an email acknowledgement. The clock for a true P1 should be running from the moment the client calls or the monitoring platform fires an alert, not from when a ticket was manually raised.
For a NSW legal firm running a client matter deadline, four hours to resolution on a complete Exchange outage is a commercial incident. For a QLD healthcare provider with clinical systems depending on M365 authentication, the same gap is a patient safety risk. The SLA headline doesn't differentiate, the contract, the on-call roster, and the escalation path do.
Questions worth asking before you sign
- What is your 24/7 on-call structure and how is it staffed, a dedicated engineer, or an on-call rotation that also covers other clients?
- What was your P1 mean-time-to-resolution (MTTR) over the last 12 months? Can you show us the data?
- What is the escalation path if the assigned engineer can't resolve within the target time?
- Is Microsoft Premier Support or Unified Support included in the engagement, and who owns the case management relationship?
- What's your major incident process, who becomes the incident commander, and how are clients kept informed in real time?