My Role
Design & front-end
Type
Product concept
Period
2026
The Stack
React · Custom CSS · AI-assisted build
A business account was frozen for an ownership change. Every document went in that day. A month later the account was still frozen, the POS couldn't settle, and support said "please wait another 24 hours" on every call for four weeks. The bank knew exactly what stage the review was at. The customer never did. I designed the communication layer that gap leaves missing.
A working prototype for the wait itself, not the decision. Built against dated public complaints rather than an invented brief, and constrained by what compliance genuinely cannot disclose.
"Several of the causes here cannot be designed away: mandatory holds, external registry timelines, reasons the bank is not allowed to give. What can be designed is what the customer is told while they wait."
The problem, in customers' own words
Unlike my previous case study, I didn't invent this problem. I found it in Wio Bank's own public reviews, then designed against what customers actually reported.
The clearest account, from Trustpilot:
"Our business account has been frozen since 17 February 2026 due to an ownership change request. We submitted all required documents on the same day... We were clearly told the process would take a maximum of 10 working days... Today is 16 March 2026... we have called customer support every 2–3 days, and each time we receive the same response: 'Please wait another 24 hours.'... Our business operations are being seriously affected because this account is linked with our POS system."
Trustpilot review of wio.io, March 2026
It isn't isolated. A second review, from a company whose director change went in at the beginning of March, reports the same shape independently:
"Till this day the director change was not finalised and our account frozen. No explanation. Every time we call support they say it's in process and will be done within 24h. Also cant move the money out of the account or do transactions."
Trustpilot review of wio.io, posted 3 June 2026, experience dated 12 March 2026
That last line is the one that shaped the final decision below. The freeze didn't just delay a verdict, it stopped the business from moving its own money. An independent 2026 review roundup describes the pattern as going beyond occasional bad luck: business accounts frozen for weeks despite submitted documentation, incoming transfers rejected without clear explanation, and agents giving contradictory information.
The details customers report most often:
- Documents submitted on day one, confirmed complete by the call centre, then weeks of silence
- A stated maximum of 10 working days that passes with no acknowledgement that it passed
- "Please wait another 24 hours," repeated on every call, every 2–3 days, for a month
- A phone call promising same-day activation that didn't happen
- Repeat requests for documents already sent, and contradictory answers between agents
- POS systems linked to the frozen account, so the business physically cannot take payment
Sources: Trustpilot, wio.io · aggregated reviews · independent roundup. These reviews are dated, so this study is a snapshot of what they documented through mid-2026, not a claim about the bank's service today.
The tension: you can't remove the freeze, and sometimes can't explain it
The freeze itself is frequently mandatory. Compliance rules can also prohibit the bank from explaining why a review is happening. So this is not a "make it faster" problem, and pretending it is would be dishonest.
How do you keep a business informed, oriented, and able to act when you cannot remove the freeze and sometimes cannot even explain it?
That constraint is the whole project. It rules out the obvious answer and forces every decision into the communication layer, which is precisely where the failure actually lives.
Who I designed for: an SME owner or finance lead whose business is operationally down. Payroll, suppliers, and POS are all affected. This is not inconvenience, it's existential. They call every two days because there is nothing else they can do. I designed for someone in crisis, not someone browsing.
Scope: the hold communication experience only, six screens. Out of scope: the compliance decision itself, back-office review tooling, and account opening, which my previous case study covers.
The design decisions
Each decision is problem, constraint, the options I weighed, and the choice, with the rejected option kept visible.
1. Show the stage even when you can't show the reason
Customers have no idea whether their case is moving or forgotten, and compliance rules often prohibit disclosing why a review is running. The options were to say nothing until there's a decision, or to expose the stage and owner of the review without the reason.
I exposed stage and owner. "We can't discuss it" gets heard as "nobody is working on it." Knowing a case sits with external registry verification is meaningful even when the reason stays confidential, and unlike the reason, it's disclosable.
2. Replace reassurance with a running clock
"Wait another 24 hours," repeated indefinitely, destroys trust faster than bad news. But the bank genuinely can't always predict the end date. So: keep giving a rolling 24-hour promise, or show elapsed working days against the stated maximum, updated daily.
I chose the running clock. A promise that breaks daily is worse than an honest number that's merely uncomfortable. "Working day 6 of up to 10" can't be contradicted by tomorrow.
3. Admit the estimate slipped, before the customer notices
The promised maximum passes and nobody acknowledges it, so the customer discovers it themselves and escalates angry. External verification delays are outside the bank's control, but the silence isn't. The options were to stay quiet and hope it resolves, or to proactively flag the breach with a revised estimate and a named accountable officer.
I chose proactive admission. Silence converts a process delay into a trust failure. Naming the officer and the escalation date converts "nobody cares" into "a specific person owns this."
4. Never let the status flatter itself
A tracker that says "in progress with our compliance team" while the bank is actually waiting on the customer is a lie, and it's the same dishonesty this case study exists to criticise. The blocked state is less comfortable to display than a neutral "in progress," which is exactly why the first build defaulted to the comfortable one.
I chose the explicit pause. A status that always looks fine is worthless. The paused state also tells the customer their clock isn't ticking down while they're the holdup, which removes the panic without hiding the fact.
5. Answer "has anything changed?" without a phone call
The real question behind every support call is not "what's the status" but "is it different from yesterday?" A static stage can't answer that, and most days genuinely have no news. The options were a current-status page only, or a dated activity log that includes an explicit statement when nothing has changed.
I chose the log. An unchanged status page is ambiguous, because the customer can't tell whether it's stale or accurate. The log ends with the line that does the real work: if nothing new is listed, nothing has changed, and calling won't reveal more than this page shows.
6. Own the promises you already broke
By the time a customer is a month in, the damage isn't just the delay. They were told "another 24 hours" repeatedly and once promised same-day activation that never came, so every future statement is now discounted. Agents genuinely couldn't see the external stage, so they guessed, and you can't un-say it. The options were to move on and give a better estimate from now, or to list the previous promises, say plainly they were wrong, and explain why they were made.
I chose to list them. A new estimate from a source that has been wrong repeatedly carries no weight. Naming the broken promises is the only way to make the next number credible, and explaining why, that agents couldn't see the stage and now can, shows the cause was fixed rather than just apologised for.
7. Don't stop the business from trading
Customers report POS systems linked to the frozen account, so a compliance review stops them physically taking payment. That's what converts a delay into an existential event. The account itself must stay restricted, but total lockouts are often more restrictive than the regulation requires.
I chose scoped restriction, published. The compliance requirement is about this account, not about the customer's ability to operate. So the concept keeps collecting card takings and holds them rather than rejecting them, which also means the customer's own customers never see a failed payment, and lets the business nominate an alternative settlement account for the duration. It keeps viewing balances, exporting statements for their accountant, and receiving funds available, then publishes the exact scope of what's restricted rather than leaving them to discover each blocked action by hitting it.
Two principles
Honest beats comfortable. Every screen prefers an uncomfortable fact over a comfortable ambiguity: a running clock over a rolling promise, an admitted breach over silence, a named blocker over a neutral "in progress."
Design the wait, not just the outcome. The decision was never the broken part. The weeks before it were.
What I'd test next
This is a concept, so I have design intent, not proof. If I took it further I'd test three things: whether the activity log measurably reduces inbound support calls during a hold, whether the paused state reduces perceived unfairness when the customer is the blocker, and whether publishing the access scope reduces account closures during long reviews. Those are the hypotheses the design is built to test.
Try the whole flow yourself
Notification · 17 February
Your account is on hold while we complete your ownership change.
You requested a change of ownership on 17 February. UAE regulations require us to re-verify the business before the account can operate under new ownership. Your funds are safe and remain yours throughout.
What's affected
- POS settlement to this accountWe know this one stops you trading. See below.
- Outgoing transfers and payments
- Card transactions
What still works
- Viewing balances and statements
- Receiving incoming funds (held, not rejected)
- Exporting data for your accountant
If your POS is linked to this account
Card takings will keep being collected and held — they are not rejected and your customers see nothing unusual. You can nominate a different settlement account for the duration of the hold so you keep trading.
What happens next
We've logged the four documents you submitted on 17 February. Review normally takes up to 10 working days. You'll get an email at every stage change — you don't need to call to find out where it stands.
The bank knew the stage the whole time. Everything the customer needed already existed internally and never reached the screen. That gap is the design problem.