The three questions that dominate remittance support

Classify twelve weeks of support contacts at almost any money transfer business and the same shape appears. Three questions account for somewhere between half and two thirds of everything that arrives, across every channel.

Where is my money. Why was my transfer held. What is my rate today.

They arrive by phone, by chat, through WhatsApp, in social comments and occasionally at an agent counter. They arrive at three in the morning. They arrive in volume on paydays and around festivals. And none of the three requires a human being to exercise any judgement at all.

The shape of remittance support

Below is the distribution we typically find. The ranges come from engagements rather than from published research, and your mix will differ by corridor, channel and app maturity. The point is the shape, not the numbers.

Read the first three rows together. Somewhere between half and two thirds of contact volume is a lookup against a system the sender cannot see. That is an access problem, not a service problem.

Why these three are different

Most support automation fails because it targets what was easy to build rather than what actually arrives. These three are unusual in that they are simultaneously the highest volume and the most automatable.

– They have a definitive answer. Transfer status is a fact, not an opinion.

– The answer is already in a system. It just requires authentication and a query.

– They repeat identically. The thousandth instance is the same as the first.

– They are time-sensitive. A sender asking where their money is at midnight does not want a reply at nine the next morning.

Somewhere between half and two thirds of remittance support volume is a lookup against a system the sender cannot see.

What automation actually solves

Three things, in descending order of how obvious they are.

The first is cost, and it is the one everyone leads with. Removing half the contact volume from a queue has a straightforward effect on support cost per completed transfer, which is the metric that should be reported rather than cost per ticket.

The second is speed, and it matters more than cost in this category. A sender who has transferred money for a family member and cannot see where it is experiences the wait as anxiety, not inconvenience. Answering in forty seconds at midnight is worth considerably more than answering in four hours at nine.

The third is the one most teams miss entirely. A meaningful share of contacts come from senders stuck mid-verification who gave up on the app and phoned instead. Those are being handled as support tickets when they are recoverable revenue. Routing them into a recovery flow rather than a queue turns a cost line into a revenue one.

The escalation rules matter more than the build

In the engagements we have run, agreeing the escalation rules consistently takes longer than building the automation, and that is the correct allocation of effort.

In this category a held transfer can mean a family does not eat that week. The boundary between what a machine handles and what a person handles is not a technical decision and should not be made by whoever happens to be building it.

Anything involving a complaint, a dispute, a compliance hold or a distressed sender routes to a human immediately, with the full conversation attached so nobody has to repeat themselves.

Two further rules that are worth holding to. Anything the assistant cannot resolve within two turns escalates rather than trying a third time. And escalation accuracy is audited weekly against a sample, not assumed to be working because nobody has complained.

What happens to your team

This is the question everyone in the room is actually thinking about, so it is worth answering directly.

In the engagements we have run, nobody has lost a job. What changes is the composition of the work. The team stops answering the same lookup forty times a day and starts handling the cases that genuinely require a person.

There is a counterintuitive consequence worth expecting. Average handling time on the remaining cases goes up, often by a quarter or more. That is not a regression. The easy cases have been removed, so what remains is what deserved a person in the first place. A team whose average handling time falls after automation is probably escalating too little.

Where to start

Classify first. Twelve weeks of contact data, categorised by reason rather than by channel, with volume and handling time per reason. It takes about a day and it prevents the most common failure in this work, which is building for the questions that were convenient rather than the ones that arrive.

Then build in this order: transfer status, rate enquiry, hold explanation, KYC guidance. That sequence follows volume and automatability together, and it puts the highest-return work first.

Start on the channel that carries the most volume rather than the newest one. In several corridors that means WhatsApp, because a large share of senders will reply there and nowhere else.