Exception handling is what customers remember
Imagine a customer who sends 5,000 dirhams to a supplier on a Tuesday and sees it come back on Thursday, less a fee, under a status that says "Payment unsuccessful". The agent she reaches can see that the payment was returned but not why, and has no way to tell her whether the fee will be refunded. He offers to escalate.
A week later she still hasn't heard anything. By then she has told the supplier, and probably a few friends, what she thinks of your company.
She won't remember the forty payments that went through without a problem. Customers judge a payments business on the few moments when money doesn't do what they expected, and most of what happens in those moments is decided in operations: the status the customer sees, the timeline they are given, what the first person they speak to is allowed to do, and whether anyone tells them when it's over. Failed payments, returns, refunds and account holds each have their own version of this.
Product teams design the path where everything works, and the exception path tends to be designed by whoever handled the first complaint.
Start with the status. Internally, a returned payment carries a reason code from the scheme or the receiving bank, and there are a lot of them. Customers need perhaps five or six states, each with a plain explanation and a next step. "Returned by the recipient's bank because the account number doesn't match an open account. The money is back in your balance and we've refunded the fee. Check the details with your supplier and send it again." A message like that prevents a contact. "Payment unsuccessful" creates one, and then an agent has to look up the code and translate it over the phone.
The mapping from internal codes to customer states is operations work. Someone who knows what each code means in practice should write it, with support and product in the room. It needs a review whenever a new partner or payment rail brings codes you haven't seen before. With instant payments the customer sees a failure within seconds, so the explanation has to be ready just as fast; the staffing side of that is in instant payments leave no overnight window for exceptions.
Then the timeline. Customers count "three to five business days" differently from you, especially across weekends and public holidays in two countries. A date works better: "You'll have the refund by Monday 30 June." To give a date you can keep, look at how long this kind of case took over the last quarter and take the slow end. If 90 percent of card refunds reached customers within six business days, promise six and let the faster ones be a pleasant surprise. The average is no use for this, because something like half your customers would see you miss it.
Many of these timelines depend on a partner, such as a sponsor bank investigating a return or a correspondent tracing a payment. If your agreements don't say how quickly partners respond to investigation requests, you can't promise the customer a date with any confidence, which is one more reason to write service levels your partners can measure.
Account holds are the hardest case, because some are raised by financial crime review and limit what staff are allowed to say. That makes it more important to agree the wording with compliance in advance: what the customer can be told, and who contacts them when the hold is lifted. Where nobody has done that work, agents fall back on saying nothing, and a customer who can't reach their money and can't get an answer will keep calling until someone gives one.
Giving the front line room to fix things
The agent in the example did the only thing open to him, which was to escalate. Look at how many of your payment contacts end in an escalation, and then at what the escalation team does with them. A large share usually end in one of a handful of outcomes: refund the fee, resend the payment once the customer confirms new details, confirm the return reason, speed up a refund. A trained front-line agent can make those decisions if they can see the reason code and have a clear limit.
Say an agent may refund fees up to an agreed amount and resend a returned payment once, with anything above the limit going through a maker-checker step to a supervisor. That rule costs you some fee income and saves a queue of escalations that each take a day to come back. Two measures tell you whether it is working: the share of payment contacts resolved on first contact, and the number of repeat contacts about the same case. A customer who calls three times about one refund costs you three contacts and most of their goodwill.
Closing the loop means two things. The customer hears from you when the case is resolved, before they have to ask, in the channel they used. And the reason for the exception goes back to whoever can prevent the next one. If a fifth of your returns come from customers mistyping IBANs, the fix belongs in the payment form, and operations is the only team holding that data. Disputes work the same way: reason codes and evidence say a lot about product and merchant problems, if someone reads them with that in mind.
A useful exercise for the next month is to pull twenty recent exception cases of mixed types and read each one from the customer's side. What did the app say, what did the agent say, how long did it take, and did anyone tell them it was over? The gaps are usually obvious by the fifth case, and most of them can be fixed without a new system.
Discuss your operations
