Cx Vulnerability Detection

Vulnerability signals in support conversations

Customers disclose things to support agents they disclose nowhere else in a company: a bereavement, a diagnosis, a job loss, a mental health crisis, an abusive relationship, a struggle to understand what is happening to their money. In many sectors recognising that and adapting is a duty rather than a courtesy.

The analysis is worth doing and it carries more risk of harm than anything else in this catalog. Read the guardrails before the method.

The two questions, and only one is yours

"Did the customer show a signal of vulnerability?" — answerable from the conversation, and what this analysis does.

"Is this customer vulnerable, and what do we owe them?" — a judgement with consequences for how a real person is treated, and it belongs to a trained human within a defined process. Not to an analysis, and not to a model.

Keep the output at the level of signal present, and was it recognised and acted on. A system that labels people as vulnerable, and then treats them differently on that label without human judgement, is the specific failure to avoid — both because the labels will be wrong and because the label itself becomes sensitive data attached to a person.

Signal categories

Vulnerability is usually framed around drivers rather than customer types, because it is frequently transient — someone vulnerable this month may not be next month, and someone not vulnerable in general may be entirely so in the middle of a specific event.

• Health — a disclosed physical or mental health condition, a diagnosis, a hospital stay, cognitive difficulty, addiction.
• Life events — bereavement, relationship breakdown, job loss, caring responsibilities, domestic abuse, becoming a carer, imprisonment.
• Resilience — financial difficulty, inability to absorb a shock, over-indebtedness, reliance on a single income or benefit.
• Capability — difficulty understanding the product or the communication, low confidence with digital channels, language barriers, needing a third party to help.

Also treat as signals, because they are frequently the only visible trace:

• Third-party involvement — someone acting for the customer, a power of attorney, a family member calling on their behalf.
• Repeated failure to complete something the customer clearly wants to complete.
• Distress language in the conversation, including statements about being unable to cope.
• Statements of urgency tied to essentials — food, heating, rent, medication.

Detection: assume it is weak and design accordingly

Pattern matching finds explicit disclosures and misses most of the rest.

• Explicit disclosures are the easy case and even they vary enormously in phrasing.
• Capability and resilience signals are usually implicit and appear as behaviour rather than statement — the fourth call about the same form, the request to explain it again.
• Search every language you support. A single-language sweep of a multilingual operation systematically misses vulnerable customers in every other market, which is the opposite of the intent.
• Voice matters disproportionately here and transcription quality varies by accent and audio condition — so signals in voice are under-detected precisely for some of the customers most likely to need them. State this.
• Report recall honestly. Hand-label a sample and estimate what you missed. A detection rate presented without a recall estimate will be read as coverage, and in this domain that misreading has consequences.

Because recall is poor, the correct use is finding cases to review and measuring whether the process worked — not producing a definitive population count.

The audit that actually matters

Detection is the input; the finding is what happened next. For conversations with a signal present:

• Was it recognised? Did the agent acknowledge it, or continue with the standard script?
• Was it recorded, in whatever place your process specifies — and with the customer's knowledge where that is required?
• Was the handling adapted? More time, a different channel, a simpler explanation, a referral, a hold on collections activity, a specialist team.
• Was the required process followed — the referral, the specialist handoff, the forbearance step?
• Was the outcome different from the outcome a non-vulnerable customer would have had, in the direction the duty intends? This is the substantive test. Recording a flag and then proceeding identically is a compliance finding, and it is the most common one.
• Did a subsequent interaction ignore it? A signal recognised once and then lost at the next contact is a systems failure, and it is what customers experience as having to explain their bereavement four times.

Report recognition rate and adaptation rate separately. They are frequently very different, and the gap is the training and process finding.

What good looks like in the data

• Recognition rate rising while detection stays constant — agents getting better.
• The gap between recognition and adaptation closing.
• Repeat disclosure falling — customers not having to say it again.
• No adverse-outcome gap: check that customers with signals are not systematically ending up with worse resolutions, longer waits, or more escalations. If they are, that is the headline finding and it outranks everything else in the report.

Guardrails

This is the most sensitive analysis in this catalog. All of these are hard.

• Never build a persistent "vulnerable" label from a detector. Signals feed a human review. A model-assigned status attached to a customer record is a special-category-data problem and it will be wrong for real people.
• Do not use vulnerability signals for any commercial purpose. Not retention, not pricing, not segmentation, not upsell suppression beyond an exclusion, not prioritisation by value. Detecting vulnerability and then using it commercially is among the most serious conduct failures available.
• Health, and much of this, is special category personal data in many jurisdictions. Processing it needs a lawful basis, and detecting it at scale is itself processing. Flag this to whoever owns data protection before running the analysis, not after.
• Minimise and aggregate. Report counts, rates and conversation ids. Do not build a list of named customers with their disclosures, do not paste disclosure text into any report, and do not put it in a slide. If a case example is genuinely necessary, de-identify it and get agreement first.
• Restrict access to the output more tightly than an ordinary CX report, and say so when you hand it over.
• Do not diagnose, and do not infer beyond what was said. "Customer mentioned a bereavement" is a signal. Any inference about their state is not yours to make.
• Where the conversation indicates immediate risk to someone's safety, that is not an analytics finding. It goes to the defined escalation route immediately, by whatever process exists for it.
• Whether a duty applies and what it requires is for compliance and legal. Produce the evidence; do not interpret the obligation.

Present results to the user

1. The data-protection flag first — that this analysis processes special-category data, and who needs to agree to it.
2. Detection method and estimated recall, with languages and channels covered, and an explicit statement that the count is not a population.
3. Recognition rate and adaptation rate, separately, with the gap called out.
4. Process adherence — referrals, specialist handoffs, forbearance steps.
5. The substantive test — whether outcomes differed in the direction intended.
6. The adverse-outcome check — whether customers with signals fared worse. If yes, lead with it.
7. Repeat-disclosure cases, as a systems finding.
8. Aggregates and ids only. No named list, no disclosure text.
9. What needs a compliance determination, and anything requiring immediate escalation handled through its own route rather than reported here.