Handle a sudden increase in prepaid support tickets
If support tickets spike, count the distinct orders first. Group them by time, product and outlet, then check the original references through the approved status route. Give one person responsibility for the investigation and for the next customer update.
The pattern may point to the supplier, but it could also be a branch that lost its connection, a change at the till, unclear redemption instructions or a busy campaign. Look for what the reports share before deciding which team should investigate.
Surge triage table
| Group | Read-only check | Customer update |
|---|---|---|
| Same product and time window | Compare original references and statuses | Acknowledge review. Give next update point |
| One outlet only | Check local connectivity and workflow records | Explain local checks underway |
| Several products or outlets | Look for shared timing and account evidence | Say the pattern is being investigated |
| Provider notice available | Confirm timestamp and stated scope | Repeat only verified scope |
| Missing references | Request receipt or internal sale ID | Explain what evidence is needed |
By Freepaid · Published
Assign a single incident owner
When many cases arrive, several people may contact the supplier independently or tell customers different things. Assign one incident owner to maintain the evidence, coordinate supplier queries and approve customer updates. Individual ticket owners can still communicate with customers, but they should use the verified status and agreed language from the incident record.
The owner should keep a concise log: issue first observed, products and outlets affected, example references, checks completed, confirmed facts, unresolved questions and next update time. Avoid putting full recipient details or credentials in a broad incident channel. Link each customer ticket to the shared incident only when that is permitted by the organisation's privacy process.
Worked example: 15 reports in 20 minutes
Imagine 15 reports arrive within 20 minutes. The team groups them by product and outlet. It finds 10 reports from three outlets involving the same product, all with original references and a pending status. Five other reports are from one branch where the till lost network connectivity. The groups should be handled separately: the first can be escalated as a shared pattern with references and timestamps. The second needs a local connectivity check.
The incident owner checks the provider's notices and order statuses. While the cause is unclear, tell customers that the team is checking their orders and when it will update them. Give staff that same wording and keep the original orders open for investigation.
Prioritise evidence and impact
Sort cases by customer impact, transaction status and age. A case with an unknown outcome needs a status check against its original reference. A case with no reference may need the customer or outlet to provide a receipt ID before further investigation. A confirmed completed transaction with a complaint follows the normal dispute path. Do not collapse these categories into one “failed” queue.
Use approved read-only checks first: account access, local connection, supplier status view and published service information. Preserve timestamps and error messages in the source format. Do not run test orders or change production settings as a diagnostic shortcut. If a technical change is needed, use the organisation's normal authorisation and change process.
Turn the queue into one incident record
Keep one incident ID for the surge and link each customer case to it. Give the incident owner the count of unique orders and the time of the first report. Recount when the next update is due, and distinguish new affected orders from repeat contacts about existing ones. The customer-facing team can then give a consistent update while the investigator checks the evidence.
Communicate without overclaiming
Tell customers what you can confirm, what the team is checking and when you'll be in touch again. Once you have the result, share it and give customers with open cases a contact for follow-up.
After the rush, use the closed tickets to count cases tied to the incident, cases with a separate cause and cases still open. If the evidence points to unclear receipts, a training problem or confusion over ownership, change that part of the process.
See the fulfilment support playbook for case routing and the outage diagnosis guide for read-only checks.