SLA-Based Technical Support

Agreed technical response for services with clear ownership.

We agree the applications, integrations, platforms, infrastructure dependencies, risks, support boundaries, and change controls before setting an SLA that reflects how the service is actually operated.

Discuss Your Support Requirement

Support engineers reviewing a customer record and technical status screens.

Contracted cover around an explicit technical scope

Organisations currently use this SLA model where their applications and supporting environments require defined incident response, escalation, maintenance and technical follow-through. Coverage can include agreed integrations, platforms and infrastructure where they form part of the supported service.

This is not a generic managed IT or end-user helpdesk service. We onboard the relevant architecture, dependencies, operating hours, service impact, access, monitoring, runbooks, suppliers, and change controls. The contract then states what Onyxsis owns, what remains with the organisation, and how incidents and planned work will be handled.

An agreed SLA can include:

Tiered response targets and coverage windows with documented channels, severity handling, and escalation routes
Incident triage, containment, and service recovery across the application and its agreed technical dependencies
Defect correction and root-cause investigation to address recurring failures rather than repeatedly restoring service without correcting the cause
Security and dependency maintenance scheduled around release, approval, and operational controls
Planned stabilisation and supportability work within the responsibilities and limits set during onboarding
Service reporting and improvement actions so SLA performance, recurring issues, and decisions remain visible

If a system needs contracted cover, we can review its service criticality, technical boundaries, current ownership, and required coverage before confirming the appropriate tier. Discuss the support requirement.

At a Glance

Current advertised commercial terms and coverage options.

Pricing

Priced per supported application according to the agreed tier, technical boundary, and coverage responsibilities
Minimum Contract Term

12 months
Support Tiers

Tier 1 (24/7), Tier 2 (Mon-Fri), Tier 3 (Mon-Fri email only)
Response Time

From 1 hour (tier-dependent)
Scope

Incident triage, live outage response and service recovery, bug fixes, security & dependency patching, planned maintenance, and escalation management

Where an agreed SLA removes ambiguity

Each use case starts with an agreed system boundary, service impact, and division of responsibility. Support then follows those facts rather than a generic catalogue.

Production Incident Response & Stabilisation
Triage, contain, and restore an agreed application or platform, then record the technical follow-up needed to reduce recurrence.

Defects in Business-Critical Workflows
Diagnose and correct repeat faults in applications and operational workflows, with root cause and responsibility made clear.

Security & Dependency Patching
Assess and apply relevant updates within the organisation's release, approval, testing, and rollback controls.

Release Support & Recovery
Provide agreed engineering cover around releases, including triage, targeted correction, validation, and rollback where required.

Integration Failure Handling
Trace faults across APIs, queues, data flows, identity, third-party services, and internal dependencies without losing sight of ownership boundaries.

Existing & Legacy System Support
Support established applications and platforms within documented access, vendor, source, knowledge, and change constraints.

Service Evidence & Reporting
Record response performance, incidents, recurring causes, maintenance, and agreed improvement actions in a form useful to technical and operational stakeholders.

Choose coverage according to application criticality

Not every application carries the same operational risk. The three tiers align response targets, coverage windows, and communication channels to the role each supported application plays, while keeping responsibilities explicit.

Each tier includes onboarding to confirm scope, dependencies, incident channels, escalation, and maintenance arrangements. Reporting provides evidence of performance and recurring technical work over the contract term.

	Tier 1	Tier 2	Tier 3
Response Time	Up to 1 hour	Up to 12 hours	Up to 1 working day
Coverage	24/7/365	Mon to Fri ¹	Mon to Fri ¹
Support Channels	Agreed channels	Agreed channels	Email only
Uptime Guarantee ²	Contract-defined	Not included	Not included

¹ UK business hours.
² Uptime guarantees and service credits are defined contractually during onboarding.

Pricing is confirmed after reviewing the application boundary, required tier, and operational responsibilities

Minimum 12-month engagement

Responsibilities available within the agreed scope

Each tier includes structured incident handling, technical follow-through, agreed maintenance responsibilities, and reporting. Exact coverage is confirmed during onboarding so application, integration, platform, infrastructure, supplier, and organisational boundaries are explicit.

Incident Triage & Recovery
Intake, severity assessment, containment, restoration, and escalation aligned to the agreed service model.
Defect Correction & Root-Cause Investigation
Debugging to restore function, followed by documented findings and remediation matched to the cause and recurrence risk.
Security & Dependency Maintenance
Relevant vulnerability and dependency work scheduled against the supported system's release and change controls.
Context Across Technical Boundaries
Support accounts for agreed applications, integrations, data flows, platforms, and infrastructure rather than treating each symptom in isolation.
SLA & Service Reporting
Response performance, incident patterns, material changes, and follow-up actions are recorded against the contracted obligations.
Planned Maintenance & Stabilisation
Agreed maintenance and corrective work keep the supported environment operable and address known risks.

Support Informed by the Agreed Environment

Active cover with explicit boundaries

Organisations currently use this SLA model for systems requiring a dependable technical response. Onboarding defines coverage and exclusions before support begins, including responsibilities shared with internal teams and third parties.

Delivery context carries into the SLA

The SLA protects agreed applications and environments using technical context carried forward from delivery. It provides focused, ongoing support for the systems within scope and can sit alongside an organisation’s wider support arrangements.

Restore service, then follow the evidence

Incident recovery is followed by a written account of the impact, findings, actions taken and recommended next steps. Planned changes are agreed through the organisation's controls rather than introduced simply because a ticket was raised.

For bounded investigation or improvement work outside the contracted SLA scope, Engineering Support Hours provide a separate block-hours model. Wider diagnostic work can be handled through technical investigation and operational diagnostics.

Discuss the SLA Requirement

Frequently Asked Questions

What response times are defined, and how are resolution targets handled?

Response targets are defined by tier and apply through the agreed support channels: up to one hour for Tier 1, up to 12 hours for Tier 2, and up to one working day for Tier 3. Resolution depends on severity, complexity, access, and third-party dependencies; after triage we state the recovery plan and expected next update.

How are incidents prioritised?

Priority is based on impact and urgency within the supported scope:

P1 (Critical): Service unavailable or major operational impact - immediate triage within the applicable Tier 1 coverage.
P2 (High): Significant degradation or blocked workflow - prompt response and coordinated remediation.
P3 (Medium): Partial impact or an available workaround - handled within the normal queue and agreed timescale.
P4 (Low): Minor defect or request - addressed during planned support windows.

How are unresolved incidents escalated?

Escalation triggers and contacts are agreed during onboarding. If impact increases or an SLA target is at risk, we add the appropriate engineering review, coordinate relevant organisational or supplier teams, and keep ownership and update intervals clear.

Can different applications use different tiers?

Yes. Tiers can be assigned per application according to operating hours, service criticality, risk, and required channels. Scope and dependencies are documented separately so a higher tier does not create ambiguous coverage.

What does SLA reporting include?

Reporting can include response-target performance, incident volumes and severity, recurring causes, material maintenance, root-cause findings, and agreed actions. The reporting interval and audience are confirmed during onboarding.

What can be covered by the SLA?

Coverage can include agreed applications, integrations, platforms, and infrastructure dependencies that Onyxsis can responsibly support. Architecture, access, source or vendor constraints, observability, and ownership are reviewed before the scope is accepted.

Is 24/7 support available?

Yes. Tier 1 provides 24/7/365 coverage with response in up to one hour. Tier 2 and Tier 3 operate Monday to Friday during UK business hours, with the response times and channels shown in the tier table.

Can existing, legacy, or third-party systems be supported?

They can be considered where access, knowledge, source, vendor cooperation, and safe change routes are sufficient. Responsibilities are explicit in the SLA. Larger remediation can be handled through existing and legacy system engineering.

How does Onyxsis work with internal teams and suppliers?

Onboarding defines incident channels, technical contacts, approvals, supplier escalation, and ownership. We document findings and changes so organisational teams retain the context needed for routine operation and decisions.

Is monitoring included?

Monitoring responsibilities are agreed per application. We can work with existing alerts or implement relevant service indicators where included, then tune escalation against availability, error, performance, and dependency signals.

What planned maintenance is included?

The agreed scope can include security and dependency patching, defect correction, and stabilisation work. Activities are scheduled through the organisation's testing, release, approval, and maintenance-window controls.

Can the SLA include platform or infrastructure lifecycle risk?

Yes, where those components are part of the supported application boundary. We can identify unsupported versions, fragile dependencies, capacity risks, and end-of-life components, then agree remediation or a separate engineering project.

How are recurring issues tracked?

Incidents are linked to affected components, previous occurrences, findings, and corrective actions. Patterns are reviewed for root cause and converted into maintenance actions or wider technical recommendations according to their frequency and impact.

Can support extend to integrations and operational data flows?

Yes, where they are explicitly in scope. Wider changes can be delivered through systems and API integration or data integration and operational reporting.

Need to compare tiers or define the supported boundary? Tell us which systems need support.

Define the support boundary for important systems

We can review application criticality, dependencies, operating hours, ownership, and coverage needs, then confirm whether the SLA model and one of the current tiers are appropriate.