Ticket after ticket, same question
The most common support ticket at a payments or banking app is some version of 'where is my money'. A transfer has not arrived, a top-up has not appeared, a card payment is still pending, a refund from a merchant has not come through.
The agent opens the helpdesk ticket, then the admin panel to find the customer, then the transactions screen, then the provider's portal because the admin panel status is vague, then the ops review queue to see whether the payment is held, then Slack to ask ops what a status means. Ten minutes later they reply. The next ticket is the same question from someone else.
Why a simple question needs so many tabs
The answer to 'where is my money' depends on facts that live in different systems, and the helpdesk was never connected to any of them.
- Your app shows the customer a simplified status, and support needs the detailed one.
- Provider statuses use terms agents have not been trained on.
- Holds and reviews live in the ops tool, which support may not have access to.
- Known incidents, such as a provider delay today, are announced in a Slack channel, not in the helpdesk.
- Nobody has written down what each status means for the customer and what to say.
Slow answers and escalations
Each ticket takes longer than it should, and new agents take a long time to become useful because they have to learn every tool. Many tickets get escalated to ops just to translate a status, which interrupts ops. Customers wait and worry, and some of them tell everyone on social media while they wait.
The same payment may be asked about by the sender and the recipient, and they might get different answers from different agents.
A customer panel in the helpdesk
What we build brings the answer into the ticket. Agents keep using Intercom, Zendesk, Freshdesk or whatever you run.
- A sidebar app in your helpdesk identifies the customer from the ticket and loads their recent payments and account state from your systems.
- Each payment shows your internal status translated into plain language, with the detail behind it one click away.
- If a payment is held or under review, the panel says so and shows what the customer can be told, without exposing internal notes support should not see.
- Known incidents are shown on affected payments, such as a delay at a named provider since a certain time.
- Suggested replies are drafted from templates you write for each status, which the agent edits and sends.
- A button raises a structured escalation to ops with the payment already attached, for the cases that genuinely need it.
| Payment state | Agent sees | Suggested reply covers |
|---|---|---|
| Sent, not yet arrived | Sent time, rail used, normal arrival window you define | When to expect it and what to check |
| Held for review | That a review is in progress, not why | That it is being checked and the next update point |
| Returned | Return reason in plain words | What went wrong and how to retry |
| Affected by a known incident | Incident note and start time | What is happening and where updates will be |
| Failed before sending | Failure reason | Whether money left and what to do next |
What agents can see is controlled by role. The panel reads through your services, so it does not open up your database.
The support queue afterwards
Agents answer most payment questions from the ticket, in a consistent way. New agents learn the statuses from the panel rather than from a folder of screenshots. Ops receive fewer, better escalations, each with the payment already attached.
When a provider has a bad day, the incident note appears on every affected payment in the panel, so everyone says the same thing.
Does this sound like your support team?
- Agents open several tools for one payment question.
- Ops get asked to explain statuses in Slack.
- Different agents give different answers about the same payment.
- New agents take weeks to handle payment tickets alone.
- Incident updates do not reach the helpdesk.