Incident and Service Request Handling Procedure

Purpose. This procedure describes how the service desk logs, prioritises, resolves, escalates and closes incidents and service requests.

1.Scope

This procedure applies to every contact from a client user by phone, email, portal or chat and to every alert raised by the monitoring platform. It applies to service desk analysts and to any engineer who holds a ticket.

2.Logging

Every contact must be logged as a ticket in the Service Desk Tickets system before work starts. The ticket must record the client, the user, the device or service, a clear description in the user's words, the impact, and the steps already tried. Verify the caller's identity using the client's agreed method before making any account change.

• Client and user name
• Device, application or service affected
• What the user sees and when it started
• Business impact and number of users affected
• Steps already tried

3.Prioritising

Priority is set from impact and urgency using the priority matrix. Priority one is a whole client or a critical service down and requires a response within 15 minutes and continuous work until restored. Priority two is a group of users or a key function affected, response within one hour. Priority three is a single user affected, response within four hours. Priority four is a request or question, response within one business day.

4.Resolving

The analyst must search the knowledge base first and follow the article where one exists. Remote support must be used only with the user's consent recorded in the ticket. Every action taken must be recorded in the ticket as it happens, and a fix must be confirmed with the user before the ticket is set to Resolved.

5.Escalating

If the analyst cannot resolve the issue within 30 minutes for priority one and two, or within the response target for other priorities, the ticket must be escalated to the correct team with the notes complete. Suspected security incidents must be escalated to Cyber Security immediately and recorded in the Security Incident Register. The analyst keeps ownership of communication with the user until the ticket is reassigned.

6.Closing and knowledge

Resolved tickets close automatically after three business days without user response. Where the fix is new or the article was wrong, the analyst must draft or update the knowledge base article before closing the ticket.