Service Operating Model

1. Purpose

This manual describes how the Organisation runs live services each day: which team answers first, what each support tier is allowed and expected to do, how work moves between tiers, what must be written in every ticket, how fast incidents must be handled at each severity, how a critical incident is run, how recurring faults are removed, who is told when targets are at risk, and what is reported. It is the common operating rulebook that the incident, request, problem and change procedures all rely on.

It gives staff a single place to look when they ask who owns this, how urgent it is and what happens next.

2. Objectives

• Restore normal service as quickly as possible after an incident, and keep customers informed while it is being fixed.
• Answer, classify and route every contact correctly the first time, with a target of [75 percent] of contacts resolved at the first tier.
• Make sure every ticket carries enough information that a different person can continue the work without asking the requester again.
• Remove the root causes of repeating incidents through problem management, and measure the fall in repeats.
• Meet the response and resolution targets agreed with customers in service level agreements.
• Give management accurate, regular reporting on volume, speed, quality and customer impact.

3. Scope

• In scope: all services in the scope of the SMS (see the SMS Scope and Service Management Plan), their customers and internal users, and all contact channels: telephone, email, portal, chat and monitoring alerts.
• In scope: first, second and third line support teams, on-call engineers, the security operations function, and suppliers who provide support under contract.
• In scope: incidents, service requests, problems and the escalation of each; changes are covered only where they interact with incident handling.
• Out of scope: the design of new services, which follows the Service Design and Transition Procedure, and the detailed steps of change approval, which follow the Change Management Procedure.
• Applies to: every employee, contractor and supplier engineer who works on a ticket.

4. Terms and definitions

5. Operating principles

• One ticket for every contact. Nothing is worked on, promised or closed without a ticket in the [ticketing tool].
• The service desk owns the customer relationship for a ticket until it is closed, even when another team does the technical work.
• Customers and users are told about a fault by the Organisation, not discovered by them: monitoring should detect an incident before a user reports it.
• Restore first, investigate second: during an incident the aim is to restore service; root cause work is done in problem management.
• Work at the lowest competent tier and move up quickly, not slowly: a ticket must be moved on when the next step is outside the current tier's skills or authority, or when the time limit for that tier is reached.
• Every change to a live service goes through change management, including emergency fixes made during an incident.
• Customer data seen in a ticket is handled under the Information Classification and Handling Policy and is not copied into tickets unless essential.

6. Roles and Responsibilities

7. Support model

Support is organised in three tiers, with defined hours of cover, handover rules and ticket-time limits. The table sets out what each tier does and when it must hand on. Tier hours follow the service catalogue: standard business hours are [08:00 to 20:00 on working days], extended hours [24 hours a day, 7 days a week] for services marked as such.

7.1 L1: service desk

The service desk is the single point of contact. It must answer or acknowledge every contact within the target in the service level, and is staffed to the roster approved by the Head of Service Delivery.

• Logs every contact, records the mandatory ticket fields, and sets the first impact and urgency.
• Searches the knowledge base and resolves the ticket when a documented solution exists, without handing on.
• Fulfils pre-approved requests directly from the request catalogue, such as password reset, access to a shared folder or an information request.
• Checks whether the ticket matches an open major incident or known error and links it instead of creating a duplicate.
• Routes to the correct resolver group by the support category and informs the requester of the next step and the expected time.
• Monitors tickets owned by others for approaching targets and chases them, within the rules in the escalation matrix.
• Confirms resolution with the requester, records the closure code and closes after [3 working days] of no reply when the requester has been asked twice.

7.2 L2: technical operations

• Monitors platform and infrastructure health and acts on alerts before users report them.
• Diagnoses incidents routed from L1, applies workarounds from the knowledge base, restarts, reconfigures or fails over services within standard operating procedures.
• Carries out standard changes listed in the catalogue, and raises normal or emergency changes for anything beyond it.
• Runs routine operational tasks: backup checks, certificate expiry checks, log checks and capacity checks.
• Keeps runbooks current: each fix that was not in a runbook is documented within [2 working days].
• Hands on to L3 with a complete summary of what has been tried, evidence collected and the next step suggested.

7.3 L2: business operations

• Resolves incidents and requests that concern customer data, account set-up, configuration and process, such as incorrect reports, delayed jobs or entitlement errors.
• Performs approved data corrections through a controlled script or a recorded form, with a second person checking where the correction affects more than [100 records].
• Supports customer onboarding and off-boarding steps with the customer's service owner.
• Provides business-impact information to the incident manager and the service desk during a critical incident.
• Identifies recurring request types for automation or inclusion in self-service.

7.4 L3: engineering and devops

• Takes incidents that need code, configuration or architecture change; designs and tests fixes; deploys through the release and deployment process.
• Is on call outside business hours for severity 1 and 2 incidents for the services it builds, to the roster published by [the Head of Engineering].
• Provides root cause analysis for critical incidents within [5 working days] and supports problem management.
• Maintains deployment, rollback and recovery scripts, and tests them at the frequency in the Availability and Service Continuity Management Procedure.
• Keeps technical documentation current and reviews knowledge articles written by L1 and L2 for accuracy.

7.5 Other IT and security functions

Several functions outside the three tiers are called on when a ticket needs them. Each has a named contact and a response expectation set in an operational level agreement.

These functions follow the same ticket rules. Time spent by them counts against the incident's resolution clock.

7.6 Hours of cover, rosters and handover

• The service desk and L2 teams publish a roster at least [14 days] ahead. Changes to the roster are approved by the team lead and recorded.
• On-call engineers are named for each service, with a deputy, and are reachable within [10 minutes] of a page during their on-call period.
• At every shift change the outgoing lead records the open severity 1 and 2 tickets, pending approvals, planned changes and risks in the handover log (Annexure A), and verbally briefs the incoming lead.
• No critical incident is handed over without both leads present.
• Cover for staff absences keeps the minimum staffing level of [2 people] on the service desk at all times service is offered.

8. Ticket management

8.1 Mandatory ticket information

A ticket may not be moved to a resolver group until the fields in the table are completed. Fields marked with an asterisk are also required at closure. The ticketing tool should make them mandatory on screen so that the rule is enforced by the tool and not by memory.

8.2 Ticket lifecycle

1. New: the ticket is created and the mandatory fields are being completed.
2. Assigned: the ticket has a resolver group and an owner.
3. In progress: work has started and the clock is running.
4. Pending: the ticket is waiting for the customer, a supplier or a scheduled change; the clock is paused only for a customer wait or a customer-agreed time, with the reason written in the notes.
5. Resolved: service is restored or the request fulfilled and the requester has been told.
6. Closed: the requester has confirmed, or the automatic closure rule has applied; closed tickets are not reopened and a new linked ticket is raised instead.

8.3 Quality of ticket records

The process manager reviews a sample of at least [20] closed tickets every month, scored for completeness, correct classification and customer communication, and feeds the result back to team leads. A completeness score below [90 percent] triggers coaching and a re-sample the next month.

9. Incident management

The detailed procedure is in the Service Incident Management Procedure. This section sets the operating rules that apply to every incident.

9.1 Incident process

1. Detect and logA user, monitoring alert or engineer reports a fault; the service desk logs a ticket immediately and records the mandatory fields. Target: logged within [5 minutes] of contact.
2. ClassifyThe service desk sets impact and urgency, derives the severity and checks for an existing major incident or known error to link to. Target: within [10 minutes].
3. RespondThe owner acknowledges the requester, states the severity and the next update time. Target: per the severity table.
4. Diagnose and resolveL1 tries documented solutions; if unresolved, the ticket moves to the right L2 group, then to L3 if needed, with a complete handover note each time.
5. CommunicateUpdates are sent at the cadence in the severity table, even when there is no news; the ticket records each update.
6. RecoverA workaround or fix is applied; emergency changes follow the Change Management Procedure; the requester confirms service is working.
7. CloseThe resolver records the cause category and fix; the service desk confirms with the requester, closes the ticket and, where needed, raises a problem.
8. ReviewSeverity 1 and 2 incidents, and any repeat incident, are reviewed within [5 working days] to learn what to change.

9.2 Impact and urgency matrix

Severity is derived from the impact on the customer or the business and the urgency of the need to restore. The service desk may raise severity during the incident but may lower it only with the incident manager's agreement for severity 1 and 2.

9.3 Incident severity classification

Targets are the default. A signed service level agreement overrides them for the customer concerned, and the ticketing tool must hold the agreed targets per customer. Response and resolution clocks run in the hours of cover of the service; severity 1 and 2 on a 24-hour service run continuously.

9.4 Customer communication during incidents

• The service desk or incident manager sends the first notice to affected customers within [30 minutes] of a severity 1 incident being declared, stating what is known, what is affected and when the next update will come.
• Updates avoid speculation about cause and never name individuals.
• A closing notice is sent when service is restored, followed by a short written incident report for severity 1 incidents within [3 working days].
• Where customer personal data may be involved, no statement is made until the information security lead has agreed the wording.

10. Critical incident process

A critical incident is declared by the service desk, the on-call engineer or the shift lead as soon as severity 1 criteria are met, or by the incident manager on judgement of potential impact. It overrides normal queues: staff drop other work when asked by the incident manager.

10.1 Declaring and running the critical incident

1. DeclareThe first person who recognises severity 1 criteria calls the incident manager and the on-call engineer; the incident manager confirms and declares in the ticket. Target: declared within [15 minutes] of detection.
2. AssembleThe incident manager opens a conference bridge or dedicated channel, names a scribe, and brings in L2, L3, security, network and the service owner as needed. Target: team assembled within [20 minutes].
3. AssessThe team agrees what is known, the customer impact, whether personal data or security is involved, and the first hypotheses. Information security decides if the Incident Management Procedure also applies.
4. ActThe incident manager assigns actions with owners and times. Only one person at a time makes changes; each change is noted in the ticket and, if a change to the live service, approved as an emergency change.
5. CommunicateCustomers, management and staff receive updates at the cadence in the severity table. The service desk handles customer updates; the incident manager approves wording.
6. RecoverService is restored by fix or workaround; the team checks the service, monitoring and customer-facing functions; the incident manager declares recovery and records the time.
7. Stand downThe incident manager closes the bridge, hands unfinished actions to named owners, and confirms the final communication.
8. ReviewA post-incident review is held within [5 working days]; the report goes to the service owner, process owners and top management and is shared with affected customers where the agreement requires it.

10.2 Critical incident roles

10.3 Post-incident review

The review is blameless and focuses on the facts: timeline, detection, response, cause, what worked, what slowed recovery, and what must change. Each action has an owner and a due date and is tracked in the improvement register. A problem record is opened for any incident whose cause is not fully removed.

• Review report completed within [10 working days] of recovery.
• Detection time, response time, restoration time and customer impact minutes recorded.
• Actions rated by value and cost; top actions scheduled within [30 days].

11. Service request fulfilment

Service requests are handled under the Service Request Management Procedure. In this operating model, a request is logged as a request ticket, approved if its catalogue entry requires it, fulfilled by the owning team, and closed after the requester confirms. Target times are set per request type in the catalogue and, where no special time is set, the default is [2 working days] for standard requests and [5 working days] for requests that need approval or procurement.

12. Problem management

A problem is opened when the cause of an incident is not known, when incidents repeat, or when a major incident needs a root cause. Problem work does not delay restoration. The Problem Management Procedure carries the full method; this section sets the operating targets.

The problem manager reviews the incident trend report each month for categories with rising counts, repeat callers or long resolution times, and opens problems on the strongest patterns.

13. Escalation

Escalation is a normal part of operations and not a failure. A ticket is escalated when a target is at risk, when a decision beyond the current tier is needed, or when the customer asks. Functional escalation moves the work; hierarchical escalation informs management.

Contact names and numbers are kept in the escalation contact list (Annexure B), checked at least every [3 months], and printed or stored offline in case the tooling is unavailable.

14. Knowledge management

• L1 and L2 write a knowledge article for any fix that took more than [30 minutes] to find or that is likely to repeat.
• Articles carry an owner, a review date no later than [12 months] ahead, a service tag and a visibility setting: internal or customer-facing.
• A peer reviews each new article before it is published; articles that are shown to cause wrong fixes are withdrawn at once.
• Customer-facing articles never contain internal hostnames, credentials or customer data.
• Usage and success rates of articles are reported monthly.

15. Reporting

Reports are produced by the process manager from the ticketing tool and reviewed before issue. Anyone who spots an error corrects it with the process manager.

Report content follows the Service Reporting and Continual Improvement Procedure so that definitions and calculation methods stay the same from month to month.

16. Interfaces with other processes

17. Key performance indicators

18. Records and evidence

• Tickets and their work notes, kept for [3 years] or as the customer agreement requires.
• Handover logs, on-call rosters and escalation contact lists, kept for [12 months].
• Critical incident logs, reports and post-incident reviews, kept for [3 years].
• Problem and known-error records and knowledge articles, kept while in use and [12 months] after retirement.
• Monthly reports and quality sample results, kept for [3 years].

Annexure A: Shift handover log

Annexure B: Escalation contact list

Annexure C: Critical incident record

Annexure D: Document history

19. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

20. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

21. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 20000-1:2018 references

Related documents

• Service Incident Management Procedure
• Service Request Management Procedure
• Problem Management Procedure
• Change Management Procedure
• Service Level Management Procedure
• Service Catalogue Management Procedure
• Incident Management Procedure
• Service Reporting and Continual Improvement Procedure