Picture the typical customer of a high-end financial services firm: long-established wealth, often inherited or accumulated over a lifetime — old money. The portfolios that wealth produces, though, look nothing like single venerable holdings. They tend to be a dozen newly-opened or recently-transferred accounts, often consolidating from multiple prior institutions, in various states of activation, verification, and authorization. New accounts — and a lot of them. The phrase "old money, new accounts" captures the design challenge in four words: the clientele had the deep portfolios that justified premium service, and the operational reality required a system sophisticated enough to handle that complexity gracefully.

Celtic and Norse traditions both held old wealth in high regard — heirlooms, sagas, ancestral lands handed down across generations were among the most prized possessions a family could hold. So you'd think this project would have come naturally to a Celtic Viking. But the business rules governing this seemingly straightforward voice IVR turned out to be more like a labyrinth than anything Celtic spiralwork or Norse skaldic recordkeeping ever produced — and the design challenge was to make navigating that labyrinth feel effortless, conversational, and discreet enough to keep the clientele feeling well-served.

These were clients with leverage. Substantial portfolios, sophisticated expectations, and little patience for systems that couldn't keep up — exactly the population least likely to forgive an interface that fumbled their account information.

What they asked for

This project began less with what they asked for than with what I had to ask for.

The early shape of the project had been worked out before I was brought in, with the assumption — common in tool-led environments — that the conversational AI platform would do most of the heavy lifting and that design would primarily be a formatting layer on top of it. The brief I received reflected that assumption: skeletal requirements, technical specifications that left fundamental product questions unanswered, and a project plan that allocated meaningful time to neither requirements-gathering nor user experience design.

That's not how voice-driven financial services need to work. The clientele wouldn't tolerate a system that fumbled their account information, the business rules governing the engagement were considerably more complex than the early framing had suggested, and security demands — appropriately heightened for the demographic — were in tension with the basic requirement that the system actually be useful.

So my first move wasn't to design anything. It was to do the requirements-gathering that the design needed in order to proceed.
What account statuses actually existed? Active, suspended, needs-reauthorization, pending-signature, pending-verification — and several variants in between.
What could the user do in each of those statuses? Not all statuses permitted the same actions, and some required live-agent handoff.
What happened when status couldn't be retrieved? End the call? Transfer to an agent — and if so, which one? Escalate? Advise the user to wait and retry?
What level of authentication did each path require? Disclosing the existence of multiple accounts demanded more robust authentication than a single-account system, and the strength of authentication had to scale with the sensitivity of what could be discussed.

Only after those questions had answers could the actual design begin.

What we envisioned

Once the requirements were in hand, the design's architecture organized itself around three load-bearing decisions.

Authentication that scaled with sensitivity — and accommodated heterogeneous authority. A single-account voice IVR can authenticate the user once and grant them access to that account's information. A multi-account system disclosing the existence of multiple accounts — let alone their statuses — needed something more graduated. But there was a further wrinkle: not all of these accounts actually lived at our client's institution. Many were aggregated from other financial institutions through partnership arrangements, and each external institution potentially carried its own additional authentication requirements that overlaid or supplemented our client's own. The architectural decision: authentication strength would scale with what was about to be discussed, and would accommodate the layered rules of whatever external authority governed a given account. A general account inquiry required one level; revealing that multiple accounts existed required another; discussing the specifics of an active or sensitive account required the strongest — and any account governed by an external institution's additional rules required satisfying those as well. The user wouldn't experience this as a series of escalating challenges so much as a system that asked for what it needed at the moment it needed it — but underneath, authentication was load-balanced against both the sensitivity of the disclosure and the authority of the institution behind each account.

List logic as the primary navigation experience. The original brief treated multi-account handling as a sorting problem. It wasn't. With a clientele likely to have many accounts in various statuses, list navigation was the user experience — and list logic, even at its simplest, is always more complex than it appears. The design grouped accounts by threes when there were four or more (a number small enough to track aurally, large enough to make progress), and gave the user navigation controls at each grouping: repeat the last account status, repeat the current group, go back one account, go back one group, hear the next group, or cancel the playout entirely. Each status announcement also included what the status meant in plain language and what action, if any, the user was expected to take. The system wasn't just reading account statuses aloud; it was keeping the user oriented in a conversation that could otherwise have become a wall of accounting jargon.

Agent handoff as architectural element, not fallback. In some cases, the right answer to a user's status inquiry was "this needs to be handled by a person." Active accounts with sensitive activity, status-retrieval failures, security flags — these weren't system failures requiring escape hatches; they were design states with their own legitimate handling. The envisioned architecture treated agent handoff as a first-class outcome, with specific routing logic depending on the reason for handoff: which agent group, what context to hand off, what the user should be told to expect. A user transferred to an agent should never feel they had been dropped there because the system had given up; they should feel they had been brought there because that was the right place to handle their question.

Together, these three decisions defined the design space. Within that space, the actual interaction flows could be built — and the call flow grew progressively more complex as the cascading consequences of those three decisions were worked through. Layered authentication had implications for list navigation; list navigation had implications for agent handoff; agent handoff had its own authentication requirements depending on what the agent was being asked to handle. The complexity was real, but it was organizedcomplexity — the kind that a careful design can render invisible to the user even when it's working hardest underneath.

What we built

The flows that emerged from those three architectural decisions were genuinely intricate — substantially more so than the original brief had anticipated. The accompanying call flow shows the full architecture; what follows here is a walkthrough of the load-bearing sequences.

Authentication and verification. The user's first interaction was with a graduated DOB verification sequence, with separate handling for format errors, current-date sanity-check failures (a DOB that hadn't happened yet), and DOB-mismatch failures against the system of record. Each failure mode had its own retry path, with the second failure escalating to a "let me get you to someone who can help" agent transfer rather than continuing to fail in front of the user. Authentication wasn't a single-pass gate; it was an interaction, with the system's behavior calibrated to the kind of failure occurring at any moment.

API orchestration and graceful degradation. Account status data was retrieved via API call, and the system was designed to handle the realistic case of API failure or partial failure. "I'm sorry, but I've run into some trouble getting information about your bank accounts" was a real path with its own routing — not an unhandled exception bubbling up to the user. The API call itself included duplicate-culling logic, since aggregated multi-institution data routinely produced duplicate entries that needed reconciliation before list logic could even begin.

The list logic engine. With status data successfully retrieved, the system handled at least four distinct shapes of result: zero accounts, one account, two accounts, and three-or-more accounts. Three-or-more triggered the grouping logic — accounts presented in groups of three, with each group offering navigation controls (repeat the last account, repeat this group, hear the next group, stop). State tracking determined how the grouping logic terminated: a final group of one received different verbiage than a final group of two or three, because the conversational appropriateness of "would you like to hear this group again?" depends on whether the group has anything worth repeating. Each status announcement included plain-language explanation of what the status meant and what the user was expected to do — keeping the user oriented in the conversation rather than just naming labels at them.

Status-class differentiation. The flow treated different account-status classes differently. Pending Signature and Pending Verification accounts (which required user action) were grouped together and presented first, since they were where the user could actually do something. Active, Suspended, and Needs Reauthorization accounts (which were more sensitive and largely required agent assistance) were handled obliquely until the user opted into more detail or transferred to an agent. The sequence wasn't just announcing statuses; it was triaging them by user-actionability and security-sensitivity simultaneously.

Iterative loophole closure. The first version of the call flow surfaced edge-case loopholes in internal testing — sequences where the user could arrive at states the design hadn't anticipated, or where group-of-three counting could fail in specific late-sequence configurations. Rather than letting these survive into production, the flow was revisited: decision-diamond order was reversed in critical sections so total-count checking happened earlier, and intra-group particulars were verified before the user encountered them. The result was a more deterministic, more graceful flow than v1 — and the kind of iterative discipline that distinguishes shipped, reliable conversational design from prototype-quality work.

The full design grew to encompass eight distinct entry-point variants for the multi-account intro alone (different verbiage depending on whether the user arrived with multiple banks, a single bank, mixed pending and non-pending statuses, or only non-pending statuses), each with its own state-aware copy. None of that complexity was visible to the user. That was the point.

What it achieved

The design itself was the achievement. From a brief that lacked the requirements to support a coherent deployment, the work produced a complete architectural model — graduated authentication accommodating heterogeneous external authority, list logic capable of handling the full range of account-portfolio shapes the clientele actually presented, agent handoff designed as a first-class outcome, and a call flow whose loopholes had been closed through iterative testing.

Unforeseen technical constraints prevented initial deployment of the full design, but the design itself had anticipated that possibility — built-in modularity meant each functional piece was able both to stand on its own and to tightly integrate with the deployed system when later pieces came online. The architecture's value didn't depend on simultaneous full delivery; it accumulated as each component reached production. Some months later, both the client and the engagement's leadership returned to revisit the original design as the foundation for the next stages of deployment, confirming that the architectural decisions made at the outset were the ones that were going to carry the system forward.

The design has held up because it was built on the right principles in the first place: that authentication should scale with sensitivity, that list navigation is an experience and not a sorting problem, that agent handoff is a design state and not a failure mode, and that the underlying complexity of a system should be invisible to the user even when it's working hardest. None of those principles depend on the specifics of any one institution, any one platform, or any one engagement. They are how voice-driven financial services need to work — and the design that demonstrated them remains a reference point for the discipline.

What it sounded like

The sample below illustrates one of the more complex use cases the system was designed to handle. (The "Westwind Financial Services" name and the URL provided in the audio are fictionalized.)