Incidents

When a service stops working, the Service Desk Agent records what happened, how urgent it is, and which service is affected. A linked asset narrows the investigation when the interruption is tied to equipment. The case can be assigned to the person who will respond. That common record gives the next shift a clear starting point instead of a collection of messages.

An incident moves from open to acknowledged when the responder takes it. Investigation follows as work starts. The response event records the responder and time; an attributed update explains the action taken. The team can then separate a case that is waiting to be picked up from one being actively investigated.

• Triage. Record priority, service, asset and assignee before asking another team to investigate.
• Response. Keep response events and dated updates attached to the same incident as the work proceeds.
• Impact. Add service impact and outage evidence when users face a delay or loss of service.

Agree who owns the first acknowledgement, who may change priority, and when an impact record is needed. A critical case affecting a high criticality service may need a different response path from a local equipment issue. Use the service catalogue and asset register so the team can make that distinction from recorded context.

Agree how to describe resolution. The resolved time should reflect restoration, while closing the case can follow confirmation. A recurring issue may also need a problem record to hold its root cause. Keep that investigation linked through the service and the people responsible for it.

Take a failed service at a named site. The Service Desk Agent records the summary, priority, service and relevant asset, then assigns a responder. The responder acknowledges it, adds a response event, records the investigation update and marks the affected service unavailable. If the interruption is an outage, record its start and restoration times against the incident. Check that another responder can read the chronology and identify what was done without calling the original owner.

When service returns, record the resolution time and move the incident to resolved. Review the outage and impact records before closing it. If the incident requires a planned change, hand the finding to the Change Manager with the affected service and rollback considerations. A change decision remains visible in its own record.

• Open Incidents — Cases still waiting for acknowledgement, investigation or resolution.
• High Priority Incidents — Urgent cases that need early attention from the response team.
• Service Overview — Scoped incident distribution and a recent evidence queue.

Follow the case in incident response, then review the change path when a controlled fix is needed.