Vulnerable clients on WhatsApp: what to spot, what to record, what to change

Contents

1. What the regulator actually expects
2. The four drivers, translated into things clients actually type
3. Record the support need, not the medical fact
4. A flag that changes nothing is not a control
5. Outcomes monitoring for a firm with no data team
6. Frequently asked questions

A renewal message goes out on a Tuesday. The client replies on Thursday: sorry, my husband died in March, I do not really know what I am paying for any more. On a phone call, an experienced account handler hears the pause, stops talking about price and changes the conversation. In a chat thread, the same sentence can be answered in eleven seconds with a premium figure and a payment reminder — and nobody at the brokerage will ever know that a bereaved client was processed like a routine renewal.

That is the practical problem messaging creates. The FCA's expectations did not change when brokers moved onto WhatsApp. The signals did.

What the regulator actually expects

FG21/1, the FCA's finalised guidance published in February 2021, describes a vulnerable customer as someone who, because of their personal circumstances, is especially susceptible to harm — particularly where a firm is not acting with an appropriate level of care. It applies across sectors and to firms that never meet the customer directly, which includes most brokers placing personal lines business.

Under the Consumer Duty, the same expectation is framed as an outcome rather than a policy document: a firm should be able to show that clients with characteristics of vulnerability get outcomes as good as everyone else's. In March 2025 the FCA published the findings of its multi-firm review of how firms treat customers in vulnerable circumstances, and the weak point it identified was not compassion but evidence — firms often could not articulate what a good or poor outcome looked like, and did not hold data good enough to compare outcomes for vulnerable customers against the rest of the book.

For a brokerage of ten people, "data good enough to compare" is the uncomfortable phrase, because almost all of the relevant information sits inside conversations rather than inside the broker management system.

The four drivers, translated into things clients actually type

FG21/1 groups vulnerability under four drivers: health, life events, resilience and capability. They are not mutually exclusive and they are frequently temporary. Translated into a WhatsApp inbox, they look like this.

Driver	What it sounds like in a thread	What should happen next
Health	"I am out of hospital next week", "since the diagnosis I cannot drive", replies at 3am over several nights	Check whether the cover still matches the client's situation; ask how they would prefer to be contacted
Life events	Bereavement, redundancy, separation, moving a parent in, a business closing	Pause anything automated on that client; a named person takes the conversation
Resilience	"Can I split it?", "can you hold the debit order until the 30th", a second failed collection in three months	Discuss payment options before a cancellation clock starts; record the discussion
Capability	"Just do whatever you think", "I do not understand the wording", voice notes only, replies arriving from a relative	Slow down, confirm understanding in the client's own words, offer a call

Two signals are specific to messaging and worth naming in your own procedures. The first is a third party answering from the client's handset — a son dealing with his mother's motor policy is common, entirely understandable, and means the person consenting to the renewal may not be the policyholder. The second is the capitulating reply: long silence, then "yes fine whatever". On the phone that is a prompt to check; in a thread it reads like agreement and closes the file.

None of this is a diagnosis, and staff should not be asked to make one. The point of the list is narrower: these are the moments where the standard sequence should stop running.

Record the support need, not the medical fact

The most common mistake is recording too much. A note saying "client has been diagnosed with dementia" is health data — special category data under the UK GDPR, which needs a condition under Article 9 as well as a lawful basis, and which will be disclosed to the client if they ever make a subject access request. A note saying "needs extra time before any deadline, prefers a phone call, do not send automated chasers, daughter is authorised to discuss the motor policy" is operationally more useful and carries far less risk.

Three rules keep this workable:

• Write it so the next colleague does not have to ask again. Making a client repeat a bereavement to a second handler is the harm the guidance is aimed at.
• Write it where the firm can find it. A support need that exists only inside one handler's phone is not a record. Assume every note will be read back to you — our note on subject access requests that include WhatsApp threads sets out how that plays out.
• Set a review point. Vulnerability is often transient. A flag from a redundancy two years ago should be revisited, not inherited forever.

A flag that changes nothing is not a control

The FCA's review was pointed about firms that identify vulnerability and then treat the customer exactly as before. In a WhatsApp-first brokerage, the flag should visibly alter at least five things:

1. Bulk sends. Build the recipient list for a broadcast deliberately rather than firing at the whole book, and keep flagged clients out of promotional campaigns unless a human has decided otherwise.
2. Automation. Any automated or AI-assisted reply on that conversation should be suspended and routed to a named handler instead. Our governance checklist for AI-assisted replies covers the sign-off that sits behind this.
3. Deadlines. Extra time before a cancellation for non-payment, and a call rather than a third templated chaser.
4. Channel. Offer a phone call or a paper copy, record that you offered, and record what the client chose.
5. The recommendation itself. A client with low capability who "chooses" the cheapest cover has usually chosen nothing. Consumer Duty puts that back on the firm.

In ORIS this is mostly a matter of using what a shared inbox gives you: the thread belongs to the brokerage rather than to a handset, a colleague can pick up a conversation without the client starting again, auto-reply rules carry a cooldown and a cap per client, and a negative-sentiment reply produces a draft for a human to check rather than an automatic answer. There is no ready-made vulnerability field, so decide where you record the support need, keep the wording operational, and use CSV export when you need to review the flagged population outside the tool.

Outcomes monitoring for a firm with no data team

You do not need a dashboard project. A monthly extract comparing the flagged population against the rest of the book will answer most of what a supervisor would ask. Six numbers are enough to start: complaints, cancellations and lapses, renewal retention, average time to first reply, claims declined or withdrawn, and the proportion of conversations closed without a human ever replying. If the flagged group is doing worse on any of them, the Duty expects action rather than an explanation.

Keep the review short and dated, and keep the version you rejected. Evidence that you looked, found nothing and said so is worth more than a policy document nobody has opened in three years. More on running the back office in our writing on brokerage organisation.

Frequently asked questions

Does the Consumer Duty apply to our commercial clients too?

Broadly no. The Duty applies to retail customers, so the vulnerability expectations described here bite hardest in personal lines and in small commercial business where the client is an individual. That said, a sole trader in the middle of a bereavement is a person before they are a risk, and treating them as one is rarely a compliance error.

Can we ask a client directly whether they are vulnerable?

Asking the label is usually unhelpful and most clients will say no. Asking about support needs works better: whether they would prefer a call, whether they want someone else on the conversation, whether anything has changed that affects how they want to be contacted. Record the answer, not an inference.

A relative is replying from the client's phone. What do we do?

Establish who you are speaking to and what authority they have before you act on an instruction. Note it in the file, and if the arrangement is going to continue, get the policyholder's authority recorded properly rather than relying on the fact that the messages come from their number.

Is it safe to keep vulnerability notes in a messaging tool at all?

It is safe if you treat the notes as personal data with a purpose, a retention period and controlled access, and if you avoid recording health or other special category detail that you do not need. What is not safe is the alternative most firms actually run: sensitive context living in individual staff members' personal chat histories.

How do we train the team without turning this into a scripted process?

Give staff the four drivers, a short list of phrases that should stop the standard sequence, and explicit permission to slow a conversation down without asking a manager. Then review real threads in team meetings. Judgement improves from examples far faster than from a policy.