Vulnerable Customer Calls in Salesforce: What Should Financial Services Teams Capture?
A customer does not always announce that they are vulnerable. They might say they cannot follow the explanation, that a recent bereavement has made paperwork difficult, or that they are struggling to keep up with payments. Sometimes the signal is direct. Sometimes it appears through hesitation, confusion, distress, or a sudden change in circumstances.
For financial services teams, recognising that moment is only the beginning. The business also needs to respond with care, record the right information, protect sensitive data, and show what happened next.
That becomes difficult when the conversation takes place on an ordinary business mobile call and the useful context never reaches Salesforce.
This guide explains what a vulnerable customer call record should contain, how teams can use Salesforce without reducing people to a label, and why the completed action matters more than the presence of a flag.
What is a vulnerable customer call?
A vulnerable customer call is a conversation in which a customer discloses a support need or the employee notices information that could indicate the customer is especially susceptible to harm.
The Financial Conduct Authority describes a customer in vulnerable circumstances as someone who, because of their personal circumstances, is especially susceptible to harm, particularly when a firm does not act with appropriate care.
Vulnerability can be temporary, permanent, obvious, hidden, or changing. It may relate to health, life events, financial resilience, capability, or another circumstance that affects how a person understands information, makes decisions, or accesses support.
A single phrase should not automatically become a permanent customer label. It should create a careful opportunity to understand the person's needs and follow the firm's approved process.
Why mobile calls create a Salesforce gap
Financial services conversations do not only happen in a contact centre. Advisers, brokers, relationship managers, claims teams, and field based employees often speak with customers through normal mobile calls.
If those calls remain on the handset, Salesforce may show the customer record without the conversation that changed it. A colleague can see an open Case but not the support need disclosed during the call. A manager can see that contact happened but not whether the promised adjustment was made. A later caller may ask the customer to repeat sensitive information because the first disclosure was never recorded properly.
This is more than an activity logging problem. It can affect service consistency, data accuracy, quality review, management information, and the customer's experience.
The right goal is not to collect the largest possible amount of vulnerability data. It is to preserve enough accurate, relevant context for the business to provide appropriate support and evidence the outcome.
What should Salesforce capture after a vulnerable customer call?
A useful Salesforce record connects seven information layers. The exact objects and fields will depend on the organisation's Salesforce design, permissions, policies, and regulatory responsibilities.
1. The source call
Start with the basic event:
- Date and time
- Inbound or outbound direction
- Business number and employee identity
- Customer number where appropriate
- Call duration and connection status
- The Salesforce record matched to the call
This information establishes that the interaction happened and who handled it. It also helps teams distinguish a completed conversation from a missed call or attempted callback.
2. The customer context
The call should connect to the correct Account, Contact, Person Account, Case, Opportunity, policy, claim, or other relevant record.
Matching must preserve uncertainty. A shared household number, duplicate Contact, authorised representative, or outdated phone record can make identity ambiguous. Sensitive support information should not be attached to the wrong person simply because a number produced a possible match.
Where identity is uncertain, the safer workflow is to capture the call event, restrict downstream action, and send the match for review.
3. The disclosure or observed signal
Record what the customer said or what prompted concern in neutral, factual language. Avoid speculative diagnosis and unnecessary detail.
For example, a customer might say they need information repeated more slowly, cannot manage a digital process, have recently lost a family member, are experiencing financial difficulty, or need another person present for future conversations.
The record should distinguish between:
- A direct customer disclosure
- An employee observation
- An AI suggested signal
- A confirmed support need
- A decision made under the firm's policy
These are not interchangeable. Keeping them separate makes the record more accurate and gives reviewers the context needed to make a responsible decision.
4. The support need
The most useful record explains what would help the customer. That might include a preferred communication format, more time to consider information, an authorised third party, a different contact channel, a specialist team, or another reasonable adjustment defined by the firm's process.
A generic vulnerability flag without the support need can create work without improving the experience. The practical question is not only, "Was a signal found?" It is, "What should we do differently for this customer?"
Only collect information that is relevant to that purpose. Firms should decide which fields are necessary, who can access them, how accuracy will be checked, and when the information should be reviewed or removed.
5. The conversation evidence
Where recording and transcription are appropriate under the firm's policy and applicable rules, the Salesforce history may include:
- A controlled recording reference
- A searchable transcript
- An AI summary
- The exact section that prompted a review
- Access and retention information
The recording or transcript can provide source context, but access should be limited according to role and purpose. An AI summary is a useful interpretation, not the original conversation. It should not erase uncertainty or turn an inferred signal into a fact.
6. The action taken
The record should show what happened because of the disclosure or signal. Examples include:
- A specialist review task was created
- A communication preference was updated
- A Case was reassigned
- A promised callback was scheduled
- More time was allowed before a decision
- A document was provided in a suitable format
- A manager or compliance review was requested
Action ownership and timing matter. A flag that nobody owns is not a support workflow.
7. The outcome
Close the loop by recording whether the action was completed and whether it met the customer's need.
This is where activity becomes evidence of an outcome. The business should be able to see who acted, when they acted, what changed, and whether any further support is required.
The FCA's July 2026 outcomes monitoring update made this distinction clear. Strong monitoring does not merely show what information was collected. It connects the information to decisions, actions, and improvements for customers.
How should AI handle vulnerability signals from calls?
AI can help find moments that a busy employee or reviewer might otherwise miss. It can search transcripts for expressions of confusion, distress, hardship, bereavement, access difficulty, or a request for extra support. It can also suggest a review task or surface the relevant part of a conversation.
But a signal is not a verdict.
Language is contextual. A customer may describe someone else's circumstances. A phrase may be ambiguous. Speech recognition may be wrong. A person may have a support need without using the expected vocabulary.
A responsible workflow should therefore:
- Capture the conversation reliably.
- Preserve the source context.
- Label AI output as suggested or inferred.
- Route appropriate cases to a trained person.
- Record the decision and support action.
- Monitor false positives, missed signals, and customer outcomes.
AI should help the team notice and respond. It should not make a sensitive classification invisible, permanent, or unchallengeable.
How should vulnerability data be protected?
Information about vulnerability may be personal and sensitive. Health information can also be special category data under UK data protection law.
The joint FCA and Information Commissioner's Office statement published in 2026 confirms that data protection law does not prevent firms from using relevant information to support customers. It does require lawful, fair, transparent, accurate, and proportionate processing.
In practice, firms should define:
- The purpose for collecting the information
- The lawful basis and any additional condition required
- Which details are necessary
- Who can view, edit, and share them
- How customers are informed
- How accuracy is maintained
- How long the data is retained
- How third party sharing is governed
- How automated suggestions are reviewed
These decisions belong in the firm's data protection, compliance, and Salesforce governance design. They should not be improvised by individual employees after a difficult call.
What should managers report on?
Counting vulnerability flags is not enough. A higher number may reflect better recognition, a change in the customer base, a product problem, or inconsistent classification. The metric needs context.
More useful management questions include:
- How many possible signals received a timely review?
- How many confirmed support needs have an owner?
- Were promised adjustments completed?
- Did customers have to repeat a disclosure?
- Are particular products, journeys, or channels associated with poorer outcomes?
- Are mobile conversations represented in the same review process as contact centre calls?
- Which AI suggestions were confirmed, rejected, or missed?
- Did the action taken improve the customer's experience?
This turns Salesforce from a store of flags into a system for understanding whether support actually works.
A practical workflow for mobile financial services teams
The following workflow gives Salesforce, operations, compliance, and customer teams a common starting point.
- Capture the ordinary business mobile call.
- Match it to the correct Salesforce context.
- Preserve the recording and transcript where appropriate.
- Surface a direct disclosure or possible signal without overstating certainty.
- Ask or confirm what support the customer needs.
- Apply the firm's approved classification and data handling rules.
- Create an owned task, review, or Case action.
- Complete the promised support.
- Record the outcome and any future communication need.
- Review patterns across teams, products, journeys, and channels.
The workflow should be tested with real scenarios, including ambiguous identity, a customer who changes their preference, an authorised representative, a false AI suggestion, an urgent support need, and a call that begins on mobile before moving to another team.
Questions to ask before rollout
Before relying on any mobile call capture or vulnerability workflow, ask:
- Are ordinary cellular calls captured, or only calls made through an app?
- Can a completed call be matched to the right Salesforce record without manual recreation?
- Can the system distinguish a customer disclosure from an AI suggestion?
- Are sensitive fields protected through clear permissions?
- Can employees see the practical support need without seeing unnecessary detail?
- Does every review or adjustment have an owner and due date?
- Can managers connect signals to actions and customer outcomes?
- What happens when identity or record matching is uncertain?
- How are recordings, transcripts, summaries, and flags retained or removed?
- Can the customer record be corrected when circumstances change?
The answers expose whether the process is designed around the customer or merely around the presence of data.
Where RocketCell fits
RocketCell helps financial services teams capture ordinary business mobile calls and bring the resulting call activity into Salesforce. Where configured and appropriate, the conversation can be recorded, transcribed, summarised, and analysed for important signals, with Salesforce tasks, reviews, and workflows connected to what happened.
That matters because vulnerability support starts with the conversation the business can actually see. A policy cannot guide a call that remains on a handset. A review team cannot examine context that was never captured. A promised adjustment cannot be tracked if the disclosure never reaches the customer record.
RocketCell is the mobile conversation capture layer. The firm still decides how vulnerability is defined, what data is appropriate, who can access it, how human review works, and what good customer outcomes look like.
Conclusion
A vulnerable customer call record should do more than apply a flag. It should preserve the source conversation, record the customer's practical need, protect sensitive information, assign the right action, and show whether the promised support was delivered.
For mobile financial services teams, the first test is simple: does the ordinary customer call reach Salesforce with enough trustworthy context for the business to respond well?
When the answer is yes, Salesforce can support a consistent, careful, and measurable customer journey. When the answer is no, even a strong policy is working with only part of the conversation.