Group-wide HubSpot: Governance and Leads

Why is a group-wide CRM a growth lever rather than an IT project?

As long as every portfolio company runs its own CRM, the revenue between the companies stays invisible. Cross-selling depends on personal networks, every unit negotiates its own software contracts, and a new group CRO spends the first quarter reconstructing pipelines instead of executing the value creation plan. That is not a tooling problem. It is a steering problem with three price tags.

• New business stays accidental. New customers and cross-selling come from chance conversations between companies, not from a systematic process.
• EBITDA stays needlessly low. Every company buys, maintains and integrates its own systems, and group reporting is rebuilt by hand in spreadsheets every month.
• Every leadership change delays value creation. New CEOs, CROs or CFOs reconstruct processes, pipelines and playbooks instead of steering value creation.

After the third add-on the starting position almost always looks the same. Company A runs an established CRM with documented processes and partly manual reporting. Company B half-maintains an island solution with its own stages and definitions. Company C works in Excel without any pipeline logic. On top sit one ERP per unit, separate marketing tools and a group report that is assembled manually. Each of these local solutions can be sensible on its own. Together they get in the way of exactly the steering the portfolio was bought for.

The questions an operating partner asks are simple. Where do synergies come from? Which forecast can we trust? How many customers do we serve twice without knowing it? Which systems are redundant? What does the next leadership change cost us? None of them can be answered from five separate systems.

Our view: For buy-and-build strategies, CRM is not a software choice. It is the layer where cross-sell, reporting and value creation become visible across portfolio companies. That is how our page on the group-wide HubSpot CRM puts it, and it is also where the scope we usually see is stated: 3-10 portfolio companies, a platform build of 3-9 months with the first rollout waves, and group dashboards live from week 8.

The business case therefore has two levels, and both are calculated separately. Only the combined view of operating cost and revenue growth produces the number a group decides on.

Webinar deck · PDF · 29 slides · German

Setting up one CRM for 5+ portfolio companies efficiently

The slides from the webinar by Erik Steffen (HubSpot Service Lead) and Eric Mattner (HubSpot Marketing Service Lead), built on a real case with 5+ portfolio companies. The deck is in German.

• Operating model and architecture: shared core, local edges, shared account model
• Rollout in six phases, with MVP boundaries and a fallback for missing integrations
• Governance, adoption and the twelve points to settle before the rollout starts

Download the deck (PDF, German)

What has to be the same across the group, and what may stay local?

The same has to be everything the group wants to compare, add up or hand over from one company to another. Local may stay everything a market or a business model genuinely does differently. If that line is not drawn deliberately, it draws itself, differently in every company and without anyone deciding it. After that it can only be corrected with a migration.

A group-wide CRM is not one uniform process. It has a shared core and a local edge, and the argument in projects is almost always about where the line between the two runs. The table is the answer that has held up in our portfolio projects.

The test for every exception is short. A local deviation is valid if the market, the customer, the business model or the delivery is genuinely different. It is not valid because it has always been that way.

In the target picture, HubSpot becomes the group's shared decision layer. That is where companies and contacts, lifecycle and pipelines, ownership and permissions, consent and GDPR, automation and routing, attribution, forecast and segmentation live. Local systems are not replaced but connected where they add clear value. Websites and forms, ERP and billing, service systems and local marketing tools can stay individual as long as they are integrated. What comes out on top is what a group actually needs. A consolidated forecast. Cross-sell signals. Evidence for the ICP. Management reporting. Clear handovers.

Our view: The operating company is a segmentation, not a second layer. Separation is not solved by duplicating objects, but by one dimension that is used consistently everywhere. That single dimension controls who owns an account, which team receives a handover, which fit definition applies, which campaign is relevant, which view a report shows, and who may see or edit.

How do you tell a CRM that works from one that only stores?

A data store shows pipeline and history when somebody looks. A system that triggers business speaks up on its own the moment a second unit already serves the same account, and it proposes the next step. For a group with five companies that is the difference between visible data and cross-selling that actually happens.

Most consolidation projects end as a system of record. That is not worthless, but it is the smaller half of the business case. The larger half only appears once the CRM addresses the user instead of the other way round.

• System of record, the data store with a go-to-market interface. Contacts and companies are captured. Pipeline is visible. History is stored. Reporting is consolidated. The user asks the system.
• System of action, the system that triggers business. Flags unprompted when an account is already served by another unit. Proposes the next action on open deals. Controls which contact receives which communication. Delivers customer context before the call starts. The system addresses the user.

After go-live the system has to deliver three things, otherwise it was just a migration.

1. Cross-sell flag. A note on the account as soon as a second unit already does business there.
2. Next best action. A concrete next step on open deals, not just a due date.
3. Differentiated outreach. A segmentation that changes which email a contact actually receives.

The foundation is the shared account model. One company, one history, several relationships. For company A the account is an existing customer with an active contract and service history. For company B it is cross-sell potential with a fit but no contact history yet. Company C runs an active deal there with its own owner and its own pipeline stage. Company D has a partner relationship without a deal. All four see the same account, and relationships, deals and responsibilities still stay steerable per company.

For that to work, six questions have to be settled before the automation, not after it.

• Who owns the account?
• Who owns the individual deal?
• Who may see, who may edit?
• How does the handover between companies work?
• How is revenue credit distributed?
• How are conflicts decided?

Our view: The cross-sell problem is not solved by everyone seeing the same data. It is solved when the system actively flags the chance and a named owner is responsible for it.

Jung von Matt is not a private equity group, but the starting position was the same. Sales ran independently inside the individual agencies, with multiple systems and multiple sales funnels, and nobody had a holistic view of the group's new business pipeline. That is exactly the pattern you find in almost every portfolio after the third add-on.

How do marketing and sales speak the same language across five companies?

An MQL is a marketing assessment. A lead is an active handover to sales. Where both carry the same word, marketing and sales argue in every company about who takes over when, and the group forecast adds up different things. The lifecycle language therefore has to be set group-wide. The handover threshold may differ per company.

A contact's path is the same in every company. It enters through a form, an import, a campaign or an event. It becomes an MQL as soon as its engagement crosses a threshold that is defined the same way group-wide. Then the local ICP checks whether industry, size, geography, role and use case fit this company. Only then does a lead exist, meaning an active handover for which sales takes over the follow-up with clear responsibility. Once sales confirms the buying potential, it becomes an SQL and a deal.

In HubSpot the lead object is the operational handover point to sales. It connects the contact and its company inside the sales workspace. According to HubSpot's own documentation, the lead object carries its own pipeline stage, separate from the lifecycle stage on contacts and companies. A contact can therefore be an MQL without a lead existing in the sales workspace yet. That separation is what makes the handover measurable.

The handover threshold, by contrast, may be local. Company A has high inbound volume, so engagement plus a fit threshold automatically create a sales lead. Company B has low, strategic volume, so a person reviews the inbox before a lead goes to sales. Both use the same lifecycle language and the same lead object. Only the threshold differs, and that is a deliberate decision rather than a historical one.

Our view: Processes are validated manually before they are automated. In a portal for one company, an unclean scoring model is an annoyance. In a portal for five companies it propagates to all of them at once.

Who decides when sales takes over?

Two questions decide it, and they are regularly mixed up. Is the contact showing interest? And does the contact's company fit this unit? Interest can be measured the same way group-wide, because a click in Hamburg is the same as a click in Zurich. Fit cannot, because target markets, deal sizes and roles differ between the companies.

So the behavioural signal is standardised and the commercial fit stays local. A group-wide engagement score rates email clicks and relevant opens, key forms and content downloads, event and webinar attendance, high-intent website activity, plus ads and social engagement with one logic. An ICP or fit score per company rates company size and headcount, industry and geography, revenue, funding and technology, role and seniority, plus the concrete need. An AI-assisted ICP check can enrich and prioritise that assessment. Workflow, routing and lead creation stay deterministic, so every handover can be explained.

How the handover then runs in practice depends on volume and data quality, not on technical feasibility.

Our view: Whoever squeezes engagement and fit into one number loses exactly the information sales needs most. Whether an active contact is also a commercial fit, or simply active.

What does marketing standardise centrally, and what stays with the companies?

Central is everything that gets compared later. Local is everything a customer sees in their market. The campaign framework, the forms, the scoring and the attribution are built once. Content, brand, events and language are executed by each company itself. That way reporting across all brands exists without a central team having to approve every campaign.

Standardised centrally are the campaign framework with a fixed naming convention, the forms and subscription types, the engagement scoring, attribution and reporting, and the filter by operating company. Owned locally are content and campaign execution, brand execution and templates, events and local activities, nurture content per market, plus language and market messaging. A naming convention can combine operating company, language, channel, campaign type, audience, topic and time period, for example OPCO-A | EN | Email | Lead Generation | CRM Leaders | 2026. Forms are created per language instead of per company, with standardised required fields and local translations, and they are duplicated from templates instead of being rebuilt. That alone prevents most unnecessary properties.

For multi-brand accounts HubSpot offers the Brands add-on, formerly Business Units. It lets forms, pages, marketing emails, campaigns and one additional brand domain be assigned to a brand, and it automatically creates a Brand property on contacts for filtering. For companies and deals, HubSpot's official documentation describes no native brand assignment. That is exactly the gap a dedicated Operating Company property closes. It works across every relevant object, meaning contacts, companies, deals and leads, and it carries the reporting too. A group-wide dashboard shows contact and lead development, campaign and email performance, deal and revenue attribution, and the engagement score, and the same structure can be scoped down to a single company without maintaining two dashboards.

One point is regularly decided too late in groups, and it is hard to repair afterwards. A contact interacts with several portfolio companies. Before the build it therefore has to be clear whether consent applies group-wide or per company, whether a contact can unsubscribe per company, which subscription types are shared, and how legacy opt-ins and double opt-in are migrated.

Our view: Marketing is part of the revenue operating model, not its campaign execution. That is why the marketing framework is designed together with the CRM and not bolted on afterwards.

In what order do you build the group-wide CRM?

Not with the software. First comes the decision which decisions should get better and where value is created in the group. Then follow process design, architecture and a small pilot with one company. Migration and automation come last. Reverse that order and the CRM translates existing ambiguity into new processes and locks it in.

The rollout runs in six phases.

1. Target picture and value creation. Which decisions should get better, where does value arise, what stays local.
2. Process design. Customer journey, pipelines, ICPs, similarities and differences, segmentation, ownership, handover.
3. Architecture and data. Objects, data fields, pipeline stages, permissions, routing, reporting layer, migration rules.
4. MVP and pilot. A small scope for a first company as the pilot.
5. Sequential rollout. Company by company, every partial migration improves the overall system.
6. Enablement and governance. Power user model, change process, adoption measurement, use in daily business.

Before the MVP is built, five decisions have to be made. Otherwise the CRM only translates existing ambiguity into new processes. The value creation goal, meaning forecast, cross-sell, new business, cost, selling time or data quality. The shared definitions from account to revenue credit. The decision rights, meaning what the group decides, what the companies decide and what the CRM admin decides. Ownership and handover for company, contact, lead, next activity, deal and forecast. And a measurable MVP with the three to five areas that should be better after the pilot. The guiding question is which decision the shared CRM makes faster, more reliable or cheaper. If there is no answer, the use case is not ready to be built.

The MVP standardises the core, not every exception in every company. In the workshop, processes and fields are described before anyone has worked in the system. Once the core is live, the power users deliver concrete refinements and new use cases from daily business. After that the scope grows deliberately, based on real decisions instead of assumptions.

Big-bang rollouts fail at the same spot. Trying to solve everything before the first test produces delay instead of insight. Too many dependencies run at the same time, decisions stay theoretical, data quality keeps deteriorating, tests and adoption start too late, feedback arrives after the architecture freeze, and teams lose trust because nothing is live. The better sequence is short. Build the core. Pilot with one company. Migrate prioritised data. Train and collect feedback. Refine and scale. In our portfolio projects that means a platform build of 3-9 months with the first rollout waves, and group dashboards live from week 8.

Our view: A delayed polish of the MVP is no reason to stop the rollout. An unclear definition is.

Which history moves, and what happens if ERP and billing are not connected yet?

History is valuable when it supports decisions. An unclear migration destroys context, an unfiltered one carries legacy problems into the new system. So data is prioritised rather than copied, and marketing may only reach out once consent has been checked. If an integration is still missing, a controlled manual handover bridges the gap instead of postponing the go-live.

Every import is preceded by the same quality checks. Field mapping, counts, associations, owners, open deals, stage mapping, consent and opt-outs, deduplication, test runs and a fallback plan. Historical source systems rarely map 1:1 to HubSpot statuses, which is why a documented mapping logic is needed. Where source data is incomplete, the team documents the limitation instead of quietly smoothing it over.

For marketing there is a strict separation between data migration and activation. Marketing contacts are only emailed once consent is validated and subscription types are assigned, never automatically with the technical import. Eight steps in a fixed order make that auditable.

1. Analyse each company's data sources.
2. Define the property mapping between source systems and the shared HubSpot data model.
3. Clean up duplicates and faulty records before the import.
4. Validate consent information instead of carrying it over unchecked.
5. Import contacts.
6. Assign subscription types per communication purpose.
7. Build suppression lists for records that can no longer be contacted.
8. Activate marketing activity only after all of the above.

And if ERP, billing or the project system are not connected yet? Then the soft handover comes first and the system handover after. In stage A, a defined deal stage creates a ticket or a task, the responsible team is notified, deal and customer context travel with it, and the project or order is created downstream by hand. In stage B, the record runs through the integration layer, the right entity in the target system is matched, the project, customer or order is created, and ID and status flow back into the CRM.

Our view: An integration that blocks the go-live is a planning error. The fallback operation is designed before the automation, not improvised after it.

Who may change what, and how does the system stay in use after go-live?

Visibility and edit rights are two separate decisions. Sales needs group-wide visibility and may edit, because cross-sell and upsell do not happen otherwise. Shared marketing assets need tight rights, because a mistake there hits every company at once. And a CRM only stays in use if leadership, incentives and routines depend on it.

Governance needs three roles. An executive sponsor is responsible for the target picture, prioritisation and resolving conflicts. A group CRM owner or RevOps owner is responsible for architecture, standards and change approval. Local power users per company are responsible for adoption, first-line questions, tests and feedback. Central standards cover data fields, naming, pipelines, workflows, integrations and change requests. For sales, an audit trail beats a lock. For marketing the opposite holds, because a wrongly changed template has a broad effect.

The change path is always the same.

1. Report the need.
2. Document the business purpose.
3. Check the existing logic.
4. Assess the group-wide impact.
5. Approve, reject or redesign.
6. Build, document, communicate.

Adoption then happens in daily business, not in training. Pipeline reviews and forecasts run from the CRM only. What is not in the system gets no revenue credit. Automation saves the team follow-up, research and reporting, and that is the user value that creates acceptance. Power users feed improvement potential back while the core system stays in place. Adoption is measured by required-field completeness, stage hygiene, maintained next activities, forecast usage, quality of associations and the number of manual handovers, in a CRM review as part of the weekly business review.

What regularly goes wrong in practice fits into eight lines.

Our view: Training explains the system. Whether it gets used is decided by leadership, incentives and routines.

Where does the value come from, and how does the CFO recognise it?

Not in the data model, but in better decisions and less operational friction. The value shows up in four fields at once. Top line through systematic cross-selling across all units. EBITDA through fewer duplicate licences and tools. Steerability through one consolidated forecast. Productivity through less context reconstruction per sales rep. Whoever measures only one of them underestimates the case.

• Top line. Systematic cross-selling across all units, faster follow-up on open chances, shared account intelligence.
• EBITDA. Fewer duplicate licences, fewer redundant tools, less manual reporting.
• Steerability. A consolidated forecast across all units, a shared KPI language, comparable pipelines, win-loss evidence from real closing data.
• Productivity. Less context reconstruction, less spreadsheet consolidation, more selling time per sales rep, a data-based ICP instead of assumptions.

Before a rollout starts, twelve points should be answered. They are the short version of this article and, at the same time, the agenda for the first conversation between the operating partner, the group CRO and marketing.

1. Value creation goal. Which outcome should get better?
2. Shared definitions. From account to revenue credit.
3. Shared vs. local. What stays deliberately different?
4. Ownership. Accounts, leads, deals, handovers.
5. Governance. Who changes properties and pipelines?
6. Permissions. Who sees, who edits?
7. Data migration. Which history is decision-relevant?
8. Integration boundaries. Which systems stay local?
9. MVP. Which decisions does the pilot test?
10. Pilot units. Who is representative and ready?
11. Enablement. Which power users, what timing?
12. Operating rhythm. Do forecast and reviews run in the CRM?

The next step is rarely a new automation. It is the decision which three to five areas of your group should be governed centrally from tomorrow, and which ones deliberately stay with the companies.

SalesPlaybook is a HubSpot Diamond Solutions Partner with 39+ five-star reviews in the HubSpot Solutions Directory, and sets up group-wide implementations starting from governance. For Jung von Matt that produced "CRM = Single Source of Truth for Sales" across a 140+ FTE agency group, in 2 months.