TL;DR — What Changed
- Every deal now follows one of six defined stages the team actually uses, not informal tracking.
- Every automated action leaves a timestamped record, not a memory of a phone call.
- Compliance, commercial and process teams share one dashboard view instead of three different mental models.
A Full HubSpot Build That Has to Show Its Working
Six-stage pipeline. Thirteen automation workflows. Three dashboards. Built for a firm where every stage, every automated action and every record has to hold up if someone outside the business asks how a relationship was managed.
Overview
The client is a UK investment manager, authorised and regulated by the Financial Conduct Authority. That status shapes everything about how we approached this build. It’s not a HubSpot implementation in the generic sense of getting a pipeline live; it’s an implementation where every stage, every automated action and every record has to be defensible after the fact, because a regulated firm can be asked to show its working, and “we think that’s roughly what happened” is not an acceptable answer in that conversation. We went in knowing the brief wasn’t “set up HubSpot.” It was: build a system a compliance function can stand behind.
The Problem
Before this build, pipeline data lived in informal tracking, not in a structured CRM pipeline with defined stages and defined exit criteria. That’s a normal state for a growing firm to be in, and it’s not a criticism of the team; it’s simply what happens when a business has been closing deals faster than it’s been building the infrastructure to record them. The trouble is that informal tracking doesn’t survive scrutiny. If a regulator, an auditor, or a client’s own compliance team asks who touched a record, when, and why, “informal tracking” has no good answer. Most HubSpot builds start from a blank pipeline and add structure as the business figures out what it needs. This client didn’t have that luxury, because the two problems that needed solving were coupled: a pipeline the commercial team would actually use day to day, and an audit trail underneath it that would survive scrutiny it hadn’t yet faced. Solving only the first would have produced a nice-looking CRM that still couldn’t answer a compliance question. Solving only the second would have produced an audit trail nobody used, which is worse than no audit trail because it creates a false sense of coverage.
There’s a specific failure mode we’ve seen elsewhere that we were determined not to repeat here: a compliance-driven CRM build that treats the commercial team as the obstacle to be worked around rather than the primary user. That approach produces a system that technically satisfies an auditor’s checklist while being quietly ignored by the people who actually run the pipeline day to day, because nobody enjoys using a tool built to police them rather than help them. We treated the commercial team’s daily workflow as the thing we were designing for first, on the basis that a pipeline nobody uses generates no audit trail worth having, regulated or not.
Our Solution
We built both problems as one system rather than as a pipeline with compliance features bolted on afterward, because bolted-on compliance is usually the first thing that gets skipped when a rep is in a hurry.
The pipeline itself has six stages, covering the full lifecycle from first contact through to a closed and onboarded client. Six was a deliberate choice: enough granularity that the stage a deal sits in actually tells you something useful about where the relationship stands, not so many that reps stop updating it accurately because moving a deal forward feels like unnecessary admin. Underneath that pipeline sit thirteen automation workflows. These aren’t decorative; they do specific jobs. Some route enquiries to the right owner without a human having to triage every inbound lead by hand. Some enforce stage progression, so a deal can’t silently sit in the wrong stage because nobody remembered to move it. Some prompt for the specific data capture that compliance depends on, at the point in the pipeline where that data is actually available, rather than as a separate form someone has to remember to fill in later. And some create the tasks that keep a regulated pipeline moving without requiring a manager to chase every open item manually.
On top of the pipeline and the workflows sit three dashboards, each built for a different audience rather than one dashboard trying to serve everyone. One gives the commercial team pipeline visibility: what’s moving, what’s stalled, what needs attention this week. One gives whoever runs the process activity and workflow performance, so process ownership isn’t guesswork. One is built specifically for compliance oversight, showing the audit-relevant view rather than making a compliance officer reverse-engineer it from the commercial dashboard.
We designed the three dashboards to share the same underlying pipeline data rather than maintaining three separate reporting layers that could quietly drift apart from each other. That was a deliberate architectural decision, not the default outcome of building three dashboards: it would have been faster in the short term to build each one against its own query and let them diverge over time, and slower but more defensible to build one governed data layer with three views on top of it. We chose the second, because a regulated business asking “does the commercial dashboard agree with the compliance dashboard” needs the answer to always be yes, not “usually.”
How We Deployed It
We scoped, but didn’t build, one further piece: intelligence briefs pulling data from the FCA Register and the Companies House API directly into the CRM workflow, so regulatory and corporate status on a prospect would be visible inside HubSpot rather than requiring a manual lookup elsewhere. We’re stating that distinction plainly because it matters for anyone reading this as a reference for their own build: scoped is not the same as delivered, and this piece is not live in the client’s instance today. Everything else described here is.
The trade-off we made deliberately was speed of stage progression against strictness of data capture. A pipeline that demands every field before a deal can move forward is a pipeline reps learn to route around, usually by filling fields with placeholder values just to get past the gate, which defeats the entire point of capturing the data. We tuned the thirteen workflows to prompt for compliance-relevant data at natural points in the process rather than gating every stage transition on it, so the system nudges rather than blocks. That took iteration: the first version of a couple of the workflows gated too hard, we saw stage-transition friction in early use, and we loosened the gating while keeping the prompts, which got us the data capture we needed without training the team to game the pipeline to avoid it.
The other decision worth being honest about is what we didn’t automate. It would have been possible to build a workflow that auto-progressed a deal once every prompted field was filled in, removing the human step entirely. We deliberately left stage progression as a manual action taken by a person, even where every piece of supporting data was already captured. In a regulated pipeline, an automated system silently advancing a client relationship without a person deciding to do so is a harder thing to defend after the fact than a person making that call with good data in front of them. The automation’s job here is to make sure the right data exists at the right moment, not to make the judgement call itself.
The Outcome
The facts are the facts, and we’re not rounding them: six pipeline stages, thirteen automation workflows, three dashboards, for one FCA-regulated client. Beyond the numbers, the change is qualitative and we’re describing it as such. Before this build, pipeline data lived in informal tracking; after it, every deal has a defined path through six stages that the team actually uses. Every automated action leaves a record of what happened and when, rather than relying on someone’s memory of a phone call. The three dashboards give the business and its compliance function one consistent, checkable view instead of three different people holding three different mental models of where things stand. For a regulated firm, that’s the practical difference between a guess and an answer when someone asks a hard question.
What we haven’t done is claim a metric we don’t have. There’s no “time saved” or “conversion uplift” figure attached to this build, because we don’t have a clean before/after baseline for either: the client didn’t have a comparable formal pipeline before this went live, so there’s nothing to measure the new one against. What we can say honestly is what changed in kind rather than in degree: a business that couldn’t previously answer a specific compliance question quickly now can, using data the system produces as a byproduct of the team doing its normal work rather than as a separate reporting exercise bolted on afterward.
Why does an FCA-regulated firm need more than a standard HubSpot pipeline?
Because every stage, automated action and record has to be defensible after the fact. A regulated firm can be asked to show its working, and informal tracking has no good answer to who touched a record, when, and why.
Doesn’t a compliance-driven build usually end up ignored by the sales team?
That’s the specific failure mode this build was designed to avoid. The commercial team’s daily workflow was treated as the primary design target, not the audit trail, because a pipeline nobody uses generates no audit trail worth having.
Why six pipeline stages specifically?
Enough granularity that each stage means something distinct, without so many stages that reps stop bothering to update them. Thirteen automation workflows route, enforce and prompt progression between them, and three dashboards give commercial, process and compliance oversight.
See What This Looks Like for Your Stack
Related: CRM & HubSpot Consulting and Regulated-Sector Delivery. More on the team behind this build: About Equanax.