Separate a supplier outage from a local ordering problem
When orders stop coming back with a result, check what the affected sales have in common. Compare the products, outlets and order times, then look up the original references and check the supplier's notices. Use read-only checks so you can investigate without placing more orders.
A blank response can come from a lost connection, a problem with the account, a change to the integration or a supplier fault. Say which orders and outlets are affected, and call it a supplier outage once the provider confirms the scope.
Diagnostic matrix
| Observation | Read-only check | Escalation |
|---|---|---|
| One user affected | Check account access and local connection | Local administrator |
| One outlet affected | Compare device and network evidence | Outlet support owner |
| Multiple outlets, one product | Compare original references and product status | Operations and supplier contact |
| Multiple products and outlets | Check timing, account and provider notices | Incident owner |
| Provider notice available | Verify time and stated scope | Communicate only confirmed details |
By Freepaid ยท Published
Compare like with like
Collect the product, outlet, time window, user or channel, original transaction reference and current status for affected cases. Use a consistent time convention. Compare several examples rather than relying on one anecdote. Check whether the same issue occurs from another approved location or user only if that check is read-only and does not create a new order.
Inspect local connectivity, login access and relevant error logs using the normal support process. Do not expose API credentials or personal information in a general incident report. If you have a published supplier status page or account notice, confirm its timestamp and scope. A notice may describe only certain products or regions. Do not generalise beyond what it says.
Worked example: three outlets report delay
Three outlets report delays within the same half-hour. Operations records the original references and timestamps, then checks their statuses through the approved interface. It finds that two transactions remain pending while the third has a local connection error before submission. The first two are escalated as a possible shared pattern. The third is handled as a local connectivity case.
The team checks the provider's notices and asks it to look up the two pending references. Staff tell customers that their orders are under review. The two transactions stay open while the team waits for confirmation.
Test which layer is common to affected orders
Build a short grid with an affected outlet, an unaffected outlet and the last known normal order from each. Compare which product and route they use, when they last received a status and whether they share the same connection or account. An unaffected outlet on a different product is weaker evidence than an unaffected outlet on the same product at the same time. Use observed orders and read-only checks so the comparison introduces no new purchase.
Use a safe escalation bundle
Ask the supplier a specific question, such as whether it received the orders and what status it recorded. Include the products, time window, number of outlets, sample references and checks you've already done. Use the approved channel and keep the supplier's reply with the incident record.
If the outcome of a request is uncertain, treat it as an unresolved original transaction. Ask for its status using the reference already created. Do not submit a replacement solely to test whether the service now works. Once a failure is confirmed, follow the documented retry or recovery procedure for that product and account.
Close and learn from the incident
- Record what was observed and which evidence supports it.
- Separate confirmed facts, likely explanations and open questions.
- Assign owners for local checks and supplier follow-up.
- Update affected staff and customers with verified information and a next update point.
- After resolution, record the confirmed cause only if evidence establishes it.
- Update the playbook if the incident exposed a real process gap.
Keep local faults and suspected supplier problems in separate queues when both occur. They can need different owners and different customer updates. See the support surge guide for coordinating multiple customer reports.