Ticketing
Part of Support channel integrations
Handling a failed customer-system lookup
Give agents clear fallback steps for missing, ambiguous, denied, stale and temporarily unavailable customer records.
When a customer-system lookup fails, keep the support case moving and avoid treating missing data as a negative result. “No customer found”, “the source is unavailable” and “this agent cannot access the record” require different next steps. The agent must know which condition occurred, or at least that the result is unverified.
Classify the failure before responding
Use a small set of states agents can understand:
| State | Agent response |
|---|---|
| No reliable match | Ask for an appropriate order or account reference and verify identity before sharing details. |
| Several possible matches | Do not select one from a similar name alone; use a stronger reference or escalate. |
| Permission denied | Send the case to an authorised colleague or access owner. |
| Timeout or service error | Continue the conversation, mark the lookup as unavailable and retry through the approved route. |
| Record found but possibly stale | Check the source record before making a time-sensitive statement. |
These are proposed workflow categories, not error codes every product supplies. The support interface should show a clear status plus enough diagnostic detail for an administrator. Keep technical error text out of the customer reply.
Give the agent a safe fallback
For an order enquiry, the agent can acknowledge the question, collect a verified reference and explain that the record must be checked before confirming its status. If an approved source-system view is available, use it and note that the ticket sidebar failed.
If it is not available, assign the case to someone who can check it. Do not infer that an order was cancelled or never placed because the lookup returned nothing.
Keep ownership on the original case. A fallback that sends the customer to another address without transferring context makes the failure their problem.
Record the reference used, the lookup time, the state shown to the agent and who will follow up. Avoid copying whole customer records into a diagnostic note.
Retry without hiding a persistent fault
A temporary error may warrant a retry, but the integration should avoid an uncontrolled loop. For rate limiting, respect the response’s rate-limit and reset headers; a 429 response indicates that requests are being limited.
Server errors are a distinct failure class and may have different retry behaviour. These are examples of provider-specific signals; an implementation must follow the connected system’s own response rules.
Technical owners should monitor repeated failures by source, error type and time, then check whether cases were left without an answer. A successful later retry should update the agent’s view clearly. It should not silently overwrite a human-verified finding or trigger a second customer reply.
Test the workflow with a missing record, an ambiguous match, expired access and a simulated unavailable source. Ask whether an agent can explain the next step in each case and whether the case still has an owner.
