How to set up territory management in a CRM

Most B2B teams end up with some blend of three dimensions: geography, vertical, and company size. The mistake is picking all three without thinking. Each dimension you add multiplies the number of cells in the grid and the chance that an account lands in a cell with no owner. Start with the dimension that actually drives the sales conversation. If a rep selling to a one-hundred-person logistics company in Ohio sounds nothing like the same rep selling to a two-thousand-person logistics company in Berlin, size and geography both matter. If the pitch, the stakeholders, and the objections look identical across sizes but shift sharply by industry, vertical is doing the work and geography is cosmetic. Interview three reps who hit quota last year and three who missed. Ask what they wish they could trade or specialize in. The pattern in those answers tells you which dimensions deserve to be in the model. Carrying a dimension you cannot defend with evidence creates a maintenance load forever.

• List every dimension someone has proposed; keep only the ones that change the sales motion, not just the account record
• Validate the shortlist with three won reps and three missed reps; capture quotes about what they wish specialization looked like
• Pick at most three dimensions for v1; a fourth almost always collapses the cell size below viable coverage
• Document the chosen dimensions and the one-sentence reason each one is in the model

Once you pick the dimensions, you have to carve each one into buckets that cover every account exactly once. Geography is the easiest to botch. Country lists are fine until you remember that many enterprise logos have offices on four continents, and a rep in Chicago is going to argue they should own the North American HQ even if the opportunity sits in Singapore. Resolve the ambiguity in the definition itself: territory follows the billing address of the parent account, or the headquarters country, or the location of the primary contact, pick one and write it down. Vertical buckets rot the same way. SIC and NAICS codes drift, and most CRMs have both the one-digit and the six-digit versions floating in the same field. Collapse your industry picklist to between eight and fifteen groupings that match how your buyers describe themselves, not how the government classifies them. Size buckets are usually employee count or revenue; pick one and reject the other, because carrying both guarantees the day a rep argues the account is enterprise by employees and mid-market by revenue. Write the buckets down with explicit lower and upper bounds, inclusive on one side only, so there is no account that could legitimately land in two cells.

• Pick one authoritative source per dimension: billing country, consolidated industry, employee count, or revenue - not two
• Define bucket boundaries with inclusive-lower and exclusive-upper bounds so no account can straddle
• Collapse industry to between eight and fifteen groupings that match buyer self-description
• Store the dimension values as required picklists on the account, not free text

Lay the dimensions out as a grid: regions on one axis, verticals on another, size bands as a facet. Count accounts in each cell using your current data. This is where fantasy meets reality. A beautiful six-region by twelve-vertical by three-size grid produces two hundred and sixteen cells, and if your total addressable list is twenty thousand accounts you are averaging ninety-three per cell, which sounds fine until you realize two-thirds of them are concentrated in six cells and the rest are sparse enough that assigning them to a rep is a rounding error. Before you assign owners, prune the grid. Collapse any adjacent cells with fewer than a healthy minimum of accounts into shared ownership. The healthy minimum depends on your deal size: enterprise motions can live with twenty-five accounts per cell, mid-market needs one hundred and fifty, and SMB wants at least five hundred. If a cell cannot carry those numbers, merge it with the nearest cell on the dimension with the smallest sales-motion delta. Pruning is where you prevent the single most common territory failure, which is reps assigned to empty rooms.

• Load current accounts into the grid and count per cell
• Flag any cell below the healthy minimum for your motion
• Merge sparse cells with the nearest neighbor on the lowest-impact dimension
• Validate that no cell carries more than three times your target rep workload after the merge

Now assign each cell to a rep or a team. The naive version writes a single owner on each cell and declares victory. The real version writes a primary owner, a secondary owner, and an overflow rule for the inbound leads that do not neatly match a cell. The secondary owner matters because reps go on parental leave, quit, or get promoted mid-year, and leaving a cell orphan for even a week will cost deals. The overflow rule matters because real inbound traffic always includes accounts you cannot classify immediately: a lead with no industry, a company whose employee count on LinkedIn disagrees with your enrichment vendor, a holding company whose billing country is one place and whose actual users sit in another. The overflow rule says what happens by default: route to the house account team, route to a round-robin among reps whose cell matches on the dimension you trust most, or hold in a classification queue for a RevOps analyst to resolve inside a defined SLA. Write the rule into the CRM as an assignment rule, not as a wiki page, and test it against a hundred historical inbound leads before you ship it.

• Assign primary and secondary owner to every cell
• Write the inbound overflow rule and encode it as a CRM assignment rule
• Test the rule against at least one hundred historical inbound leads and inspect the misroutes
• Set a classification SLA - twenty-four hours is the standard - for leads that fall into the overflow queue

Overlap is the territory system's nightmare case: two reps can plausibly claim the same account. The textbook answer is to prevent overlap by design, but the honest answer is that you will have some, and the system has to resolve the conflict quietly before it reaches the pipeline. Overlap shows up in three predictable shapes. First, parent-child accounts where a global HQ sits in one territory and the opportunity sits with a subsidiary in another. Resolve this with a parent-wins rule by default, overridden only when the subsidiary has independent purchasing authority documented on the record. Second, cross-vertical accounts, like a conglomerate whose logistics arm is relevant and whose consumer-goods arm is not. Resolve this by routing to the vertical that matches the primary use case of the lead, not the account's dominant line of business. Third, migration overlap, where an account was owned by one rep last year and the redraw puts it in another rep's cell. Resolve this with a grandfather clause: open opportunities stay with the previous rep until close, net-new motion goes to the new owner. Write all three rules down, publish them on the territory landing page in the CRM, and bake them into the assignment logic. The goal is that a rep never has to argue overlap with another rep. If they do, your rules are not sharp enough.

• Document the three overlap shapes and pick a resolution rule for each
• Encode the parent-wins and vertical-use-case rules as CRM automations, not as policy memos
• Set a grandfather window for open opportunities during the annual redraw
• Give RevOps a single-click escalation path for the edge cases the automation cannot resolve

The model is only as good as the signal that tells you when it is drifting. Instrument four metrics from day one: accounts per rep, pipeline per rep, open opportunity count per rep, and quota attainment per rep. Report them side by side in a single dashboard that leadership looks at monthly. The point is not to make every number identical. Senior reps can carry more accounts than new hires, and a market with higher conversion rates can carry a smaller account list for the same quota. The point is to see the imbalance before it rots into resentment. If one rep is carrying forty percent more pipeline than the median and still missing quota, the territory is probably oversized relative to the motion. If another is carrying thirty percent fewer accounts and overperforming, you are likely leaving coverage on the table. Instrument the imbalance warning as a dashboard filter, not a quarterly review slide, so the signal reaches leadership while there is time to act on it mid-year.

• Build a single dashboard showing accounts, pipeline, opportunities, and attainment per rep
• Highlight any rep more than twenty-five percent above or below the team median
• Review the dashboard monthly with sales leadership and RevOps together
• Capture every mid-year territory adjustment as a logged event so the annual redraw has an audit trail

Territories are not permanent. Markets grow, segments mature, reps turn over, and the model has to redraw every year or it starts punishing the exact behavior you want. The redraw is not a spreadsheet exercise done quietly in the corner by RevOps. It is a half-day workshop with sales leadership, RevOps, and a finance partner, run against the live account data and the previous year's attainment report. Walk through the grid cell by cell. Ask three questions per cell: did the owner hit quota, did the account count stay inside the healthy band, and did the overlap rules produce fewer than a documented number of escalations. Any cell that fails one of the three is a candidate for redraw. Any cell that fails two is a mandatory redraw. Publish the proposed model to the sales team at least thirty days before it goes live, with a documented appeal process for reps who think a specific account was miscategorized. The appeal process is the single highest-leverage change you can make to adoption. Reps accept a redraw they could challenge; they resent a redraw that landed on them without input.

• Schedule the redraw workshop with sales leadership, RevOps, and finance
• Pull the previous year's attainment, account count, and escalation data per cell
• Flag cells that fail on quota, workload, or escalation volume
• Publish the proposed redraw thirty days ahead with a defined appeal window

Every redraw creates handoffs. The last thing to lock before you ship is what happens when an account changes hands. Grandfathered opportunities stay with the previous rep until the opportunity closes, win or lose, and the previous rep carries the quota credit for that deal. Any new opportunity opened after the effective date goes to the new owner, who is responsible for a documented warm introduction within ten business days. Transferred account history, notes, open tasks, and contacts migrate to the new owner on the effective date; the previous rep retains read access for ninety days so they can answer questions the new owner has about relationship context. Commission accelerators and SPIFFs tied to the account are prorated on close date, not open date, which prevents the previous rep from stuffing the pipeline with speculative deals the week before transfer. Write the playbook down, give every rep a copy, and have a RevOps analyst audit the first thirty transfers to catch cases where the policy does not match the automation.

• Define the grandfather rule for open opportunities and publish the quota credit math
• Set a ten-business-day warm introduction SLA for transferred accounts
• Preserve read access for ninety days so the previous rep can field context questions
• Audit the first thirty transfers after any redraw to confirm policy and automation agree