How to Introduce Territory Planning and PODs
At some point, a growing GTM team stops being a group of individuals and needs to become a coordinated system. Territory design and POD structures are how you build that system. Here's how to do it from scratch.
Territory planning and PODs.
Most early-stage GTM teams start the same way: a small group of people, loosely coordinated, going after whatever opportunities surface. Everyone knows what everyone else is working on. Coverage gaps get filled by whoever has capacity. It works because the team is small enough that one person can hold the whole picture in their head.
That model has a ceiling. As the team grows, the informal coordination that held everything together quietly starts to break down. Accounts get double-touched or missed entirely. Reps compete for the same logos. No one has clear ownership, which means no one has clear accountability. The revenue motion that worked at five people becomes friction at ten.
Territory planning and POD structures are the answer to that problem. Not as administrative overhead, as the architecture that makes a larger team coherent.
The question isn't whether to introduce this structure. It's whether you build it before the cracks appear or in response to them.
(01) Territory Design: The Mechanics
A territory is a defined slice of the addressable market assigned to a specific rep or team. The goal is simple: clear ownership of every account that matters, with enough opportunity in each territory to make the quota realistic, and enough balance across territories to make the team fair.
In practice, territory design involves four dimensions. Getting all four right simultaneously is the work.
- 01
Segmentation axis: The first decision is what your territories are carved along. Geography is the most intuitive: DACH, Nordics, UK&I. But it's not always the most logical for B2B SaaS. Vertical segmentation (fintech, logistics, healthcare) often produces better results when the product has different use cases or buying motions across industries. Firmographic segmentation by company size is another option. The right axis is the one that most closely maps to how your buyers actually behave, not what's easiest to draw on a map.
- 02
Account coverage and TAM distribution: Once you've defined the segmentation axis, you need to know how many accounts live in each territory and what their collective revenue potential looks like. This requires a clean account list, ideally enriched with firmographic data, and a realistic view of which accounts are actually workable. A territory with 3,000 accounts and no prioritisation is not a territory. It's a list. The design work is deciding which accounts each rep should actually be spending time on, in which order, and why.
- 03
Balance and equity: Territory equity matters more than most leaders give it credit for. Reps are acutely sensitive to whether their patch is fair relative to their peers'. A territory that is structurally harder, with thinner TAM, lower average deal size and more competitive accounts, will produce lower results regardless of rep quality, and the rep will know it. The design needs to account for this. Some imbalance is inevitable; the goal is to make it visible and to compensate for it explicitly, either in quota or in additional support.
- 04
Named accounts vs. open territory: Not every account in a territory needs to be named upfront. A common approach is a hybrid: a set of named target accounts that the rep owns regardless of who sources the opportunity, plus an open territory of smaller or less-defined accounts that any motion can touch. Named accounts provide focus and prevent the "who owns this?" conversation from derailing a deal. Open territory preserves flexibility where the TAM is still being mapped.
(02) POD Structures: Options and When Each Fits
A POD is a small, self-contained unit within the revenue org: a set of roles grouped together to cover a defined territory or segment end-to-end. The logic is that account coverage improves when the people responsible for it are coordinated at the team level, not just the individual level.
There is no single correct POD model. The right structure depends on where the company is in its motion, how complex the sale is, and what the customer lifecycle looks like after the initial close.
A POD is only as functional as the clarity of ownership within it. Grouping people together without defining who is responsible for what produces the appearance of coordination without the substance of it.
AE + BDR pairing (Account Executive · Business Development Rep):
The simplest and most common configuration. One AE owns the territory and the pipeline; one BDR handles outbound prospecting and meeting generation into that territory. Accountability is clean: the BDR is measured on meetings booked, the AE on pipeline and closed revenue. Works well when the primary challenge is top-of-funnel coverage: getting enough qualified conversations started in a defined set of accounts. Best suited to companies with a clear outbound motion, a reasonably short sales cycle, and enough territory density to keep the BDR fully occupied. The risk is that the BDR becomes entirely reactive to the AE's priorities rather than operating with independent territory judgment.
AE + BDR + CSM (Account Executive · Business Development Rep · Customer Success Manager):
Extends the pairing model by adding a CSM who owns the post-sale relationship within the same territory. The POD covers the full customer lifecycle from prospecting through expansion. This model makes sense when net revenue retention is as important as new logo acquisition, when expansion ARR from existing customers is a meaningful part of the revenue plan. It also creates a natural feedback loop: the CSM's insight into what customers actually use and value informs the AE's pitch and the BDR's targeting. The coordination overhead is higher, and the model requires clear handoff protocols between AE and CSM at close. Without those, the customer experience fractures exactly at the moment it should be strongest.
Specialist POD (AE · BDR · Solutions Engineer · CSM):
Adds a technical or solutions resource to the pod, typically a Solutions Engineer or Pre-Sales Consultant, for products with significant technical complexity or longer enterprise evaluations. The SE handles product demonstrations, technical discovery, and proof-of-concept engagements that the AE cannot carry alone. This configuration is rarely appropriate before Series B, and only when deal complexity genuinely requires it. Introduced too early, it creates resource costs the deal volume cannot justify. Introduced at the right moment, it meaningfully improves win rates in enterprise accounts where technical credibility is part of what's being evaluated.
(03) Making the Structure Operational
Territory design and POD structure exist on paper before they exist in practice. The gap between the two is where most implementations lose their effect.
Three operating mechanisms close that gap:
| Mechanism | Purpose | Cadence |
|---|---|---|
| Territory review | Assess coverage, surface gaps, rebalance accounts where necessary. Not a pipeline call, a strategic conversation about whether the territory design is still serving the motion. | Quarterly |
| POD sync | Align the pod on priority accounts, active deals, expansion opportunities, and handoff status. Short, structured, focused on coordination rather than status updates. | Weekly |
| Account planning | For named or strategic accounts: a documented view of the buying committee, the engagement history, the open opportunities, and the next actions. Owned by the AE, reviewed with the pod. | Monthly or per deal stage |
The design is the starting point. The operating rhythm is what keeps it functional as the team grows and the market shifts. Territories that are never reviewed drift out of balance. PODs that never sync develop the same coordination failures the structure was supposed to prevent.
Territory planning and PODs are not complexity for its own sake. They're the mechanism that lets a growing team stay coherent, that replaces the informal coordination of a small group with a structure that scales.
The design work is not a one-time event. It's a system that needs to be revisited as the team grows, the TAM evolves, and the motion matures. Build it deliberately, review it regularly, and adjust it without sentiment when the data says something isn't working.
Structure should follow the motion. When it does, the team can grow without losing the clarity that made it effective when it was small.