Incidents

A register stops responding during a trading period. The service desk records what the store reported, assigns a priority and links the affected service and asset. This keeps the opening time, current state and responsible technician in the same incident. A supervisor can see whether the issue is still open, acknowledged, under investigation or resolved without reconstructing the case from messages.

The incident is the anchor for later store evidence. A register outage can name the store and register and record when service returned. A trading window can give the store’s opening and closing times and timezone. Both records link to the incident, so the service desk can compare the operational context with the issue being worked.

• Intake. Record the summary, priority and opening time, then select the service and asset that the team will check.
• Acknowledgment. Read the linked service and asset, validate the lifecycle state, assign a technician and record the acknowledgment time.
• Follow-through. Add dated technician updates as investigation proceeds and record the resolution time when the issue is resolved.

Agree how stores report a new issue and who chooses the affected service and asset. A register may have its own asset record, while a store network issue may affect a different asset. The team should decide which choice makes the incident useful to the next technician. Agree when a priority is Critical and when a case should be assigned to a specialist.

The service desk also needs a consistent rule for acknowledgment: the assigned technician must be someone who can take responsibility, and the timestamp should represent the actual response to the store. Decide who can update a resolved case and what evidence is needed before it is marked closed. Keep store codes and register numbers consistent with the evidence records your team will capture.

Rehearse a store reporting a failed checkout register. Select the checkout service and the affected asset. Have the technician confirm both links, assign themselves and acknowledge the incident. Then add an update describing the diagnosis. Capture a register outage with the same incident, the store code, register number and start time. When the register returns, record the restoration time and resolve the incident.

Review the resulting case as someone taking the next shift. The summary should identify the issue; the priority and status should show urgency and state; the assignment should identify who is working it. The update and outage record should explain what changed and when. If those records tell conflicting stories, correct the source record before closing the handoff.

• Open Store Incidents — Working issues grouped by their current state, priority and assigned technician.
• Critical Incidents — Critical cases with the affected service, asset and technician visible.
• Incident Status Board — A status view for deciding which cases need the next action.

Continue with incident response and store evidence.