August 2026 · Marketing operations · 9 min read

Running One HubSpot Instance Across 60 Offices

Ten countries, dozens of offices, and everyone had their own spreadsheet. Here is what actually worked, and the two decisions I would make differently.

One instance, ten countries, one set of definitions

When I took over marketing operations for our international office network, the system of record was a folder of spreadsheets. Each office had built its own, each used different column names, and the only way to answer "how many active partners do we have in Asia" was to email four people and wait two days.

We now run on one HubSpot instance across offices in the USA, UK, Russia, Azerbaijan, Singapore, Malaysia, Indonesia, Africa, India and Türkiye. I set it up and I administer it. This is what the work actually involved.

Start with the questions, not the objects

The instinct is to open HubSpot and start creating properties. That produces a beautiful CRM nobody can report from.

Instead I wrote down the five questions leadership actually asks, in the words they ask them:

• Which offices are ahead of or behind plan this month?
• How many active partners does each region have, and how many went quiet?
• Where did this month's business come from?
• Which deals are stuck, and at which stage?
• Who owns this relationship?

Every property, pipeline stage and required field in the build traces back to one of those five. If a field does not answer one of them, it is not required. That single rule kept the instance clean while a dozen offices asked for their own custom additions.

Pipeline design: one shared spine, local stages only where they earn it

The most common multi-office mistake is giving every region its own pipeline because "our market is different." Six months later nothing is comparable and leadership is back to asking four people by email.

What worked was a single shared pipeline for the core motion, with stage definitions written in plain language and pinned where everyone could see them. A stage is not "Qualified" because a rep feels good about it. A stage has an entry condition you could argue about in a review.

If two offices would classify the same deal differently, your stage definition is not finished.

Where a market genuinely runs a different motion, that gets its own pipeline. But the burden of proof sits with the request, not with the standard.

Custom properties: fewer than you think, named better than you think

Three rules I hold to:

• No free text where a dropdown will do. Free text fields are where reporting goes to die. Thirty offices will produce thirty spellings of the same country.
• Name properties for what they mean, not for who asked. "Partner tier" not "Ahmet's tier field". People inherit these long after the requester leaves.
• Every required field must be answerable at the moment it is required. If a rep cannot know the answer at that stage, they will invent one, and you have poisoned the data.

Permissions: the boring decision with the biggest consequences

In a network of semi-independent offices, permissions are politics. Get them wrong in either direction and you lose.

Too open and someone reorganises a shared pipeline on a Tuesday and nobody knows why the reports changed. Too locked down and every small change becomes a ticket to you, adoption dies, and the spreadsheets quietly return.

What I settled on: office-level teams with visibility of their own records, regional leads with cross-office read access, and structural changes (pipelines, properties, workflows) restricted to two administrators. Anyone can request a change; nobody can make one alone.

Most of the admin work happens from Istanbul

Workflows: automate the reminder, not the judgement

The workflows that earn their keep are unglamorous:

• Deal untouched for 21 days, notify the owner, not their manager. Escalation destroys trust in a system faster than anything.
• New partner created, assign an onboarding task with a due date.
• Required field left blank at a stage change, flag it back to the owner.
• Monthly snapshot for the review, generated automatically rather than requested by email.

What I do not automate is anything that makes a judgement call for a human, like auto-advancing stages or auto-scoring leads on thin data. Those feel clever and produce reports nobody believes.

The part everyone underestimates: adoption without authority

This was the real work. These offices operate semi-independently and do not report to me. I could not mandate anything. I had to win agreement.

Three things moved it:

I put objections into the document rather than arguing with them. When an office said "this does not fit how we work," I asked exactly where, added their case to the written standard, and told them it came from them. People defend documents they appear in.

I gave them something back in week one. Before asking anyone to enter data, I made sure the system already returned something useful to them: their own pipeline in one view, without building it themselves. A CRM that only feeds head office is a tax, and people avoid taxes.

I made the first version smaller than requested. Fewer required fields, fewer stages, less reporting. You can always add. Removing a field people already hate is much harder than never shipping it.

What I would do differently

Write the definitions before the build, not alongside it. We built and defined in parallel, which meant early records were entered under stage definitions that later changed. Cleaning that up cost more than writing the definitions first would have.

Appoint an owner in each office on day one. Not a power user, just the person who answers questions locally. Where that existed, adoption was quick. Where it did not, every question routed to me and the office stayed slow.

How to tell if it worked

Not by seat count or record count. The honest tests:

• Can someone other than the admin produce the monthly report?
• Did the spreadsheets actually stop, or do they still exist in parallel?
• When leadership asks a new question, can it be answered from the system rather than by email?

The last one is the real measure. A CRM is not a filing cabinet. It is the thing that answers the question before the meeting.

Updated: August 2026