A vulnerable customer support tool is software that helps a bank's staff notice that a customer may need extra care, record the need on a lawful basis, apply it on every channel, route specialist cases, put right what went wrong and show the board whether customers with needs fared as well as everyone else. A CRM flag does one of those things: it stores the need. Whether a flag is enough depends on how many systems contact the customer without looking at the CRM, and in most banks that is most of them, which is why the FCA's 2025 review found needs recorded and then not used. Botminds' Vulnerable Customer Support is a tool of the first kind: seven agents listen, draft, follow through, route, review, compare and assemble evidence, while colleagues record with the customer's agreement and specialists check every refund and account change.
The regulatory benchmark is the UK's: FG21/1 and the Consumer Duty. No US federal rule requires a bank to record vulnerability, so for a US bank the buying question is about service and risk rather than compliance, and the comparison below still holds. Product examples come from a fictional sample bank, Corvane Bank UK.
A CRM flag and a support tool, job by job
CRM flag: Relies on the colleague to hear the sign and remember to set it.
Vulnerable customer support tool: Hears a possible sign, checks what is on file and prompts the colleague once with words to ask.
CRM flag: A code or a free-text note, often without the basis or a review date.
Vulnerable customer support tool: The need in the customer’s words, the driver, the basis or consent passage, who recorded it and when it is reviewed.
CRM flag: Visible to whoever opens the CRM; invisible to the print run, the dialer and the fee engine.
Vulnerable customer support tool: Applied to each channel’s rules, with letters checked before they print where possible.
CRM flag: Found when the customer complains.
Vulnerable customer support tool: A look back over recent charges and contacts, with a proposed refund for a person to approve and another to check.
CRM flag: An email or a queue with no clock.
Vulnerable customer support tool: A referral with a team, an owner, a first-contact time and an escalation path.
CRM flag: Reconstructed by hand for testing and the board.
Vulnerable customer support tool: Outcome gaps by group and driver, every number cited, verified before it is signed.
What is a vulnerable customer support tool?
It is the software layer between what customers tell a bank and what the bank then does to them. A complete one covers the whole chain the FCA's guidance describes: helping staff recognise and respond, recording and retrieving needs, adapting service and communications, referring to specialist support, and monitoring outcomes. A partial one covers some links; most products sold under the name are a recording screen, a speech-analytics feed or an MI dashboard.
The users are wider than the contact centre. In the sample bank, the colleague on the phone records needs and approves small refunds; a customer support specialist checks money and account changes and works the referrals; a compliance monitoring analyst tests files and verifies the board report; the Consumer Duty manager agrees actions and signs; and an administrator keeps the consent wording, review periods, refund mandates and agent settings, each change approved by a second person.
Who uses a vulnerable customer support tool, and for what
| Role | Uses it to | Must never be able to |
|---|---|---|
| Customer service colleague | See how to help; ask when prompted; save the need with the customer’s agreement; approve refunds up to £50 | Check their own approval |
| Customer support specialist | Work referrals against a clock; check and post refunds and account changes; close needs the customer no longer wants | Approve and check the same change |
| Compliance monitoring analyst | Test files with the passage and decision on each; re-read every number in the board report against source | Sign the report they verified |
| Consumer Duty manager | See outcome gaps by group and driver; agree actions with owners and dates; sign the report; approve setting changes | Sign before verification |
| Administrator | Propose changes to consent wording, review periods, mandates and agent versions, with a written reason | Bring a change into force without approval |
Is a CRM flag enough for the Consumer Duty?
A CRM flag on its own is rarely enough to show the Consumer Duty is met, because the Duty asks about outcomes and a flag only proves that something was written down. PRIN 2A.9 requires a firm to monitor whether customers "receive the support they need" and whether any group fares worse than another. A flag cannot say whether the letter went out in large print, whether the dialer skipped the customer, or whether the bereaved paid charges the bank could have stopped.
The FCA's findings sit exactly on that gap. Its 2025 bank review found the systems to record needs in place, and no clear sign that staff consistently used them (FCA retail banks review, 2025; see recording vulnerability). Its 2026 payments review praised firms that consistently record vulnerability with system flags, and in the same publication found firms that could not show how the information was shared across the customer journey. A flag is necessary. The question is what makes it work.
Proportion matters too, and the FCA says so. For smaller payments firms it wrote that effective support "does not necessarily require complex systems or extensive processes", provided the approach is proportionate and can be shown to work. A small firm with one system, one channel and a few hundred customers may do well with a flag, a review date and regular file testing.
What a flag does well
A flag is cheap, visible and already in the CRM. Set well, it tells the next colleague that a need exists, carries a short instruction, and gives the firm a count of customers with recorded needs, which the FCA expects firms to understand. The 2026 payments review counted consistent flags in the customer management system as good practice (FCA payments firms review, 2026).
It does best where the CRM is also the system that acts: where letters, calls and collections all run from it. It does worst where it is one of several systems, which in a bank with branches, a contact centre, an outsourced print run and a collections platform is the normal case. How a single register read by every system closes that gap is the subject of our guide to the vulnerable customer register.
Where a flag stops: six jobs it cannot do
A flag cannot listen, cannot reach systems that do not read it, cannot check what happened, cannot look back, cannot run a clock and cannot compare. Each of those is a job the FCA has found firms struggling with.
It cannot prompt at the moment of disclosure. The FCA's research found only 19% of consumers with characteristics of vulnerability felt their provider had encouraged them to disclose. It cannot reach the print run: Mrs Hollis's large-print need was flagged in March 2025 and her savings statement still went out at 11 pt in September 2026, because the template did not read it. It cannot check contacts: in the sample, checking 412,600 letters, calls, fees, sales and collections contacts against needs found 61 misses in a month. It cannot look back for harm, run a specialist referral to a deadline, or compare outcomes for customers with needs against everyone, which PRIN 2A.9.10R requires a firm's monitoring to be able to do.
What a check adds to a flag: each miss found, with its cause and a fix
What features should a vulnerability tool have?
The features that matter are the ones that make a recorded need change what happens next, and the controls that keep people in charge of decisions. Ask each vendor the questions below, and ask to see the answer on screen, on your own data where possible.
Twelve questions to ask any vulnerable customer support tool
- Does it help at the moment of disclosure?
A prompt with words to ask, once, above a threshold the bank owns; or nothing at all on calls.
- Does anything get recorded without a person?
The FCA warns against relying on a model to identify vulnerability without testing. The safe answer is no.
- Is the basis kept with the need?
The consent passage, or the other condition a specialist recorded.
- Does each need say how to help in plain words?
Codes leave interpretation to the colleague.
- Which of our systems will apply it, and before or after the contact?
Name the correspondence, dialer, fee and collections systems.
- Does it check contacts against needs, and propose fixes to causes?
A miss fixed at the template stops the next one.
- Can it look back for harm already done?
Charges and contacts since the need was known, with sources.
- Are money and account changes approved by one person and checked by another?
And can the approver never check?
- Does it run specialist referrals with a clock and escalation?
Bereavement, attorneys and carers, financial difficulty.
- Does it compare outcomes by group and by driver?
With a minimum group size and a written tolerance.
- Can every number in a report be traced to source and verified before signing?
The person who signs should not be the person who verifies.
- How are its models versioned, tested and changed?
On your calls, by speaker group, with overrides recorded and a named owner.
The last question carries the most weight for any tool that uses AI. The FCA's October 2026 publication found firms trusting a language model to recognise vulnerability before testing and safeguarding it, and others relying on human review that had become a formality (FCA, AI good practice, 2026). What a listening model may and may not do, and how to test one, is set out in our guide to AI and vulnerable customers.
Can a tool look back for harm already done?
Yes, if it can read the accounts and contacts from the date the need began, and it should, because the Consumer Duty asks firms to identify customers who have been harmed and put it right. FG21/1 suggests firms check whether customers with characteristics of vulnerability end up paying particular fees and charges more often than others (FCA FG21/1; how to measure that gap is in FCA vulnerable customer outcomes). The FCA's 2025 report described a firm that found customers in vulnerable circumstances charged early-withdrawal penalties it did not think fair, and refunded them.
In the sample, the look back happens the moment the need is saved. The Follow-through agent finds that Mrs Hollis's late husband's £1,250 standing order to a care home took her joint account to −£637.60 on 1 October and that overdraft charges for 1 to 19 October came to £35.00. It proposes a refund, citing the bank's bereavement standard and the passage from the core banking record. The colleague can open the source before approving.
The source behind a proposed refund, one click from the proposal
The same look back works at the scale of a book. Across the sample bank's third quarter, the Outcomes agent found 212 bereaved customers who had paid £7,480 of overdraft interest in the 30 days after the bank recorded their bereavement, and the Consumer Duty manager agreed an action with an owner and a date. How that becomes a measured outcome is in our guide to FCA vulnerable customer outcomes.
Where Vulnerable Customer Support fits, and where it does not
Vulnerable Customer Support fits a bank or building society with a contact centre, branches and separate systems for letters, collections and complaints, serving UK retail customers under the Consumer Duty, that wants needs recorded once and followed everywhere with people deciding. It reads from the systems the bank already runs: the contact centre platform, the core banking record, the correspondence system, the collections system, the complaints system and branch appointments.
It does not fit every case, and a buyer should know where. It is not a CRM and does not replace one. It does not detect financial exploitation of older customers, which is a separate discipline with its own rules; a suspected abuse referral goes to a restricted specialist team. It is not a complaints system, though it reads complaints for the outcomes comparison. It does not decide the bank's lawful basis or policy: consent wording, review periods, mandates and channel rules are the bank's settings. And a small firm with one system and few channels may find a well-run flag and file testing proportionate, as the FCA has said for smaller firms.
A specialist's check in Vulnerable Customer Support: maker and checker on the record
Botminds estimates the working time on one disclosure, from the call to the evidence for the board, at 69 minutes by hand and 9 with the agents. On the sample bank's volume of 3,214 new disclosures in 30 days, that difference is roughly 3,200 hours a month; a bank should rebuild the arithmetic on its own volumes and handling times before relying on it.
Working minutes on one disclosure, by hand and with the agents
How to evaluate one on your own calls
Run it on a sample of the bank's own recorded calls and branch notes, with the bank's own needs register, before deciding. Vendor demonstrations on prepared calls show the screens; only the bank's calls show what the tool hears in its customers' voices and how many of its existing needs its systems are already ignoring.
Three results make a pilot decisive. First, the prompts: on a set of calls labelled in advance by two of the bank's own people, how many signs did the tool prompt on, how many did it miss, and how many prompts were false, by driver. Second, the misses: run last month's letters, sales contacts, fees and collections contacts against the existing register and count the contacts that did not respect a recorded need. Third, the repeat disclosures: how many customers told the bank the same need twice within 90 days, and where they first told it. The sample bank's figure is 3.1%, against a design target of under 1% once the tool is live. Botminds offers to run Vulnerable Customer Support on a sample of a bank's own recorded calls and branch notes; details are on the Vulnerable Customer Support page.
Questions people ask
What does a vulnerability tool cost?
Prices depend on the number of channels and systems connected and on call and contact volumes, and vendors rarely publish them. The better comparison is the cost of the work it replaces: Botminds estimates 69 minutes of people's time per disclosure by hand and 9 with its agents, which a bank can price on its own volumes and staff costs.
How do vulnerability tools work with existing systems?
By reading from and writing to the systems the bank already runs rather than replacing them. Vulnerable Customer Support reads call audio and chats from the contact centre platform, accounts and charges from core banking, letters from the correspondence system before they print, and contacts from collections and complaints, and writes refunds and account changes to core banking only after a second person checks.
Who uses a vulnerable customer support tool?
Frontline colleagues in the contact centre and branches, specialist teams for bereavement, attorneys and financial difficulty, compliance monitoring analysts, the Consumer Duty manager and an administrator. Each role should see only what it needs: in the sample bank, colleagues see how to help, while health details stay with specialists, compliance and internal audit.
How do you evaluate vulnerable customer software?
On your own calls, with your own needs register. Measure prompts against calls your people have labelled, count contacts last month that ignored a recorded need, and count repeat disclosures within 90 days; then check that no money or account change can be made and checked by the same person.
Is speech analytics the same as a vulnerability tool?
No. Speech analytics can supply one input, possible signs heard on calls, which the FCA has described as good practice when it prompts staff or triggers a review. A vulnerability tool also records the need, applies it across channels, checks contacts, routes specialist work and reports outcomes.