Do you work with companies that operate across multiple European markets?

Yes. We at Zooma work with B2B companies that operate across several European markets, and with global companies beyond Europe. We usually start with the global headquarters, agree what should be shared across every market and what must stay local, and then roll the HubSpot setup out to local markets one at a time, with GDPR and local privacy rules built in from the start.

Why does multi-market setup matter more in 2026 than it used to?

Multi-market setup matters because B2B buyers in every market now expect the same quality of experience, while each market still has its own language, sales process and privacy rules. A setup that works for headquarters but ignores local reality gets bypassed by local teams within months.

Two things have changed. First, more mid-sized and large B2B companies in manufacturing, industrial tech, energy and professional services now run marketing, sales and service in one CRM, such as HubSpot, instead of separate local tools. Second, privacy regulation has spread: the EU's GDPR is no longer the only rule set, and companies selling into North America, Asia or Australia have to handle different requirements in the same system.

The result is a design question that a single-market company never faces: what do you standardise, and what do you let each market decide?

How do we roll HubSpot out across several markets?

We start with the global headquarters, build a shared foundation, and then implement in local markets step by step. In my experience, this is the order that keeps the setup consistent without forcing every market into the same mould.

In practice, the sequence looks like this:

1. Define the shared foundation with headquarters. Agree the data model, lifecycle stages, lead definitions (for example what counts as an MQL and an SQL), brand rules and reporting structure.
2. Build and test the foundation. Configure the core in HubSpot (Marketing Hub, Sales Hub and Service Hub as relevant) so it works for headquarters first.
3. Map each local market. Before building anything local, we learn how that market actually sells: its language, its sales process, its partners or distributors, and its legal requirements.
4. Implement locally, market by market. Each market gets the shared foundation plus its agreed local adaptations, with training for the local team.
5. Hand over and scale. Once the first markets run well, the next ones go faster, and local teams can take over parts of the onboarding themselves.
   
   

The key takeaway: a multi-market rollout succeeds when the shared foundation is decided before the first local market is built, not negotiated market by market afterwards.

What should be centralised, and what should stay local?

Centralise what you need to compare and govern across markets; localise what customers in each market experience directly. Deciding this upfront is the single most important step in a multi-market setup.

Use this table as a starting point for a workshop with headquarters and local leads, not as a fixed rule. Where a market has a genuinely different business model, more of the right-hand column applies.

Should we run one HubSpot portal or several?

It depends on how differently your markets or business units operate. Both models work, and the right choice follows from how much you need to share.

• One central portal with local adaptations fits companies where markets sell similar offerings, share a data model and need group-level reporting. It is the simpler model to govern.
• Separate portals per market or business unit, rolled out from a headquarters template, fits companies where markets operate largely independently, have different offerings, or need clear separation of data and users.

I typically see the headquarters-first approach work in both models: build the foundation once, then implement it in the local markets, whether that means local teams inside one portal or local portals based on the same template. The deciding factors are reporting needs, data separation, and how independent each market really is. We will cover this decision in more depth in a separate article.

How do you handle GDPR and privacy across markets?

We build GDPR into the data architecture from the start, including consent management, subscription types, cookie consent, retention rules and lawful-basis tracking, rather than adding it after launch. With a Nordic and European base, this privacy-first way of working is our default.

For companies operating outside Europe, the same principle applies to other privacy regimes: each market's requirements are considered in the setup. One boundary is important: we handle privacy from an implementation and technical perspective, while legal decisions, such as privacy policy wording, whether to use double opt-in, or how a regulation applies in a specific market, should always be made by your legal team or legal advisor.

Special cases and exceptions

This approach applies to B2B companies with a headquarters that can own shared decisions. It works less well, or needs adjusting, in these situations:

• There is no real headquarters mandate. If local markets operate as fully independent companies and won't accept shared definitions, start with a single pilot market rather than a group-wide rollout.
• You only sell in one or two closely related markets. The full centralise/localise exercise is unnecessary; a single setup with language variants is usually enough.
• Your business is mainly US- or APAC-facing. We work internationally, but if Europe is a small part of your business, weigh whether a partner with a larger presence in your main region fits better.
• A market has strict data-residency or sector-specific rules. Involve legal and IT before deciding on portal structure, because this can force separation regardless of what is simplest.

Actionable takeaways

• Agree the shared foundation first (high priority, low effort). Run one workshop with headquarters and two or three local leads to fill in the centralise/localise table above.
• Fix definitions before configuration (high priority, medium effort). Lead definitions, lifecycle stages and data ownership should be agreed in writing before anything is built.
• Pilot in one local market (medium effort). Choose a market with an engaged local lead, launch, learn, and adjust the template before rolling it out further.
• Bring legal in early (low effort, high risk reduction). Ask your legal team to confirm consent and privacy requirements per market before the build starts.
• Plan for handover (medium effort). Train local teams so they can onboard new colleagues and run day-to-day work themselves once the foundation is stable.