Banking: designing service that preserves context

Start with a bounded request

Someone asks about a request started days earlier. The operational challenge is often reconstructing what was submitted, what remains missing and who must act. Automation can begin with this follow-up, using a bounded status catalog and approved messages. Informational questions should be separated from instructions that change data, commitments or transactions. Even when they arrive through the same channel, they require different controls and owners. The conversation must preserve this distinction from the first contact.

One case instead of several conversations

A case needs an identifier, category, status, last update and accountable team. Messages can reference it without copying sensitive documents into every exchange. Linking another channel must follow the institution’s identification procedure; a matching name is insufficient. Stale information needs its own response: explain that the status requires validation and trigger review rather than presenting an undated record as current. Keep an explicit difference between information supplied by the customer and information confirmed by the institution. If a customer reports that a document was submitted but the case record does not show it, preserve both observations for review. Neither source should silently overwrite the other just to produce a simpler status.

Design the team handoff

A useful handoff contains the contact reason, checks performed, missing documents and requested action. Advisors should not have to reread the entire conversation. A mismatch between portal and case status can enter a reconciliation queue with both values and timestamps. The team resolves it and records the authoritative source. The customer update then follows that resolution, separating investigation from communication.

Measure continuity and quality

First-response time is insufficient when customers repeatedly ask the same question. Track repeat contacts per case, context-free handoffs, stale statuses and time to confirmed resolution. Compare pilot journeys with manually resolved requests, including a separate sample of conflicting records. A short, correct response may be better than an extensive explanation exposing unnecessary data. Reduce uncertainty without treating speed as permission to skip validation. Review how the journey behaves when a customer returns after several days. A previously accurate response can become outdated, so the next reply should consult the current case rather than simply repeat the earlier message.

Questions that define the pilot

Before implementation, identify which system confirms status, what each role may access and who resolves discrepancies. Choose one request type and test duplicates, incomplete documentation and returning users on another channel.

Common mistakes when designing banking follow-up

The stumbling blocks tend to sit at the edges of the flow rather than on the main path. They are worth reviewing before the channel opens to more people, since fixing them later means rewriting messages that have already gone out.

• Using one generic status such as “in progress” for stages owned by different areas, so the customer cannot tell whether the institution or they themselves must act next.
• Treating a question about a charge as informational when it actually opens a dispute with its own deadlines and owners.
• Letting the assistant echo full personal details to “confirm identity” instead of requesting only the fragment the procedure requires.
• Not defining what to say when the source system does not answer, so the silence ends up read as a final status.
• Counting messages handled without separating those that closed a question from those that triggered another call.