A Counter Outage Runbook for Retail Teams

Identify the failure before choosing the response

Separate a power problem, a device problem, a local network issue and an unavailable external connection. Use simple checks that ordinary staff can perform safely under the business's approved procedure. State what they should record before contacting support. Avoid a single instruction to restart everything, because it can remove useful evidence or interrupt another working part of the operation. The runbook should make the first few minutes clearer without turning the cashier into a technician.

Document the deployment's dependencies

List the counter device, printer, scanner, network and services required by the proposed setup. For browser-based checkout, include the internet connection as a stated dependency. Ask the provider to explain the supported behaviour during an interruption; do not assume that a browser view or local device provides offline trading. If the business requires a particular continuity mode, make it an explicit requirement and demonstrate it on the intended configuration before launch.

Agree the customer-service procedure

Decide who directs the queue, who communicates with customers and which trading actions remain permitted during the interruption. Have operations and the responsible advisers approve any alternative documentation or payment process needed for the business. This guide does not prescribe a substitute billing method. The important point is that staff use one approved procedure rather than several informal workarounds that later produce inconsistent sales, stock or settlement records.

Preserve evidence for support

Record the affected counter, time, visible message and last known transaction reference where available. Keep sensitive information out of casual public messages. Identify the correct support channel and escalation contact for software, equipment and connectivity. A useful incident report tells the receiving person what failed and what has already been checked. Repeating the same unstructured description to several teams can delay recovery even when one of them is able to resolve the underlying problem.

Recover with reconciliation as well as access

When the counter becomes available, follow the agreed checks for transactions that were interrupted or handled through an approved alternative process. Confirm whether any action remains pending and who reviews it. Avoid repeating a payment or document submission merely because the first response was unclear. The operator should have a supported way to establish the state of the earlier attempt. Recovery is complete when the business records are understood, not simply when the screen opens again.

Rehearse and revise the runbook

Run a controlled exercise before launch and after a material equipment or deployment change. Have staff use the written instructions without a demonstrator filling in missing steps. Record confusing points and improve the runbook. Link the exercise with shift-close reconciliation and the accepted backup plan. Keep the contact details and responsibilities current. A realistic, repeatable recovery process is a stronger basis for comparing systems than an unsupported promise that interruptions will never happen.

Useful next steps

• Review recovery preparation
• Include interruptions in counter testing

Ask iPOS to help validate a short runbook for the proposed deployment and rehearse one representative interruption with the staff who will use it. Discuss your requirements with iPOS.