A connected self-service and teller workflow that lets customers verify identity, select an account, upload documents and hand off a structured request for faster review.
The concept moves request preparation out of the teller conversation and into a guided kiosk journey. Customers authenticate, choose an account and service, upload supporting documents from their phone and receive a token linked to the request.
When the token reaches the teller, the correct workflow opens with the customer, account, request and uploaded data already in context. The teller reviews and approves rather than reconstructing the request from scratch.
I shaped the end-to-end experience across identity, conversational guidance, cross-device upload, token generation and teller verification, including fallback and exception considerations.
Role
Principal UX Designer
Platform
Branch kiosk, mobile web and employee desktop
Primary use cases
Cash deposits, deposit creation, cheque book requests, address updates, nominee maintenance, joint-holder updates and other branch transactions and service requests handled by tellers and Single Window Operators
Prototype walkthrough
Address update illustrates the shared kiosk-to-teller journey. Required fields, documents and review steps vary by service.
I reframed a kiosk prototype as a service-orchestration problem spanning customer and employee channels. The key design decision was to carry verified intent and request data forward, while keeping the teller accountable for regulated review and final approval.
Customers arrived with a service need, but identity checks, account selection, explanation, form completion and document handoff began only after the token was called. The teller had no useful context before the conversation started.
The teller first has to discover what the customer wants before opening the right workflow.
Account and request details are read from paper or repeated verbally, then keyed into the system.
Physical and digital documents still need to be handed over, interpreted and linked to the request.
Discovery and data entry happen at the counter while the visible queue continues to grow.
The research framing considers everyday work across cash deposits, cheque book requests, deposit creation, address changes, nominee maintenance and joint-holder updates. Each service needs different inputs and checks, but all benefit from a clear handoff of customer identity, account, intent and prepared data.
Mapped common preparation steps across services: identity and account selection, service-specific inputs, required evidence and confirmation. Cash counting and final verification remain with the teller.
Defined a shared request package: customer, account, service type, token, entered data and evidence where required. Deposit amounts, cheque book preferences and maintenance details vary by request.
Considered failed verification, incorrect account choice, cash amount discrepancies, missing signatory or nominee details, interrupted uploads and requests requiring further approval.
The customer prepares the request; the teller verifies and completes it. These personas and goals cover cash deposits, deposit creation, cheque books and account maintenance. Select any template to view it full-size.
Responsibilities: verify identity, interpret requests, process transactions and manage queue flow.
Pain points: manually reads or asks for account details, discovers the request at the counter and re-keys information while the queue grows.
Goal: Process requests quickly and accurately without spending the opening minutes reconstructing information that could already be available.
Responsibilities: take a token, prepare documents, explain the request and confirm the final outcome.
Pain points: cannot prepare the request in advance and may repeat the same details through paper, conversation and teller entry.
Goal: Get served with less waiting and repetition, while remaining in control of identity, account and document choices.
User goal
I need a prepared request with the correct customer, account and service details, so that I can verify and complete branch work accurately without re-entering information.
User goal
I need to prepare my branch request before reaching the counter, so that I can receive the right service without repeating my information.
| Branch service | Customer prepares | Teller verifies |
|---|---|---|
| Cash deposit | Account, amount and denomination breakdown | Physical cash against declared values and required checks |
| Cheque book request | Account, book preferences and collection or delivery choice | Eligibility, charges and delivery details |
| Deposit creation | Funding account, amount, term and maturity instructions | Product terms, funding, eligibility and customer confirmation |
| Address / nominee / joint holder | Requested changes and relevant documents | Evidence, consent, authority and any additional approval |
For a pilot, I would instrument the handoff rather than inventing impact figures. These measures test whether the concept reduces work without hiding failure or shifting effort to the customer.
The teller opens the token and sees the selected account, service and prepared details. For cash deposits, the next step is checking the cash; for servicing, it is checking the data and evidence. The customer continues the request without repeating the whole story.
Face scan can create a fast, low-input path, but it cannot be the only path. Customers need an understandable fallback when recognition, consent, accessibility or environmental conditions make scanning unsuitable.
Keep mobile-number and supported biometric alternatives visible; explain the purpose of verification and allow the customer to choose another method without restarting.
Multiple entry paths avoid turning one authentication method into a dead end.
The prototype uses face scan to establish customer context before service selection.
A welcome message alone is not enough. Showing held accounts and asking for an explicit choice prevents the assistant from applying a request to the wrong product relationship.
Once selected, recent or frequent actions help customers recognize common tasks while the open question supports needs such as address update.
The assistant exposes the available banking relationships before proceeding.
Frequent actions and a conversational prompt support both recognition and free-form intent.
In this prototype walkthrough, the customer enters “Address update.” Oracle Assistant turns that intent into a structured request and displays a QR code. Scanning it opens a temporary mobile upload flow, avoiding email, cables or browsing personal files on a shared kiosk.
Natural-language intent is translated into the address-update service.
The customer moves only document selection to their own device.
Selected files are visible before returning to the kiosk.
Upload completion is not the same as request completion. The customer needs to verify which files arrived and confirm the package before it enters the employee queue.
The QR session should be short-lived, bound to the active kiosk session and cleared after completion or timeout. The kiosk should expose document names and status, not leave reusable access on screen.
The kiosk confirms which documents were linked to the request.
Explicit confirmation prevents accidental submission.
The token carries the prepared request into the teller queue.
The employee dashboard exposes pending applications. Each row connects token number, account, customer, request type and status. Selecting edit opens the relevant servicing screen with available data already populated.
Token, account and request context appear together in the queue.
The teller validates the address and evidence, requests missing data when needed, then submits.
The kiosk may collect and carry data, but it does not silently approve a profile change. The teller remains responsible for review, clarification and submission.
If information is missing or inconsistent, the teller can ask the customer, correct the pre-filled data or hold the request rather than forcing a new start.
The prototype should be evaluated as a connected service rather than as isolated screens. A successful kiosk flow is not enough if the teller receives incomplete context or the customer cannot recover from an interruption.
Can the customer understand the failure, choose another method and continue without losing progress?
Can the account be changed before submission, and is the request always linked to the final choice?
Can the customer safely retry, see upload status and avoid duplicate or partially linked documents?
Can the employee correct or pause the request while preserving an auditable link to customer-provided information?
Across branch transactions and servicing, the concept establishes a clear division of work: customers prepare and confirm their request, the system preserves verified context, and tellers review and approve. This reduces avoidable discovery and re-entry without removing the judgement required at the counter.
Less repetition, clearer progress and a private way to upload documents from their own phone.
Request intent, account and documents arrive together, shifting attention from setup to verification.
A repeatable service pattern for cash deposits, cheque books, deposit creation, nominee and joint-holder maintenance, address changes and other branch requests.
Kiosk guidance, mobile document access and teller review now behave as parts of one service. The most important outcome is continuity: customers do not have to start again when they move from self-service to the employee counter.
© Designed & Coded by Mahendra Bhagavath
