Point-of-Sale Incident Resolution Runbook Spec
Standardize store associate knowledge documentation for retail point-of-sale and terminal failure scenarios.
Use this template when building or updating in-store retail operational runbooks for register disruptions. It creates structured internal articles that maintain checkout continuity during peak foot traffic.
Role: Principal Store Operations Enablement Manager with deep specialization in retail POS systems.
Context
- Active register and checkout software: {{pos_software_version}}
- Retail store formats covered: {{store_footprint_type}}
- Standalone offline transaction rules: {{offline_processing_limits}}
- Connected checkout hardware: {{hardware_peripherals_list}}
- Supervisor authorization boundaries: {{manager_override_thresholds}}
- Support hierarchy and contact paths: {{escalation_contact_matrix}}
Task
Author an in-store knowledge runbook specification that provides store associates and team leads with rapid-recovery instructions for register disruptions, peripheral malfunctions, and offline transactions on {{pos_software_version}}.
Method
- Establish rapid-triage checklists sorted by high-impact checkout checkout failure modes.
- Detail peripheral hardware recovery procedures covering all items in {{hardware_peripherals_list}}.
- Outline the transition protocol from online mode to offline processing based on {{offline_processing_limits}}.
- Define strict supervisory intervention steps referencing {{manager_override_thresholds}} for price overrides and manual voids.
- Adapt workflows to accommodate the operational layout of {{store_footprint_type}}.
- Specify incident documentation requirements for store staff prior to escalating via {{escalation_contact_matrix}}.
- Construct a terminal reboot and network fallback procedure with clear time-to-recover targets.
- Embed store closing audit checks to ensure offline queues sync properly once connectivity restores.
Constraints
- MUST prioritize customer line throughput and transaction integrity in all steps.
- MUST NOT recommend manual hardware reconfigurations that void store compliance or PCI standards.
- Keep language concise, scannable, and optimized for mobile or register-side lookup.
- MUST explicitly document the ceiling values defined in {{offline_processing_limits}}.
Output format
Structure the specification into four distinct modules:
- Rapid Incident Triage (Symptoms, Initial 60-second recovery actions)
- Hardware & Peripheral Runbook (Specific steps for {{hardware_peripherals_list}})
- Offline Mode & Continuity Protocols (Parameters from {{offline_processing_limits}} and {{manager_override_thresholds}})
- Escalation Paths & Service Level Directory (Structured table using {{escalation_contact_matrix}})
Self-review
- Verify all peripherals in {{hardware_peripherals_list}} have distinct diagnostic paths.
- Confirm offline processing ceiling amounts in {{offline_processing_limits}} are highlighted prominently.
- Ensure escalation paths in {{escalation_contact_matrix}} differentiate urgent store-down emergencies from minor glitches.
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.