Give the customer somewhere to be while the bank works — and give the bank a way to ask a question without picking up the phone.

Context

This chapter is the other side of the previous one. An exception is raised inside the Application Workflow by a bank officer; it is lived here, by the customer.

Under the paper model, that exchange was a phone call. Governance found something unclear — a blurred document, a missing page, a question about a partner — and called the Relationship Manager, who called the customer. Nothing about it was recorded, its quality depended entirely on who made the call, and the customer had no idea any of it was happening.

The digital journey removes that call. And it removes something else: the customer's ability to ask "where is my application?" In a branch there is a person to ask. On a screen there is nothing, unless it is built.

So the portal is not a status page. It is the channel that replaces the phone call, plus the answer to a question nobody can otherwise ask.

Portal overview for a submitted application with no open queries — Arriving with nothing waiting — the state most customers find, and the one a status page has to earn the right to show.

Portal overview with a banner announcing queries awaiting the customer's response — The same screen when something is waiting — the banner sits above the road, not inside it.

Modal setting out what a complete company document must contain — What "complete" looks like, said before the customer tries — the answer to the commercial register that arrived as one page.

Query asking the customer to explain the nature of their business, answered in free text — A query with no document to upload — the officer's spoken question, kept as a question.

Query requesting an updated tax card, with acceptance criteria and an upload area — And one with a document — the same wording the customer already met at onboarding, so no second vocabulary has to be learned.

Pending queries tab showing a tax card response submitted by the customer — Resolved the moment the customer is done — not when the bank agrees. The only question they can act on is whether anything is waiting on them.

Resolved queries tab showing a national ID that has been updated — One question across however many turns it takes — a thread, not an accumulating list of apparent failures.

Decision

Identity is the application, not an account

There is no registration, and no password. Nothing for the customer to create, remember, or lose. The customer returns with either their application number, or the same email and mobile they started with, and verifies by OTP. From there the system decides where they belong: There is one entrance and a state behind it. The customer is never asked to know the difference between continue my application and track my application — the system knows where they are and takes them there. This is also what makes returning possible at all. Seven of ten tested participants paused and came back in a later session. They can, because identity is attached to the application rather than to an account someone has to maintain. Save-and-resume isn't a feature bolted onto the journey; it's a consequence of that decision. The application number is repeated across several onboarding screens on purpose — it needs to reach the customer before they know they need it. And language can be switched before entry, not after.

Decision

The query is a conversation, not a rejection

One screen, three tabs: the application overview, pending queries, resolved queries — with counts on the tabs themselves, so the customer sees whether anything is waiting on them before clicking anything. The status rail runs the full length of the process — submitted, document check, application review, account number generation, fulfilment, activation — with real dates against completed stages. The customer can see the whole road, including the parts that haven't happened yet. Where something is waiting on them, a banner sits above it with a direct way in. Each query is a ticket: a number, a timestamp, a status, the request in the customer's own language, acceptance criteria, an upload area, and a free-text reply. Three things about it matter. The wording is generated from the exception type, not typed by the officer. When governance raises an exception for a tax card, the customer receives the same phrasing they saw when the document was first requested during onboarding. The customer doesn't learn a second vocabulary in order to fix something. The officer's free-text detail is appended to that fixed line — context added, never a substitute for it. This is the difference between a channel with guaranteed quality and a phone call whose usefulness depended on who made it. Acceptance criteria come from the system, attached to the document type. What makes a valid tax card is not something the officer has to remember to write. This is a direct answer to a failure from the customer journey — commercial registers uploaded as a single first page, because nothing told the customer what "complete" looked like before they tried. And where no document exists, the query is still a query. Several exception types ask for explanation rather than a file — the nature of the business, whether buyers are also shareholders, why there are no suppliers. Those are answered in text.

Decision

Resolved means the customer is done, not the bank

A ticket moves from Pending action to Resolved when the customer submits their response — not when the bank accepts it. That is deliberate. If the status tracked the bank's internal review, a customer who had done everything asked of them would still be staring at Pending action, with no way to tell whether they had failed or were simply waiting. The status answers the only question the customer can act on: is anything waiting on me? If the answer turns out to be insufficient — the tax card uploaded front-side only — the same ticket returns to Pending action with a follow-up. Not a new exception. One question, tracked across however many turns it takes, so the customer sees a conversation rather than an accumulating list of apparent failures. And the same record is shown two ways. The customer sees a thread. The officer sees a table — the exception trail from the previous chapter. Same data, opposite presentation, because the officer is scanning dozens of applications a day and needs density, while the customer has one application and needs a story. Deciding that these are two different products rather than one shared screen is the whole design.

Notifications

Fourteen emails, each in English and Arabic, designed end to end. They map the application's lifecycle rather than its screens: case created · reminder to submit · termination warning before submission · termination · submitted · exception raised (including a variant that names the specific partner it concerns) · reminder on an open exception · termination warning at governance · terminated at governance · passed to the next unit · account number created in freeze mode · withdrawal · rejection.

Case creation email confirming the application has been started — The first email — the application number reaches the customer before they know they will need it.

Exception raised email naming the specific partner the query concerns — The variant that names the partner — because "a document is missing" is not an instruction anyone can act on.

Two things follow from that list.

The bank speaks before it goes quiet, and warns before it closes anything. Termination has a warning email ahead of it, twice — before submission and at governance. An open exception gets a reminder. Nothing lapses silently.

Warning email sent before an application is terminated for inactivity — The warning that precedes the closing — nothing lapses silently, and the customer is told twice before anything ends.

Reminder email about an exception still awaiting the customer's response — The reminder on an open question — the phone call that used to depend on whether someone remembered to make it.

The email carries the reason, not just a nudge. A customer who reads only their inbox still knows what is being asked and why. The portal is where they act; the email is where they understand.

SMS templates came ready from the bank's customer experience team — I didn't write those. The emails are mine.

Withdrawal

The customer can withdraw. It runs across more than one screen rather than a single confirmation — enough room to ask why, and enough friction to let someone reconsider, because withdrawal is usually a reaction rather than a decision. When it completes, the data is removed and the customer can start a fresh application.

Confirmation screen after an application has been withdrawn — The door, found. An applicant who wants out and cannot leave stays in the system as a ghost.

Building the exit properly matters more in a regulated product than in most. An applicant who wants out and cannot find the door doesn't stop wanting out — they abandon the application and stay in the system as a ghost.

Result

No problems have surfaced in the portal or the emails — through testing, and through the controlled release. Tracking has been understood, and notifications have arrived.

That is a real result and a limited one. Egypt is in friends-and-family release; a channel like this is tested by volume, by customers who ignore email, and by queries that take four turns instead of one. None of that has happened yet.

What can be said is narrower and still worth saying: the phone call became a channel with a record, and the customer stopped waiting in the dark.

Portal overview and query list shown together for an application with open queries — The whole channel in one frame — the road, and the questions along it. Neither existed before; both were a phone call nobody wrote down.

Next chapter: Fulfilment & AOF — the officer travels to the customer, and the account finally opens.