A Consumer Duty CRM HubSpot project usually starts the same way: compliance tells RevOps “we need to be able to evidence this,” and nobody has translated that into a specific list of properties, workflows, and reports. This is not a legal explainer of the Consumer Duty itself, and it is not a substitute for a firm’s own compliance judgement about what it needs to evidence. It is a practical look at what the FCA’s own published guidance says good evidence actually looks like, and what that requires from a CRM’s configuration specifically.
Consumer Duty CRM HubSpot: What “Evidence” Actually Means
The FCA’s own guidance on outcomes monitoring is direct about what data collection on its own does not achieve: “Collecting data, listing metrics or reporting management information (MI) will not, by itself, show whether customers are receiving good outcomes.” The regulator’s own framing of what good practice looks like instead has four parts: firms should be able to explain what their information tells them, how they use it to identify risks or issues, what action they take in response, and how they consider whether those actions have improved outcomes.
Read as a CRM requirement rather than a compliance sentence, that is four separate capabilities, not one. A HubSpot instance that logs a customer interaction has captured the raw material and nothing more. Whether it can show what that interaction told the firm, whether that insight was reviewed against a pattern, whether a specific action was tracked back to it, and whether anyone checked afterwards that the action worked, are four different questions a timeline entry alone does not answer.
The Consumer Duty itself applies across four outcomes: products and services, price and value, consumer understanding, and consumer support. None of the four dictate a specific CRM structure, and this article does not attempt to map each one to a HubSpot feature, since which outcome a given interaction speaks to, and how, is precisely the kind of judgement compliance is best placed to make. What is consistent across all four, and what the rest of this article focuses on, is the same underlying requirement: a record on its own is a starting point, not a finished piece of evidence.
The Loop Most HubSpot Instances Stop Halfway Through
Most firms already capture more raw interaction data than they realise: call notes, ticket threads, form submissions, meeting records. The gap the FCA’s guidance describes is not a data-capture gap, it is a review-and-action gap. An interaction sitting in a contact timeline is not evidence of outcomes monitoring on its own; it becomes evidence once it has been reviewed for a pattern, once that pattern has produced a decision, and once that decision has been tracked through to completion.
This is where a typical HubSpot setup stops. Notes and tickets accumulate on individual records, which is exactly where a firm would want them for day-to-day service, but nothing in that structure naturally rolls a hundred individual tickets up into “here is the pattern we found, here is what we decided, here is who owns following through.” That rollup has to be built deliberately, as a reporting view, a workflow, or a dedicated tracking object, rather than assumed to exist because the underlying data does.
None of this requires exotic tooling. A custom property recording the pattern an interaction was linked to, a workflow that creates a tracked task when a threshold is met, and a report that shows open versus closed actions by category, will usually close the loop. What it does require is treating the loop as a deliberate build, not an assumption that logging the interaction was the whole job.
Why a Single Vulnerability Checkbox Fails This Test
The FCA’s same guidance names a specific area for improvement directly: “Some firms monitored outcomes for customers in vulnerable circumstances separately to other customers, but did not segment those outcomes by vulnerability drivers.” Its own example is a firm that “aggregated its vulnerability MI rather than splitting it by drivers such as health, financial resilience or life events,” which the FCA notes “can make it harder to identify whether different groups of customers with characteristics of vulnerability have different needs…” The regulator’s own good-practice example, by contrast, describes a firm that “introduced meeting recording software to create more consistent records of client conversations, including personal circumstances and indicators of potential vulnerabilities such as health issues, bereavement or other life events.”
The gap between those two examples is a property-design decision most firms make without realising it is one. A single “vulnerable customer: yes/no” checkbox is the most common way vulnerability gets modelled in a CRM, and it is what produces exactly the aggregated MI the FCA describes as making differences between customer groups harder to identify: it can flag that a customer needs different handling, but it cannot support the kind of disaggregated review the guidance describes, because the driver behind the flag was never captured. The more useful structure is a picklist or multi-select property recording the driver category itself, such as health, financial resilience, life event, or capability, rather than a single boolean standing in for all of them.
This matters beyond the property schema. In the FCA’s own survey work on the consumer support outcome, 81% of firms reported that customer-facing staff have easy access to an internal recording mechanism for the disclosure or identification of vulnerability. Access to a recording mechanism and a recording mechanism capable of supporting a disaggregated review are not the same capability, and a CRM’s property design is exactly where that distinction gets decided.
The Central Action Tracker HubSpot Doesn’t Give You
The FCA’s guidance also describes what stronger governance looked like in practice: “Other firms had integrated action records or central action trackers. These recorded actions arising from risk events, product governance, committee discussions, MI and file reviews in a single set of tracked deliverables.” That is a specific, recognisable artefact, and it is not something HubSpot’s default contact, deal, or ticket objects produce on their own.
The reason is structural rather than a HubSpot limitation specifically: tickets are built around a support interaction with a customer, and deals are built around a sale, so an action arising from a board discussion or a file review has no natural home in either.
Firms end up choosing between two real options, and the right one depends on volume and existing structure rather than a universal answer. One is adapting an existing pipeline, most commonly the ticket pipeline, with a dedicated action-tracking stage set and source property. The other is building a genuinely separate custom object, where the HubSpot tier allows one, when the volume and variety of action sources make forcing them into a support or sales pipeline more confusing than clarifying. Either way, the tracker needs to be built as a distinct thing a board can be shown, if it is to serve that purpose, rather than inferred from wherever the underlying activity happened to be logged.
How often it needs to be shown is also worth designing for up front. The FCA’s guidance notes that some firms “reported customer outcomes to their board throughout the year rather than as a standalone annual exercise,” using that information to challenge processes rather than simply receive them. A tracker built to produce one report a year tends to get built as a one-off export; a tracker built to support a running conversation with the board needs a live report or dashboard view instead, which is a different, and usually cheaper, build if it is decided on before the object structure is finalised rather than after.
Who Decides What Gets Evidenced
The most common way this goes wrong is not a missing feature, it is a missing conversation. RevOps can build any of the property structures or reporting views described above competently once it knows what is needed, but deciding what actually needs to be evidenced, at what level of granularity, and for how long it needs to be retained, is a compliance judgement call, not a CRM configuration one. A RevOps team that builds a vulnerability-driver property or an action tracker on its own best guess, without compliance sign-off on the categories and retention period, risks building something that looks thorough and does not match what the firm’s own compliance function has actually committed to monitoring.
The workable split is straightforward in principle even where it takes real conversation to reach: compliance defines what needs to be evidenced and why, RevOps translates that into properties, workflows, and reports, and both sides review the result against real records before it is treated as done. Skipping the first step and starting straight from a HubSpot build is the single most avoidable mistake in this kind of project.
A practical way to run that first step is to walk through a handful of real, recent customer interactions together, compliance and RevOps in the same room, and ask of each one: “Is this something we would need to point to if asked, and if so, what would we need to show alongside it?” That exercise surfaces the actual property and workflow requirements far faster than starting from a general list of what “good” looks like, because it forces the requirement to be stated against a record that already exists rather than a hypothetical one.
Related Reading
For the CRM foundation a build like this sits on top of, see HubSpot Consultancy. For the strategy layer connecting compliance requirements to CRM design, see RevOps Consultancy. For work specific to regulated firms more broadly, see Regulated Sector Delivery. On the broader data-quality discipline this depends on, Automated Pipeline Hygiene covers the wider practice of keeping CRM data trustworthy enough to report on.
Go deeper: RevOps Automation Maturity Model · n8n vs Zapier for RevOps Automation
Frequently Asked Questions
Does having good HubSpot records automatically satisfy Consumer Duty evidencing requirements?
No. The FCA’s own guidance is explicit that collecting data or reporting management information does not, by itself, show that customers are receiving good outcomes. Records are the raw material; a firm still needs to show the interaction was reviewed for a pattern, that a decision followed, that the decision was tracked through to completion, and that someone checked afterwards whether it worked.
Why is a single “vulnerable customer” checkbox property a problem under Consumer Duty?
The FCA has flagged aggregated vulnerability MI, given as a real example in its guidance, as making it harder to tell whether customers with different vulnerability drivers, such as health, financial resilience, or a life event, actually need different handling. A single boolean property produces exactly that aggregated result; a driver-specific property preserves the distinction instead.
What is a “central action tracker” and does HubSpot have one natively?
It is the FCA’s own term for a single record of actions arising from risk events, product governance, committee discussions, MI, and file reviews. HubSpot has no default object built for this purpose specifically; firms typically adapt a ticket pipeline with a dedicated stage set, or build a separate custom object when action volume and variety make that a cleaner fit.
Who should decide what a firm needs to evidence: RevOps, or compliance?
Compliance decides what needs to be evidenced and why, including retention and granularity; RevOps translates that decision into CRM properties, workflows, and reports. Building the CRM structure before that decision is made is the most common way these projects end up rebuilt.