Clear Agreements, Predictable Follow-up
Support is not about "how fast someone responds", but how predictable your operation becomes.
Clear priorities, clear definitions and transparency about what is and isn't covered by the SLA.
Fast response times across multiple contact channels—email, phone, or chat.
Dedicated support for all your needs, from simple questions to complex escalations.
Clear Language
No jargon, no small print. This is what we mean.
Response Time
Time until the first substantive response (triage + next step).
Resolve Time
Time until solution or workaround. Depends on cause, dependencies and scope.
Incident
Something doesn't work as intended and impacts availability, security or performance.
Service Window
The period during which planned maintenance may take place (if applicable).
Clear Priority Levels
Every incident is classified based on business impact. This determines our response.
Critical (Major Incident)
Example Situations
- Production is (largely) unavailable
- Security incident or suspected active compromise
- Data loss threatens or restore is immediately needed
- Payment/critical chain processes are down
What You Can Expect
- Immediate triage + incident coordination
- Escalation to the right engineer(s)
- Continuous status updates according to agreed cadence
- Focus on stabilization (workaround) then root-cause
High (Serious Impact)
Example Situations
- Service is available but partially not functioning
- Performance is so poor that business processes are hindered
- Important integration fails without direct workaround
What You Can Expect
- Fast triage and action plan
- Temporary workaround where possible
- Resolution via change or fix at the earliest safe moment
Normal (Limited Impact)
Example Situations
- Non-critical functionality doesn't work
- Small performance issues without business impact
- Support questions, configuration, small changes
What You Can Expect
- Substantive response with follow-up steps
- Scheduling based on impact and backlog
- Resolution via regular change flow
Low (Request / Nice-to-have)
Example Situations
- Feature requests
- Improvement wishes
- "Can you take a look at..."
What You Can Expect
- We estimate effort and impact
- We schedule it or include it in roadmap/optimization
Response vs Resolve
We promise response times because those are fully under our control.
Resolve times depend on complexity, dependencies (e.g. third parties) and the nature of the change (hotfix vs. planned).
What you always get:
- Fast triage
- Clear next step
- Transparency about risks and options (hotfix, rollback, workaround, planned change)
Response
Under our control
For P1 incidents
Resolve
Depends on context
Based on complexity
SLA Credits Done Right
SLA credits only work well if they are tightly defined.
Per Package
SLAs and credits are described per package and per service (hosting, portal, control plane).
Clear Scope
Credits only apply to unforeseen downtime within agreed scope.
Measurable
We measure availability based on pre-agreed measurement points (e.g. health endpoints).
SLA Addendum
Want an SLA with credits? We provide an SLA addendum with definitions, measurement method, exceptions and credit calculation.
Exceptions (so nobody argues afterwards)
This typically does not fall under credits / SLA uptime:
We always explicitly record this in the SLA addendum.
We Keep It Simple
Ticketing (Standard)
Always the source of truth
Incident Line (P1)
For escalation and coordination
Status Updates
Via ticket + optional status page or incident message
For This to Work Well
An SLA is not a PDF, but a way of working. For mature support we need at minimum:
Monitoring + Logging
On agreed measurement points
Contact Persons
Agreed contacts and escalation path
Change Flow
Who may do what, when
Access
According to least privilege
Ready to Set Agreements?
Plan an assessment and we'll send you:
- Proposal for package + scope
- Draft SLA addendum (priorities, response, windows, credits)
- Implementation plan to make this measurable