Annex A - Service Level Agreement (SLA)

• Legal >
• Terms >
• Master Services Agreement – IT Services >
• Annex A - Service Level Agreement (SLA)

Last updated: 3 August 2026. View change log.

This Annex forms part of the IT Master Services Agreement between you and Cultrix Limited (“Cultrix”, “we”, “us”). It defines the Service Desk support model: how tickets are classified as incidents, service requests or information requests, how we prioritise them, and the target service levels for triage, first meaningful response, and periodic updates for each type.

Not every Service described in the Schedules to the Agreement will apply to you. This Annex applies only to the Services included in your Order.

1. Purpose and scope

The purpose of this SLA is to give us both a clear, shared understanding of:

• how we classify tickets as incidents, service requests or information requests;
• how we prioritise each ticket;
• when the Service Desk is available;
• target times for triage, first meaningful response, and periodic updates; and
• what is, and is not, included in SLA measurements.

SLA targets are service objectives, not strict guarantees. They apply only to in-scope Services, systems and devices we manage under your Order.

2. Service hours and SLA clock

Unless your Order says otherwise:

• Business Hours are Monday to Friday, 08:30–17:30 UK time, excluding English bank holidays.
• SLA timers run during Business Hours only.
• We treat tickets raised outside Business Hours as received at the start of the next Business Day, unless Out-of-Hours cover applies under your package.
• SLA timers pause when a ticket is set to Pending or On-hold.
• SLA timers resume when the ticket returns to an active queue.

3. Ticket classification

We classify every ticket at triage as one of three types. The type describes the kind of work the ticket needs; the priority (section 4) describes how quickly we engage with it. Each type has its own SLA table in section 6.

3.1 Incidents

An incident is an unplanned interruption to, or degradation of, an in-scope service – something that should be working is broken or behaving incorrectly. Examples: a user cannot sign in; email is not flowing; an application is crashing or erroring; a device fault; a security alert. The goal of an incident is to restore normal service as quickly as possible.

3.2 Service requests

A service request is a request for something new or changed where nothing is broken. Examples: a new starter or leaver; an access or permission change; new hardware or software; a mailbox or distribution-list change; a configuration change. The goal of a service request is to fulfil it through the appropriate standard steps, which can include approvals or procurement. A request that needs significant design, planning or procurement may be scoped and agreed as a project instead (see section 10); we will tell you before that applies.

3.3 Information requests

An information request is a question – a request for advice, guidance or information where nothing is broken and nothing needs changing. Examples: how-to questions; advice on options or licensing; a request for a report or export; a question about a service. The goal of an information request is to give you an accurate, useful answer.

We set the type at triage and may reclassify a ticket as our understanding develops – for example, a how-to question that uncovers a fault becomes an incident. When the type changes, the targets for the new type apply from that point.

4. Priorities

We set a priority for every ticket, whatever its type, from two things: its impact (how much of your organisation is affected) and its urgency (how badly work is disrupted).

Impact:

• Organisation-wide – affects your whole organisation or a core shared service.
• Department – affects a team, site or group of users.
• Individual – affects a single user or device.

Urgency:

• Work stopped – people cannot work and there is no acceptable workaround.
• Work degraded – people can still work, but in a limited way.
• Minor issue or query – little day-to-day impact, or a general request.

We combine the two to derive the priority. Impact runs down the rows; urgency runs across the columns:

The priorities mean:

• P1 – Critical: complete loss of a mission-critical service with no acceptable workaround, or a request or question that is business-critical and cannot wait.
• P2 – High: significant degradation of a major service, serious user or business impact, or a hard, dated business deadline the work must meet.
• P3 – Medium: issue with moderate impact where a workaround may exist, or a routine request or question with a target date.
• P4 – Low: minor issue, low-impact fault, advice, or routine request with no fixed deadline.

The same priority scale applies to all three ticket types. In practice, incidents that stop people working sit at P1–P2, while most service requests and information requests sit at P3–P4. A concrete, dated business deadline – month-end accounts access, payroll day, a new starter’s first day – can justify a higher priority for a request; general urgency wording on its own does not.

Priority is usually set by our triage, which can include automated assessment of impact and urgency, and we can adjust it as we learn more about the ticket. Issues caused by unauthorised or unsupported changes on your side are not automatically classed as urgent incidents.

5. SLA definitions

• Triage: initial review, classification, prioritisation and assignment of a newly received ticket.
• First meaningful response: substantive engineer communication or action that moves the ticket forward.
• Periodic update: a later meaningful customer-facing update or progress confirmation at the target interval, while the ticket stays active.

Automated acknowledgement emails do not count as a first meaningful response. Non-substantive messages (for example, “Thanks”) may be excluded from SLA event calculations where reasonable.

6. Target service levels

Our committed service levels are the times to triage a new ticket, give a first meaningful response, and provide periodic updates while the ticket stays active. Each ticket type has its own table below. Resolution and fulfilment are separate best-efforts aims, not guaranteed times (see 6.4). All targets are measured in Business Hours.

6.1 Incidents – committed targets

6.2 Service requests – committed targets

6.3 Information requests – committed targets

6.4 Resolution and fulfilment aims (best efforts, not a guaranteed SLA)

We aim to resolve incidents, fulfil service requests, and answer information requests within the following targets. These are aims, not guaranteed times, and they are not a breachable SLA clock:

We do not guarantee a resolution or fulfilment time. How long a fix or a fulfilment takes can depend on third-party vendors, hardware parts or procurement lead times, or waiting for information, access, approvals or decisions from you. Where any of these apply, the aim may not be met, and that is not an SLA breach. We keep you updated at the periodic-update intervals until the ticket is resolved or fulfilled. We may also monitor resolution and fulfilment times internally for service quality and planning.

7. Reopened tickets

If a ticket is reopened, we record the reopen event for service reporting. Reopened tickets re-enter active SLA management, including periodic update requirements, and we may re-triage them where the scope or impact has changed materially.

8. How to contact the Service Desk

• the service portal (where provided);
• email to the support address we give you during onboarding; or
• telephone to the Service Desk number we give you during onboarding.

We may record telephone updates on tickets as call notes, to keep an auditable service timeline.

These are the only channels that create and update support tickets. They feed the queue our whole team works from, they carry your SLA clocks, and they keep an auditable record of what was asked and agreed.

Messages sent another way – personal messaging apps such as WhatsApp, SMS, social media, or messages to individual members of our team – are not support requests. They do not create a ticket and do not start any SLA clock. If something reaches us that way, we may ask you to resubmit it through a support channel; the SLA clock starts when the ticket exists.

The same applies to instructions and approvals: a decision that changes scope, cost or configuration is only effective when it is recorded on a ticket or agreed through the change process in your agreement. An informal message is not an instruction we can act on, or a commitment by either of us.

9. Out-of-Hours support

Out-of-Hours support is available only where it is included in your Order. Where included, it is for genuine urgent incidents and follows the entitlement and process defined for your package.

Where Out-of-Hours support is not included, we handle incidents raised outside Business Hours from the next Business Day. Service requests and information requests raised outside Business Hours are always handled from the next Business Day.

10. Dependencies and exclusions

Meeting SLA targets depends on:

• accurate, timely information from your contacts;
• timely access to systems, users and decision-makers;
• cooperation with troubleshooting and change controls; and
• the availability of relevant third-party services and vendors.

The SLA does not apply to:

• projects, consultancy, migrations, and major change work – including service requests that we agree to scope as a project;
• issues caused by unsupported or unauthorised changes by you or a third party;
• assets or software outside support, or not under our management;
• service impact caused by third-party outages, internet/carrier issues, or force majeure events; and
• work waiting on your instruction, access, approval, or a third-party response (while the ticket status is paused).

11. Major incidents

For major incidents affecting multiple customers or shared platforms, we may invoke a major incident process. During that process, we may provide coordinated updates rather than per-ticket responses. We will use reasonable efforts to restore service quickly and keep you informed.

12. Changes to this Annex

We may update this Annex to reflect service improvements, operational changes, or legal requirements. We will publish material changes with reasonable notice.