Streamline payment query escalation

01

The problem, and what shipped

Twelve thousand payment queries a month, run entirely out of Outlook group mailboxes. Only 30% of them were new work — the rest was people chasing, duplicating and escalating things already in flight.

The tool that replaced those mailboxes has one front door that will not accept a query without the transaction reference, so the same payment cannot be raised twice. Personal in-trays with a visible clock, so “urgent” stops being whoever shouts. And an escalation route that stayed open to everyone but recorded why.

Post-launch it cut query handling time by 60%. It was approved at USD 300K and went live to 50+ people across investigations and relationship management.

Fig. 01The in-tray that replaced the group mailbox. Queries are assigned, ordered by time remaining, and the clock is on the row. — high-fidelity prototype

02

Where the other 70% went

The brief, as the team wrote it: “Streamline query and escalation management for the UK payment investigations team to enhance overall operational effectiveness & better end-client experience.”

Research surfaced six themes. Three of them were doing most of the damage, and all three are the same failure wearing different clothes — nobody could see the state of anything they did not personally own.

Duplication
The same payment raised two or three times, because there was no way to find out it was already open.
Dependency
A relationship manager could not learn where a case had got to except by asking a person, who then stopped investigating to answer.
Awareness
No shared clock. Priority was whoever escalated hardest, so escalation became the normal way to be seen.

Fig. 02Mapping the interviews into themes. Duplication, dependency and awareness are the three that drove the design. — project deck, slide 07

Two personas came out of it, and they are the two ends of every stuck query — the person holding the case, and the person being asked about it.

Fig. 03The Deep Diver — an investigations specialist, deep in one case at a time. — project deck, slide 08

Fig. 04The Front Runner — a relationship manager, spread across clients, answering to one of them. — project deck, slide 09

03

Eight questions, one vote

Eight How Might We statements went on the wall. The team voted, with a seven-of-ten threshold to carry, and what survived was sorted into a MoSCoW backlog.

Each decision in the next section beat alternatives that were on the wall at the same time.

Fig. 05Insights reframed as eight How Might We statements. — project deck, slide 10

Fig. 06The vote, then MoSCoW. What survived became a complete feature list, ordered by what had to ship first. — project deck, slide 12

04

Four decisions

Each one in the same shape: what was true, what we chose, and what it cost.

Decision A

The transaction reference is the front door

What was true: The same payment was being raised two and three times over. Nothing in a mailbox could tell you a case already existed.
What we chose: A mandatory transaction reference, looked up against the payment record before the form will submit. If a query already exists it blocks, names the person who raised it, and offers that case instead.
What it cost: Real friction at the front door. You cannot raise anything without the reference to hand, which is slower for the genuinely new query — the price of the duplicate never being created.

Fig. 07Before — the 2023 mid-fidelity wireframe of the raise form. — project deck, slide 13

Fig. 08After — the reference resolves to an open case, and submission is blocked rather than warned about. — high-fidelity prototype

Fig. 09The same field on a payment with no query against it: the details fill themselves and are not editable. — high-fidelity prototype

Decision B

Escalation stays open to everyone

What was true: Escalation was a shout with no record. It moved work, but nothing captured why, so nobody could tell an emergency from a habit.
What we chose: Keep it open to everyone, and make its cost visible instead of gating it. Five named reasons and no 'Other' and no 'Urgent'. A private mirror showing your own escalation rate against the team median, seen by nobody else. The manager accepts or declines with a reason of their own.
What it cost: More design, and more to build, than a permission check. Gating escalation would have been one line of logic — this needed the reasons, the mirror and the decision loop before it worked at all.

This is the spine of the project, and it is also where the first instinct was wrong. That instinct was to restrict who could escalate. It would have suppressed the signal rather than the behaviour — the people escalating most were the ones under the most client pressure, and taking the button away does not take the pressure away.

Making the rate visible only to the person doing it was the version that worked. It is information, not a limit, and it is not reported anywhere.

Fig. 10Five named reasons. The absence of 'Other' is the design — if none of these is true, the query is already in the queue. — high-fidelity prototype

Fig. 11The private mirror: your rate against the team median, with an explicit line saying it is not a limit and is not reported. — high-fidelity prototype

Fig. 12The manager's side. Accepting is not a button — it takes a written instruction, because it reorders someone else's queue. — high-fidelity prototype

Decision C

Access is decided by the query, not the role

What was true: Two personas plus a manager, all needing different things from the same case — and a real confidentiality line between relationship management and investigations.
What we chose: One shell, three roles, and permission that reads the query rather than the person. Your own open query is editable. A colleague's is readable but has no controls. A resolved one is closed to everybody, including the person who closed it.
What it cost: Cross-member search went to Won't Have. An RM cannot look across the team's book at all, which is occasionally what they actually need.

Fig. 13Before — the 2023 query detail wireframe, one view for everyone. — project deck, slide 15

Fig. 14Your own open query: full controls. — high-fidelity prototype

Fig. 15A colleague's open query: readable, and every control gone rather than greyed. — high-fidelity prototype

Fig. 16Resolved, and raised by this same investigator — still read-only. The rule is the query's state, not ownership. — high-fidelity prototype

Decision D

A policy assistant that cites, and never acts

What was true: A large share of the questions reaching investigators were not about a case at all. They were 'how long does this take' and 'is this allowed' — answerable from published standards.
What we chose: An assistant that answers from those standards and cites the one it used, every time. It cannot change a query, and it will not answer across the permission line — it says whose query it is and stops.
What it cost: It can answer, but it cannot do. Every action it might have saved you still costs a trip to the screen that owns it.

It is also meant to be read before the work, not only during it. An investigator can check what a standard requires before starting on a query, instead of getting halfway through and finding the rule that governs it.

Fig. 17A policy answer, carrying the standard and the date it was updated. — high-fidelity prototype

Fig. 18The refusal. It names who raised the query rather than returning nothing, so the answer is still useful. — high-fidelity prototype

05

The manager’s view

The third role is the person who has to answer for the team rather than work a case. The dashboard was voted a Should Have and drawn into the navigation, and every number on it comes from that vote: the book of work, where the time actually goes, and how escalations were decided.

There is no per-person breakdown of who escalates. A league table of that is precisely the thing decision B was built to avoid.

Fig. 19The dashboard, built from the original vote rather than invented. — high-fidelity prototype

Fig. 20Seven working days. The period control counts working days, because the tool is not staffed at weekends. — high-fidelity prototype

Fig. 21Ninety. The same series at a different resolution — it zooms rather than redraws. — high-fidelity prototype

06

Everything else the vote asked for

The rest of the Must and Should list, built. Each of these traces to a line on the MoSCoW board in Fig. 06.

Fig. 22Status tracking (Must). The RM can hand a query back or withdraw it — withdrawn is never recorded as resolved. — high-fidelity prototype

Fig. 23Withdrawal takes a named reason too, for the same reason escalation does. — high-fidelity prototype

Fig. 24Reports with filters (Must). Value totals per currency, never summed across them. — high-fidelity prototype

Fig. 25Notifications to related parties (Must), as two channels — what changed in the tool, and what changed in the industry. — high-fidelity prototype

Fig. 26The landing page: what is unresolved, what is past its response time, and what is escalated. — high-fidelity prototype

07

Outcome

60% faster: Reduction in query handling time, measured post-launch.
USD 300K: Approved budget.
50+ people: Across investigations and relationship management.
3–4 hrs/week: Overtime removed per person.
17.5k: Kilograms of CO₂ avoided.

Fig. 27The cost-benefit case as it was put to the business. — project deck, slide 17

08

What the team took from it

Don’t fall in love with the first idea. The first instinct was to lock escalation down. The version that shipped left it open and made its cost visible, and it is the better design.

Involve developers right from the ideation stage. The tool had to run on a platform that was still being chosen, so what was technically possible kept moving while the screens were being drawn. The gap between what stakeholders expected and what the platform could support surfaced as pushback from the technical team — on work that had already been designed. Engineering in the room at ideation is what would have found it in week one.