40% of support calls were problems the product should have solved itself.
XPayBack is a peer-to-peer lending platform. Users couldn't resolve basic issues — failed transactions, refund status, account holds — without calling support. The interface gave them nowhere else to go.
The stakes
XPayBack's support team was fielding hundreds of calls a week. When we looked at what users were calling about, the pattern was clear: failed transaction status, refund timelines, and account hold explanations accounted for over 60% of inbound volume. These weren't complex problems. They were visibility problems. Users were calling because the product gave them no other way to find out what was happening with their money.
Every call that shouldn't have happened was a cost — to the support team, to the user's trust, and to the product's reputation in a category where trust is the entire business.
The problem
XPayBack users who encounter a failed transaction, refund delay, or account issue have no self-service path — no ticket system, no status tracking, no contextual help — forcing them to call support for resolution, driving avoidable inbound volume and eroding trust in a high-stakes financial product.
The existing help experience was a single static FAQ page. No search. No way to raise a ticket. No way to track whether anyone had seen your complaint. For a platform handling real money, this was a significant trust gap.
What we found
I worked closely with the PM to map where calls were coming from. Support logs showed three dominant categories: transaction status (38%), refund timelines (24%), and account holds (18%). Session recordings showed users repeatedly tapping on transaction entries expecting detail — and getting nothing. App store reviews cited "no way to contact" and "don't know what's happening" as the top complaints.
The core insight: users weren't calling because they wanted to talk to someone. They were calling because the product gave them no other option. The fix wasn't a better FAQ — it was giving users the information and tools to resolve things themselves.
Options considered
Option A — Expand the FAQ
RejectedMore FAQ content addresses the wrong problem. Users weren't failing to find answers — they were failing to get real-time status on their specific situation. A longer FAQ doesn't tell you where your refund is.
Option B — Live chat
RejectedLive chat shifts the load from phone support to chat support — it doesn't reduce it. Engineering complexity was high and the team didn't have chat support capacity. Treating the symptom, not the cause.
Option C — Self-service help center + ticket system
ChosenA searchable help center with contextual articles reduces informational calls. A ticket system with status tracking eliminates the 'I don't know if anyone's seen my complaint' calls. Both together address the two root causes.
The tradeoff
Building a ticket system and help center meant engineering effort that delayed two other planned features by one sprint. We accepted this because the call volume cost — in support headcount and user trust — was a more urgent problem than the delayed features.
We also chose not to build live chat, which some stakeholders wanted. The tradeoff: users with urgent issues still need to wait for a ticket response rather than getting instant help. We decided this was acceptable because the majority of calls were status-check calls — not urgent escalations — and a ticket system resolves those without real-time staffing cost.
What we built
1. Searchable help center with contextual routing
Not a list of articles — a searchable system that surfaces the right content based on where the user is in the app. A user tapping on a failed transaction sees relevant articles first, not a generic help index. This alone deflects the informational calls.
2. Ticket system with visible status tracking
Users can raise a ticket in three taps, categorised by issue type. Every ticket has a visible status — open, in review, resolved — with timestamps. Users know their complaint has been received and where it stands. This eliminates the follow-up call.
3. Transaction status with plain-language explanations
Every transaction state — pending, processing, failed, refunded — now has a plain-language explanation and a clear next step. "Your refund is being processed. Expected by 22 May." Users no longer need to call to find out what "failed" means or what to do next.
Outcome
Within the first month of launch, inbound call volume dropped 40%. The support team — which had been adding headcount to manage volume — was able to redirect agent time to genuinely complex escalations. More importantly, users now had a place to go. That shift from helplessness to agency is what actually built trust.
What's next
The ticket system currently requires users to categorise their own issue. Session data shows 18% of tickets are miscategorised, creating routing delays. Next: smart categorisation based on the user's recent transaction history — reducing resolution time for the cases that do reach support.