SLA-Based Support
Support structured around severity levels and response commitments agreed specifically for your application, for businesses where an undefined response time to a production issue is itself a risk.
What SLA-Based Support Means
A service-level agreement defines, in writing, how issues are classified and how the support relationship responds to each classification. It exists for applications where knowing roughly when something will be looked at matters as much as knowing it eventually will be.
Defining Severity Together
Severity levels are agreed with you rather than applied from a generic template, since what counts as critical for a payment system is different from what counts as critical for an internal reporting tool.
Critical
The application, or a core part of it such as checkout or login, is unusable for most users.
Significant
A specific feature is broken or badly degraded, but the application as a whole is still usable.
Minor
A cosmetic or low-impact issue that does not stop anyone from completing their work.
What Happens When an Issue Is Raised
Logged and Classified
Every issue is recorded and assigned a severity level as soon as it is raised, rather than being judged informally in a chat message.
Worked Against the Agreed Commitment
Response and resolution targets for that severity level guide how the issue is worked, so priority is not decided case by case on a whim.
Communicated Until Closed
You hear about progress on a significant issue rather than only finding out once it is resolved.
Reporting Against the Agreement
Periodic reporting shows how issues were classified and handled against the agreed targets, so the SLA is something you can check against, not just a document filed away after signing.
Frequently asked questions
What is a severity level and who decides it?
A category, such as critical, significant or minor, that describes how much an issue affects the business. The levels and what falls into each are agreed together before support begins, not decided unilaterally when an issue comes in.
What decides the response and resolution targets in our SLA?
How critical the application is to daily operations, and how much support capacity is reserved for it. A payment-critical system typically carries tighter targets than an internal tool.
What decides the cost of SLA-based support?
How tight the agreed response and resolution targets are, and how much dedicated capacity needs to be reserved to reliably meet them.
What happens if a target is missed?
This is defined in the agreement itself, and reviewed openly rather than left ambiguous. The point of writing an SLA down is that both sides know what was promised.
Can SLA support run alongside an AMC?
Yes. An AMC sets out what work is included over the year; an SLA adds specific response and resolution commitments on top of it.
Do you need to review our application before agreeing an SLA?
Yes. Committing to response targets on an application we have not looked at would be a guess, so a short review comes first.
Who is the point of contact when something is raised?
A named contact on our side is agreed as part of the SLA, so raising an issue does not mean waiting to find out who is responsible for it.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private