TL;DR — What Changed
- One shared place now holds every contact’s consent preferences across every business unit.
- A preference set in one part of the group doesn’t need re-establishing, and can’t be silently overridden by a stale record elsewhere.
- The group has one answer to “what has this contact agreed to” instead of as many answers as there are business units.
One Preference Centre, Every Business Unit
A single HubSpot preference centre, built to hold communication and consent choices consistently across every business unit inside a major insurance broking group, where the hard problem was never the interface, it was the data model underneath it.
Overview
The client is a multi-business-unit insurance group operating within a major broking house. Groups like this tend to grow through acquisition, which means the group as a whole often isn’t one company with one history, it’s a collection of businesses that each arrived with their own way of managing customer communications already in place. That’s a completely normal way for a group like this to have formed, and it’s not a criticism of any individual business unit. It does, however, create a specific, structural problem the moment the group wants to answer one simple-sounding question consistently across all of it: what has this contact actually agreed to hear, and from whom. We built the preference centre that answers that question, and the interesting part of this build isn’t the interface a contact sees, it’s the data model we had to design underneath it, and the archaeology of reconciling years of independently evolved consent records that had to happen before that data model could be trusted.
The Problem
Insurance groups built through acquisition accumulate separate business units, each with its own history of managing customer communications, its own opt-in and opt-out records, and often its own subscription-type identifiers that don’t map cleanly onto any other business unit’s. Left alone, that means consent gets captured differently across the same group, and there’s no single, reliable answer to what a given contact has agreed to receive. That’s not just a minor administrative inconvenience; under GDPR, a group needs to be able to answer that question accurately and consistently for every contact, and “check three different systems and hope they agree” is not a defensible answer if a regulator or a contact asks. The hardest part of this problem, and the part that made it more than a straightforward CRM build, was that the opt-outs weren’t simply scattered across systems, they were stacked against subscription-type IDs that meant different things in different business units. A subscription-type ID in one business unit’s system might represent a broad marketing consent, while the same-looking ID pattern in another business unit’s system represented something narrower, more specific, or entirely unrelated. Any preference architecture that treated those IDs as interchangeable across the group would have been actively wrong, not just imprecise, and wrong in a way that wouldn’t have been visible until a specific contact complained that a preference they’d set somewhere hadn’t actually taken effect.
Our Solution
We built one HubSpot preference centre, serving every business unit from a single mechanism rather than building a separate preference flow per business unit and trying to keep them in sync afterward. A single capture point means a contact’s preference gets recorded the same way regardless of which business unit they first engaged with, and a single shared record means that preference is held centrally rather than drifting apart across separate per-unit databases over time.
Getting there meant resolving the stacked opt-out problem first, before the preference centre itself could be built on solid ground. We worked through the group’s subscription-type IDs business unit by business unit, mapping what each one actually represented rather than assuming a shared naming convention meant a shared meaning, because in an acquisition-grown group, it often doesn’t. Where two business units had genuinely equivalent consent types, we consolidated them into one shared preference category in the new architecture. Where they didn’t, and a subscription type in one business unit had no real equivalent in another, we kept them distinct rather than forcing a false consolidation for the sake of a tidier-looking data model. A tidy data model that misrepresents what a contact actually agreed to is worse than a slightly more complex one that’s accurate, because the entire point of this build was GDPR-conscious accuracy, not visual simplicity.
This mapping exercise was, in practical terms, the majority of the engagement. Building a preference centre’s front end in HubSpot is a well-understood piece of work; reverse-engineering what a decade or more of independently evolved subscription-type IDs actually mean, business unit by business unit, without a single business unit’s records serving as a canonical reference for the others, is not. We worked from source records in each business unit’s own system, cross-referencing subscription names, historical opt-in language and, where available, the original consent-capture forms, to build a confident picture of what each ID actually represented before we let any of it inform the shared architecture. Where the historical record was ambiguous, we treated that ambiguity as a reason for caution rather than a reason to guess, defaulting to the more restrictive reading of what a contact had actually agreed to.
The result is a preference architecture that respects each business unit’s own consent surface. A contact who engaged with one business unit sees and controls the preferences relevant to that relationship, without the system either hiding genuinely separate consent categories from other business units or falsely implying that a preference set with one business unit automatically extends to an unrelated one where no such consent was ever given.
How We Deployed It
The trade-off running through this whole build was consolidation against fidelity: how much could we simplify the preference model to make it usable and maintainable, without simplifying away a genuine, legally meaningful distinction between two business units’ consent records. We erred toward fidelity throughout, because the cost of getting this wrong in the direction of over-consolidation is a compliance problem, whereas the cost of erring toward more granularity than strictly necessary is, at worst, a slightly less tidy admin interface. Those are not equivalent risks, and we designed with that asymmetry in mind rather than treating the decision as a coin flip.
We also had to design for a group that would keep changing shape after this build shipped. An insurance group built through acquisition doesn’t stop acquiring the day a preference centre goes live, and a data model that only works for the business units that existed at launch would need a rebuild the next time the group absorbed another one. We built the subscription-type mapping as a structure new business units could be onboarded into, rather than a fixed one-time migration, specifically so the group’s own team could extend it without needing us back in the room every time the group’s shape changed.
That onboarding structure has a specific shape: a defined intake process for mapping a newly acquired business unit’s existing subscription types against the group’s shared preference categories, flagging anything that doesn’t have a clean equivalent for manual review rather than auto-mapping it and risking the same over-consolidation problem we’d deliberately avoided in the original build. We documented that process for the group’s own team rather than keeping it as tribal knowledge only we understood, because a preference architecture that only its original builder can extend correctly isn’t actually solving the group’s long-term problem, it’s just deferring it to the next acquisition.
The Outcome
There’s no single locked metric attached to this build, and we’re stating that plainly rather than reaching for a number that would misrepresent what changed. We’re including it in our case studies because it proves something a metric can’t: a coherent, GDPR-conscious preference-centre mechanism working across a real, live, multi-business-unit group that had genuinely divergent consent records going in. The group now has one shared place where consent preferences live and apply consistently. A preference a contact sets in one part of the group doesn’t need re-establishing elsewhere, and it doesn’t get silently overridden by a stale record in a different business unit’s old system either. For a group that grew by acquisition, that’s not a small thing: it’s the first point at which “what has this contact agreed to” has one answer instead of as many answers as there are business units.
We’d also flag what this build doesn’t claim to be. It isn’t a full consent-management platform with its own vendor relationship and its own procurement cycle, and we didn’t build it as one. It’s a preference architecture built inside the CRM the group already runs its day-to-day commercial operations through, which was a deliberate choice: a separate consent system that lives outside HubSpot would have solved the immediate problem while creating a new one, namely another system the group’s commercial and compliance teams would need to keep reconciled against the CRM they actually work in day to day.
Why not just build a separate preference centre per business unit?
Because keeping separate flows in sync afterward is where this kind of build usually breaks. One preference centre serves every business unit from a single capture point and a single shared record.
What made this harder than a typical preference-centre build?
The opt-outs weren’t just scattered across systems, they were stacked against subscription-type IDs that meant different things in different business units, so treating them as interchangeable would have been actively wrong, not just imprecise.
Is this a GDPR-driven build?
Consent accuracy is central to it. A group needs to be able to answer what a contact has actually agreed to receive, accurately and consistently, for every contact, and checking three systems and hoping they agree isn’t a defensible answer.
See What This Looks Like for Your Stack
Related: CRM & HubSpot Consulting and RevOps Consultancy. More on the team behind this build: About Equanax.