Keep the waiting customer informed through the device that is actually with them — and make sure an interrupted application is remembered by the phone, not by the customer.
Context
The web portal chapter established the structure: identity attached to the application rather than an account, queries as a tracked conversation, Resolved meaning the customer's side is done. All of that carries over unchanged.
What mobile changes is reach. On the web, the bank could speak to an absent customer through two channels — email and SMS. Both depend on the customer going somewhere: an inbox, a messages app. The phone adds the channel that goes to them.
Decision
Push joins the conversation
On mobile, a third channel arrives: push notifications, alongside email and SMS. Push carries the moments where silence costs the most: modules started and not finished, an application never submitted, and — critically — queries raised by bank staff in the Application Workflow, surfacing on the lock screen of the person who has to answer them. The exception loop that the web case file built across three systems now ends in a pocket instead of an inbox. The permission ask is a designed step, and its timing is the design. I ask for notification permission immediately after the OTP — after the customer has invested effort and identity, before they can drift. Not on first launch, when the app is a stranger and refusal is the rational answer. The screen says why: so we can follow up on unfinished modules and let you know when the bank asks you something. The reasoning is the same environmental reading that shaped the onboarding chapter, and it is mine: on mobile, leaving is normal. The customer starts in the car, on a break, walking. A journey designed for interruption needs a way to call people back — otherwise the dashboard that welcomes returns has no returns to welcome.
What carries over, natively
The portal structure is the web's, delivered in native patterns: the application overview with its status rail, pending and resolved queries with counts, ticket-style conversations per query. Where a query asks for a document, the answer is captured the same way onboarding captures — camera, photos, or files, with the scan-and-merge model for multi-page documents.
One consequence is worth naming: the device that receives the query is the device that answers it. On the web, a customer reading an exception email at work still needed to find the documents later. On mobile, the request, the camera, and the papers in the drawer are in the same room.
Result
Designed, internally validated, not yet built — same status as the onboarding chapter, same discipline: no claims beyond the design.
The claim the design itself supports: the web gave the waiting customer a place to check. Mobile gives the bank a way to reach, and the customer a way to answer from wherever the interruption left them. The conversation that was once a phone call, then a channel, is now ambient.
This completes the Neobiz Mobile case file. See: [Results Table — Neobiz Mobile] for the honest close, and the sibling [Egypt Acquisition (Web)] for the architecture this app plugs into.