Multi-Country HubSpot Rollouts: Global Standards, Local Processes

A shared CRM needs common definitions. Local teams still need a system that reflects how they sell and serve customers. The design problem is deciding which differences belong in configuration, which belong in data and which reveal a process that has not been agreed.

I currently contribute to a HubSpot Enterprise rollout within Rentokil Initial’s MarTech team. This guide describes a general approach to multi-country CRM design; the examples are illustrative and do not describe confidential project configurations.

Start with a shared operational vocabulary

Agree what a customer, opportunity, qualified lead and closed deal mean across the organization. Then identify what the group needs to compare. If markets use incompatible definitions, a consolidated dashboard will produce a number without a common interpretation.

Distinguish the legal entity, selling market, service location and communication language. They may differ on the same account. A single “country” property cannot reliably answer all four questions.

Decide where each variation belongs

Do not create a separate pipeline merely to label a country. A different sequence of decisions may justify one; a reporting segment may only need an agreed property. Validate access and reporting requirements before choosing.

Give exceptions a decision owner

Local requests should have a visible path. Record the need, affected users, reason the common model is insufficient and proposed owner. Decide whether the request belongs in the shared model, a local configuration or a temporary exception.

Temporary exceptions need a review date. Otherwise they become permanent differences that future administrators cannot explain. Keep the decision alongside the configuration and link it to the relevant test.

Select pilot markets for useful differences

The easiest market may not reveal the problems that matter. Choose a manageable pilot that exercises meaningful variation: languages, business units, integrations or service models. Agree the process and data scope before importing records.

A representative pilot should include incomplete records and cross-team handoffs. Test an account with activity in more than one market, a territory change and a user who should see only the information needed for their role.

Use an acceptance checklist before extending the rollout

• Local users can complete the agreed sales and service tasks.
• Required identifiers and associations survive imports and integration updates.
• Routing has a receiving owner and a fallback for uncertain records.
• Global and local reports reconcile to the same underlying sample.
• Permissions behave as designed for each tested role.
• Training and documentation reflect the version being released.
• A named team owns issues after launch.

The purpose is to identify which parts can be reused safely. Record the differences found in the pilot before turning its configuration into a global template.

Maintain the system after launch

Agree a change rhythm with both central and local owners. Assess dependencies before modifying shared properties or workflows. Communicate what changes for users, how it was tested and where questions should go.

A successful rollout leaves teams able to work and administrators able to explain the system. The useful measure is operational reliability across markets, alongside adoption and reporting quality.

Related: my role within the Rentokil Initial MarTech team, integration ownership and CRM adoption.