A national stock exchange: 150+ voice bots and real-time shareholder self-service

The exchange's shareholder services answer some of the most varied calls in financial services. Registered shareholders want to know what they hold and what it is worth. Directors and investors ask about dividends, reinvestment plans and tax forms. Brokers, advisers and tax authorities call on behalf of others. Lawyers and executors call about the shares of people who have died. Every one of those callers has a different relationship with the exchange, a different right to information, and a different path to the answer.

The mission was to transform that experience for every caller, not only investors, and to do it on Genesys Cloud CX. Callers would need to be recognised and verified against the exchange's own records, served with live information from its mainframe systems, and sent documents without waiting for an agent, all in either of its two languages. They would also need to be able to reach a person at any moment, with everything the IVR had learned passed to the agent who answered.

QVCCS worked as a specialist partner to a global systems integrator and Genesys reseller, which in turn provided the solution to a business process outsourcer responsible for all three parts of the service: the people, the processes they follow, and the technology. Our part was the voice solution itself, from discovery to production, over eight months for a team of seventy on Genesys Cloud CX 3. Few solutions we have built have demanded as much design, definition and documentation before the first flow was published.

1. Discovery of every caller type, contact reason and back-end service
2. Dialogue design for each menu, prompt and bot, in both languages
3. Interface definitions for every service exposed through the enterprise service bus
4. A modular Architect design with a numbered module for every task
5. Build of the inbound flows, more than 150 voice bot flows and the data actions
6. Documentation of every flow as built, task by task and variable by variable
7. Validation, user acceptance testing and the move to production

Callers reach the service on a family of numbers: a main shareholder line, dedicated lines for large issuers whose shareholders the exchange serves, a tax line for overseas holders, an employee plans line and telephone proxy voting lines. Each number lands in an ingress flow that checks data tables for planned maintenance, emergencies and business messages, applies the opening schedule and sets the caller's line of business. From there, callers pass into one of three main menu flows, each with between 84 and 87 tasks, which together call more than 150 voice bot flows.

Every menu is a voice bot built from a common template, so callers can say what they want in their own words or use the keypad. Each bot returns an intent and an exit reason, and the main flow decides where to go next. The back end is reached through eleven services that the exchange built and extended on its own enterprise service bus specifically for this programme, called from Genesys Cloud data actions over REST and JSON.

Every task carries a three-letter module code and a four-digit number, such as identification, verification, fulfilment or transfer, so that design documents, prompts, flows and reports all describe the same thing in the same words. Across the documented flows that meant around 300 tasks, nearly a thousand task-to-task transitions and more than 400 participant data attributes, each one named, defined and catalogued.

Identification starts before the caller speaks. The caller's number is looked up against the exchange's records, with anonymous and unusual numbers handled explicitly, and any match pre-fills the account, the preferred language and the contact details on file. A caller who is not recognised can identify themselves by account number, with a fixed number of attempts before they are offered a person. The IVR then asks who the caller is: a shareholder, a non-shareholder, a lawyer or executor, a broker or adviser, a tax authority, or a holder whose shares are held through a broker. Each type unlocks different journeys.

Verification uses the caller's tax identification number, checked against every holding on the account, followed by a further authentication service. The account's own flags then decide what the IVR may do. Accounts with special balances, unexchanged certificates, optional cash balances, returned mail, priority status or restrictions are routed to a person with the reason attached, and accounts with more holdings than the IVR can sensibly read out are passed straight to an agent. Nothing sensitive is read to a caller who has not earned it.

Once verified, callers can do far more than listen. They hear their holdings, broken down by certificate, direct registration, dividend reinvestment and other balances, and the current market value of their shares, priced live for up to four securities with the date and exchange of each price. Dividend dates and amounts come from a data table the business maintains itself, so a new payment date needs no flow change.

Callers can request more than thirty kinds of document, from ownership statements and duplicate tax forms to withholding tax forms, estate and transfer packages, reinvestment plan enrolment and direct deposit forms, and choose the language they are sent in. Documents can go by email or post, after the IVR checks that the address on file is current, and callers can link a mobile number to their account and receive a text message with what they need. Telephone proxy voting lines identify and verify registered holders, explain each way to vote, and connect them to the proxy team, so directors' elections and other meeting matters are handled on the same platform.

• Holdings and live market value, read back by type of holding
• Dividends, payment dates and reinvestment plan information
• Duplicate tax forms and statements, checked against what was already sent
• Forms and packages for transfers, estates and tax, in either language
• Delivery by email, post or a text message to a newly linked mobile
• Selling or transferring shares, and help for estate callers
• Telephone proxy voting guidance for registered holders

Callers in a service like this rarely travel in a straight line. They ask for a tax form, discover they need to verify first, change their mind, go back to the main menu and ask about dividends instead. The design treats that as normal. Every move between modules records where the caller came from and where they were going, so that after identification they return to exactly the journey they started.

Counters for tries, loops and no-input events are kept per menu, so a caller who struggles is offered a person rather than trapped, and every decision has a default path that hands the call to an agent with an explanation instead of ever dropping it. Forty-one distinct exit reasons and more than twenty transfer reasons are recorded, alongside flow milestones and outcomes, so the business can see why each call left the IVR and where every journey succeeded or stalled.

Callers can ask for a person from any menu. Before transferring, the flow builds the target from the line of business, the caller type and the language, sets the call's priority from a data table, and checks through a data action that agents with the right skill are actually signed in. Out of hours callers can leave a voicemail, and when queues are busy they are offered a callback. Estate callers have their own transfer flow to specialist teams.

Whichever route a call takes, it arrives with its context: whether the caller was verified and how, the account and holding they asked about, whether the email, mobile and mailing address on file are valid, whether they are calling about an estate, and why they left the IVR. Agent scripts turn that into plain statements, so the agent starts where the IVR finished.

The project was delivered on time and on budget. Every caller type, from individual investors to lawyers settling estates, now has a verified voice journey in two languages, with live holdings, prices and dividends, documents on demand and a person always available. The exchange's leadership were so pleased with the outcome that they recorded video testimonials about the programme's success, which the systems integrator now features.

For QVCCS, it remains one of the most technically demanding voice solutions we have designed: a modular architecture that the business can extend journey by journey, documented down to every variable, built on interfaces that the exchange created for it.

The scale of this solution could easily have become its weakness. What kept it manageable was discipline applied from the first workshop: a numbering scheme that every document, prompt and flow shared, a single bot template, interface definitions agreed with the exchange's engineers before their services were built, and test harnesses that let testers simulate any dialled number. Combined with a systems integrator, an outsourcer and a client who each knew their part, that discipline turned a vast set of journeys into one coherent service.

• More than 150 voice bot flows across three main menu flows
• Eleven back-end services over the exchange's enterprise service bus
• Identification, verification and self-service in two languages
• Context, milestones and outcomes tracked through every journey
• Delivered on time and on budget in eight months