Skip to main content

6. Sales Territory Design

Click here to go to the Overview Video for this Playbook
(the transcript is below)

Action Step

Complete this before moving on.

Watch the full overview video above and read through the transcript below. Pay attention to the difference between balancing territories by account count versus account value, and why growth cuts need to be designed from the start.

Comment in Slack

Post your answer in your onboarding channel.

What did you learn? What clicked?

Any questions — or will you have more questions once you actually get into the hands-on trainings? Either is fine. Just capture where you are right now.


Part 1: Hook / Open

A CRO is scaling the sales team from five reps to fifteen, and someone asks "how are we going to divide up the accounts?"

And the honest answer is... there's a list of states someone drew on a whiteboard six months ago.

One rep has California — which represents fifteen to twenty percent of the company's total addressable market — and another rep has thirty Midwest states with a fraction of that opportunity.

That's a pattern we see constantly at startups that are scaling. Reps can tell immediately whether they've been handed a winning territory or a losing one. And if they've been handed a losing one, the best ones leave.

And the project that fixes it is what we call Sales Territory Design.

So what is Sales Territory Design? It's the infrastructure that takes your total addressable market, values every account, and distributes those accounts across your sales team so every rep has a fair shot at hitting quota — balanced by both the number of accounts and the dollar value of those accounts.

My name is Yasin from LeanScale, and in this video I'm going to break down for you our entire Sales Territory Design Playbook... what it is, the core concepts, how it gets built, and what changes once it's in place.


Part 2: What Sales Territory Design Is

So when we talk about the territory design project, what we're actually building under the hood is the data model, the segmentation logic, and the assignment infrastructure inside of a CRM.

It's what determines which accounts belong to which rep and why.

On the input side there's existing customer data, account firmographics, contract values for benchmarking, and the growth plan for how the team is scaling over the next eighteen months.

On the output side, every account in the CRM has a dollar value attached to it, every rep has a defined territory balanced by both count and value, and there's a system that automatically routes new accounts to the right person.

Now the beautiful thing is once it's built, the routing runs in the background. New accounts come in, the system evaluates their size, geography, and industry, checks it against the territory object, and assigns them to the right rep automatically.

Now that routing layer — taking the territory definitions and turning them into live assignment logic — that's actually its own project called Lead Routing.

The way I think about it is territory design is the blueprint — it answers who should own what and why. Lead routing is the construction — it takes those definitions and builds the CRM automation that enforces them on every single lead.

They're two halves of the same system and that's why they are two different projects — but in this video we're focused on the blueprint side, the territory design itself.

The way I like to explain the sales territory project is what I call the fishing hole problem. Imagine sending three fishermen to a pond with a hundred fish and two fishermen to a lake with ten thousand fish, and then wondering why the lake team outperforms.

That's what happens when territories are balanced by geography alone — equal square miles, wildly unequal opportunity.

Territory design is about distributing the fish, not the water — making sure every rep has a comparable shot at quota based on what the accounts are actually worth.


Part 3: Sales Territory Design Pro Tips

Now the Playbooks Library below this video goes deep on the full methodology behind the territory design project — but before we get into how it gets built, here are a couple things you really don't want to get wrong when implementing this into a startup.

First — the difference between balancing territories by account count versus account value. Almost every company we work with balances on count alone, and that's a problem. Because a hundred SMB accounts are not the same as a hundred enterprise accounts. One territory could be worth five million, another worth fifty million, and they both show a hundred accounts. So if the count looks equal but the value doesn't, one rep is set up to fail from day one.

Second — territories need to be designed with growth already baked in. The biggest mistake we see is companies that build for their current team and then six months later they've doubled headcount and they're scrambling to redo everything mid-year. So design with pre-planned cuts from the start — so when a new hire comes on, the existing rep already knows what they're losing and the new rep knows exactly what they're walking into.

Third — California and New York will break a simple geographic model every time. Those two states represent fifteen to twenty percent of most companies' total addressable market. So sub-state cuts at the city or zip code level are almost always necessary for high-density areas.


Part 4: The Problem in Context

And the data backs up why this project is so key for startups who are scaling.

According to the Sales Management Association, 58% of B2B companies say their own territory design isn't working.

The Alexander Group found that poorly designed territories reduce sales capacity by 15 to 25%.

Salesforce's State of Sales Report showed that 84% of reps missed quota in 2024 — and territory imbalance is one of the reasons why.

And Harvard Business Review found that optimizing territory design can increase revenue by 2 to 7% without adding headcount.

And it's not just the sales team that feels this. Sales leadership can't hire confidently because there's no territory to show candidates. Finance can't build accurate capacity models. And the CRO is stuck explaining to the board why half the team is crushing it and the other half can't get traction.


Part 5: How It Gets Built

So how does a territory design project actually get implemented?

At LeanScale, for all of our projects, we follow a four-phase approach — Strategy, Engineering, Enablement, and Handoff.

Strategy

In the territory design project, strategy is by far the heaviest phase.

This is where we work with stakeholders like the CRO, VP of Sales, and RevOps to figure out who the best customers are, what those accounts are actually worth, and how to divide them up so every territory is balanced by both count and value.

Now before the project even kicks off, our team pulls data from the CRM and runs it through a Clay workbook to enrich the account universe with firmographic data. From there we build a V1 of the ICP tier matrix and a draft account valuation model benchmarked against the company's existing customer contracts.

We also lean heavily on AI agents throughout this process — agents trained on our playbooks that know how to pull account data, run enrichment, and assemble a V1 strategic output. And we go deeper into how we use AI in the implementation of this project in the full playbooks in the library.

From there, we iterate with the stakeholders across a series of workshops — ICP, valuation, hierarchy, and then multiple territory balancing reviews. So what that looks like is we present territories balanced by count and value, the VP of Sales socializes it with sales management, feedback comes back, we redraw boundaries, and we repeat that process until every territory is workable.

By the end of the strategy phase we have 4 things locked in: we know who the best-fit accounts are, what they're worth, how the segments are ordered, and what the final balanced territory map looks like — with growth cuts already planned for when the team scales.

Engineering

Phase two is the technical build.

This is where the territory definitions get implemented inside Salesforce as a system that routes accounts automatically.

We build what we call a territory object — a custom Salesforce object that stores every territory definition as a data record. So when a new account enters, a flow evaluates its attributes, queries the territory object for the best match, and assigns it to the right rep.

Now the reason we use this approach instead of hard-coded routing is that when someone leaves or a boundary changes, RevOps just updates the record — no code changes, no developer tickets.

We've also built what we call a Sales Territory Design Agent — basically an AI that has our entire build process codified, knows what fields need to exist, knows how the workflows should be structured, and connects directly to the CRM to start building it out. So what used to be a purely manual engineering effort now gets done significantly faster — the agent handles the repetitive build work, and our engineers focus on quality and edge cases.

Full details of the build are broken down inside the playbook library if you're curious.

Enablement

Phase three is enablement, because the system is useless if the team doesn't know how to use it.

For the territory design project we train sales leadership on territory strategy, growth planning, and how to use the territory map as a hiring pitch for candidates.

We train RevOps and Sales Ops on how to manage the territory object going forward — how to update rep assignments, add new territories, and monitor balance drift.

And we train sales managers and reps on account ownership, dispute handling, and what to expect when the team grows and territories get split.

Handoff

From there phase four is the handoff, and this is where maintenance expectations get set.

Now one thing to understand — territory design is not a one-time project. And here's why that matters.

Every time a new batch of accounts loads into the CRM, every time a rep leaves or a new hire comes on, every time the team scales into a new segment — someone needs to update the territory object and verify the balance hasn't drifted.

And if nobody owns that, what happens is new accounts start routing to overloaded territories, high-value accounts land in the wrong segment, and within a quarter the whole design starts looking as arbitrary as the whiteboard it replaced.

Reps notice immediately. One territory quietly accumulates twice the value of another, and the rep on the losing end starts updating their resume.

So the handoff isn't just about transferring ownership. It's about making sure someone on the team understands the system deeply enough to keep it balanced, and knows exactly when to call for a redesign versus when to make a simple adjustment.


Part 6: What It Unlocks + Close

So let's bring this all together to where we started. Once sales territory design is in place, what actually changes?

Every rep knows their territory was designed to give them a fair shot at quota — balanced by both account count and dollar value, not drawn on a whiteboard.

When the company is ready to hire, leadership can tell candidates exactly what territory they're walking into. And existing reps know what they'll lose ahead of time instead of getting blindsided mid-quarter.

Companies that get this right see 10 to 20% higher rep productivity and 2 to 7% revenue lift without adding headcount.

And the biggest thing that changes after this project is confidence and certainty. That CRO who was staring at the whiteboard can now pull up a territory map where every account is valued, every territory is balanced, and the growth cuts for the next three hires are already planned.

The sales team stops arguing about who got the better deal. The board gets a data-driven capacity model. And the company can scale without mid-year territory chaos blowing up pipeline.

Everything covered in this video about this project — the concepts, the methodology, the full implementation process — all of it is broken down in detail in our Playbooks Library for each project. Our Advisory Overview Playbook covers the problem, approaches, and strategic understanding behind this project. The Methodology Playbook goes deep on every concept we talked about for this project. And the Implementation walks through the step-by-step build process.

And if you're a revenue leader at a fast growing startup who's looking at territory design but also thinking about how those territories get operationalized in the system — we have a whole playbook on Lead Routing that takes the territory definitions and turns them into live assignment logic.

And while you're there, you'll see we have playbooks on every major GTM project — from Attribution and Automated Outbound to Quote to Cash, Commission Design, and beyond. Feel free to check those out.

Again, this is Yasin from LeanScale, and I'll see you in the next one!