Checklist · Platform Procurement
Support SLA Review: Response, Restoration and Coverage
Review support commitments by severity, staffed hours, initial response, workaround and resolution, including escalation, customer duties and exclusions.
Published Updated
Published by FxTrusts, a supplier of brokerage and prop firm technology. Prepared with AI-assisted research and drafting; reviewed against the cited public sources. Examples are illustrative. Product links describe our services.
Quick answer
A support SLA review distinguishes acknowledgment, active response, workaround, service restoration and final resolution. Define each clock, coverage period, severity rule and customer obligation in the actual agreement. A short initial response commitment does not mean that the service will be restored or the underlying defect permanently fixed within that interval.
Define the event that each clock measures
Ask whether response means an automated receipt, contact by an engineer or the start of technical work. Identify the time source, submission channel and information required for the clock to begin. Then ask separately about update frequency, workaround targets, restoration and resolution. If a term has no defined target, record it as uncommitted rather than filling the gap with an assumption.
Microsoft Azure's support documentation explicitly defines initial response as contact by a support engineer who starts work, with conditions varying by plan and business impact. That is a provider-specific example of careful terminology; its response times must not be applied to a platform reseller, another cloud or FxTrusts.
Sources for this section
- Microsoft Azure support scope and initial responseazure.microsoft.com
Check coverage and the responsibility chain
Record staffed hours, timezones, holidays, languages and emergency channels. A portal available at all hours is not proof of continuous engineering coverage. Identify whether the supplier handles the platform, integration and hosting itself or opens tickets with another party. Ask who communicates progress while the cause crosses organizational boundaries.
List customer duties such as providing a responsive contact, logs, safe access and continued investigation support. The AWS shared-responsibility model illustrates why operational tasks vary by service boundary. Confirm which side owns patching, configuration and application defects instead of assuming every incident is included in the infrastructure supplier's support.
Sources for this section
- AWS shared responsibility modelaws.amazon.com
Review escalation, exclusions and evidence
Map internal incident severity to the supplier's classifications and record how disagreements are escalated. Check exclusions for planned work, unsupported versions, customer changes, third-party services and unavailable dependencies. Ask how credits or other remedies are claimed if offered; a remedy is not itself a recovery process.
Retain ticket timestamps and state changes so actual service can be compared with the agreement. Do not measure a paused clock without also recording why it paused and who was expected to act. Use technical recovery objectives as a separate operational plan; contractual support response and system RTO answer different questions.
Example: a response target does not promise restoration
A fictional agreement provides a one-hour initial response for a qualifying critical case. A complete ticket is submitted at 02:00, an engineer begins work at 02:35, a workaround restores the affected function at 04:10 and the defect is fixed the next day. The response interval is 35 minutes; restoration took 2 hours 10 minutes from submission. Whether either result meets a commitment depends on the separately defined contract terms.
| Term | Question to resolve |
|---|---|
| Initial response | Who acts, and what starts the clock? |
| Coverage | Which hours, languages and holidays apply? |
| Restoration | Is there a target and a defined service state? |
| Resolution | Does this mean a permanent defect correction? |
| Escalation | Who coordinates cross-supplier dependencies? |
Implementation checklist
- Define each response and recovery term separately.
- Verify staffed coverage and the customer's required participation.
- Map severity, exclusions and cross-supplier escalation.
- Preserve ticket events when evaluating actual performance.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
- Microsoft Azure support scope and initial responseazure.microsoft.com
- AWS shared responsibility modelaws.amazon.com
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.