How to Reassign Accounts After a Merger or Acquisition

Now what?

This is one of the hardest problems in Territory Management because parent-child data is hard. Perfect hierarchy data does not exist. Different sources disagree. Ownership structures are messy. And not every acquisition matters at the same speed.

That is why the goal is not perfect hierarchy data.

The goal is clear policy.

Start with one simple hierarchy rule

Do not create different rules for ten different kinds of company structures.

That gets too complicated too fast.

Pick one clear hierarchy strategy based on how your customers buy. For most companies, that means choosing one approach and sticking to it:

• keep hierarchies together, or
• treat entities separately

The same principle applies to M&A.

You either:

• allow hierarchy changes to affect Territories live, or
• apply those changes on a cadence

Both can work.

What does not work is improvising every deal.

Decide whether M&A changes are live or batched

This is the most important policy choice.

Some companies should allow M&A-driven hierarchy changes to happen live. Others should not.

If ownership changes matter immediately in your selling motion, a live process may make sense.

If those changes usually take time to matter, or if acting immediately would create too much Territory churn, a batched refresh is probably better.

Your policy should clearly state:

• whether hierarchy changes are applied live or on a cadence
• what that cadence is
• what system or provider is the source of truth
• who can submit a suspected M&A change
• who approves the final reassignment

That matters more than having perfect data.

Freeze hierarchy data unless you have a clear exception

Territories cannot move every time a provider updates a parent account field.

That creates chaos.

Hierarchy data often needs to be frozen for Territory purposes and refreshed on a known cadence.

A simple policy is usually best:

• hierarchy is frozen as of [date]
• hierarchy is refreshed on [monthly / quarterly] cadence
• reps can submit M&A tickets at any time
• only defined exception cases are acted on before the next refresh

That gives the business stability without ignoring reality.

Existing customers are the main exception

This is where the policy usually should bend.

If an M&A event affects an existing customer, you may need to act faster. That change can affect expansion rights, renewal ownership, relationship coverage, and selling motion quickly.

Prospects are different.

In many cases, a newly acquired prospect can wait for the next refresh window without creating major harm.

So the caveat should be simple:

M&A changes involving existing customers may qualify for live review.

Let reps submit the signal, but not decide the outcome

One of the benefits of a ticket-based process is that reps help you find hierarchy changes in the wild.

That is useful.

They hear about acquisitions. They spot ownership changes. They notice when two accounts should probably be related. That can improve hierarchy quality over time.

But reps should submit the signal, not decide the Territory outcome.

The workflow should be simple:

1. Rep submits an M&A or hierarchy ticket.
2. RevOps checks the source of truth.
3. RevOps checks whether hierarchy data is currently frozen.
4. RevOps checks whether the account qualifies for an exception.
5. RevOps applies the published policy.
6. RevOps closes the loop with a clear answer.

That keeps the system open to new information without turning it into a free-for-all.

Document how hierarchy affects Territory assignment

A reassignment after M&A should not feel magical.

Reps should know:

• whether parent-child relationships affect ownership
• whether the company keeps hierarchies together or not
• whether M&A is handled live or on a cadence
• how to file a hierarchy dispute or ticket
• who makes the final call

That is how you reduce politics.

Keep the policy simple

This is the big rule.

Do not try to solve for every possible corporate structure.

Do not create separate paths for every flavor of acquisition, merger, holding company, or joint venture.

A good policy sounds like this:

• we use [source] as the source of truth for hierarchy
• hierarchy is frozen for Territory purposes and refreshed on [cadence]
• reps may submit M&A tickets at any time
• only [defined exceptions] are handled live
• existing customers may qualify for immediate review
• all other changes wait for the next refresh window

That is enough.

The takeaway

You do not need perfect hierarchy data to handle M&A well.

You need clear hierarchy policy.

That means:

• choose one hierarchy strategy
• decide whether M&A changes are live or batched
• freeze hierarchy data on a known cadence
• make existing customers the main exception
• let reps submit signals through tickets
• document how hierarchy affects Territory assignment

If those rules are clear, M&A reassignment becomes a process.

If they are not, it becomes a fight.

M&A Hierarchy Reassignment Policy Template

Policy name: M&A Hierarchy Reassignment Policy Applies to: [Sales Team / AM Team / CSM Team / Segment] Coverage model: [Territory-Based / Owner-Centric] Owner: [RevOps / Sales Ops / Sales Leadership] Last updated: [Date]

1. Purpose

This policy defines how the company handles account reassignment when a merger or acquisition affects account hierarchy.

It answers four questions:

1. When does M&A trigger review?
2. Is hierarchy handled live or on a cadence?
3. Who can submit a change?
4. When should the account actually move?

2. Decision principles

Use these principles in this order:

• hierarchy policy should be simple and consistent
• hierarchy data does not need to be perfect to be operationally useful
• live changes should be limited to defined exception cases
• existing customers may require faster review than prospects
• reps can submit signals, but RevOps applies the policy
• all hierarchy-driven Territory changes must be documented

3. Hierarchy strategy

The company uses the following hierarchy approach:

Source of truth for hierarchy: [Provider / CRM field / internal process]

4. Refresh and freeze policy

For Territory purposes:

• hierarchy is frozen as of: [Date / timing rule]
• hierarchy is refreshed on: [Monthly / quarterly / other cadence]
• hierarchy changes are applied: [Live / batched]

5. M&A ticket process

Reps may submit tickets when they believe an acquisition or merger should affect hierarchy.

Required ticket fields:

• acquired company name
• acquiring company name
• supporting evidence
• whether an existing customer is involved
• whether open pipeline is involved
• requested action

6. Exception criteria

The following cases may qualify for live review before the next refresh:

• existing customer affected by M&A
• active renewal ownership impacted
• expansion motion materially affected
• strategic account coverage materially affected
• other: [Define]

All other cases wait for the next hierarchy refresh.

7. Review workflow

8. Documentation requirements

For every approved hierarchy change:

9. Manager discretion

Managers may request exception review only for the following reasons:

• [Reason 1]
• [Reason 2]
• [Reason 3]

All overrides must be documented in: [System / Doc / CRM Field / Notion Database]

Use With AI

Download or copy the markdown version of this template and paste it directly into Claude, ChatGPT, or your LLM of choice. Then add context about your org:

• whether you keep hierarchies together or treat entities separately
• what system or provider is your source of truth for parent-child data
• whether hierarchy changes should be live or applied on a cadence
• how often hierarchy data should refresh for Territory purposes
• what should qualify as an exception
• whether existing customers should trigger faster review
• how reps submit M&A signals today
• where manager discretion should apply

The LLM will use the template structure and your context to generate a customized version for your specific M&A reassignment scenario.

Part of BoogieBoard's Territory Planning Resource Library. More templates and guides at boogieboard.ai/resources.