Sales Operations

Territory reviews happen once a year and they're always a nightmare. Six months of deal data, three competing definitions of "fair", and a sales ops manager stuck in a meeting where Alice thinks she's been underscore and Bob insists his postcode list is outdated. By the end of the meeting, someone's unhappy, someone feels overlooked, and you've approved a redraw that's defensible on paper but nobody actually believes is fair.

Velocity X's Brain changes this. It reads six months of deal density per postcode, proposes a redraw of territory polygons so each rep's expected revenue lands within ±10% of the team mean, subject to contiguity constraints (no fragmented territories). Sales ops reviews the proposal, runs a one-click approval, and every customer in the system is re-assigned to their new owner automatically. The math is transparent. The decision is defensible. The whole thing takes 20 minutes instead of three heated meetings.

Why Annual Territory Reviews Are Politically Charged and Slow

Territory assignment sounds simple until you actually ship it. The moment you draw a line on a map, someone loses something. If a rep's postcode list shrinks by 10%, they see 10% less pipeline. If a postcode shifts from one rep to another, it's a zero-sum redistribution — one rep's win is another's loss.

Most teams avoid territory rebalancing entirely. They assign postcodes once at hire-time and never touch them again. After five years of hiring and churn, you end up with Alice owning three hot postcodes that close at 35% win rate and Bob stuck with five cold suburbs that close at 8%. Nobody's tracking it. The annual plan just assumes Alice will close 4× more deals than Bob because "she's better".

When teams DO run a territory review, the process is negotiation-heavy. Sales leadership proposes a redraw based on gut feel. Reps push back because "the deal density data doesn't reflect my relationship-building" or "the last three months have been abnormal due to seasonality". After weeks of back-and-forth, you get a compromise that spreads risk and upsets everyone equally.

The real cost isn't the meeting time. It's the six-month gap where the unbalanced territories are feeding quota misses, burning out top performers, and demoralizing reps in cold zones. A rep in a weak territory knows the deck is stacked. They can't hit quota no matter how hard they work. Top talent leaves. You backfill with junior reps who are even less equipped to work cold territory.

Brain's angle: if you can mathematise fairness, you can defend it. No more feelings. No more "but my customer relationships". Just the numbers.

The Architecture — How Brain Reads Deal Density and Redraws Territory Polygons

Step one: aggregate deal data by postcode over the trailing 180 days. For each postcode, sum closed revenue + count of won deals. Divide by the postcode's area in square kilometres. Now you have expected revenue density (dollars per square km) for each postcode.

Step two: read the current territory assignments. Each rep owns a set of postcodes (stored as a polygon in Postgres using PostGIS geometry types). The system calculates each rep's current expected revenue: sum of (deal density × postcode area) for every postcode in their territory.

Step three: solve the rebalancing problem. Goal: redraw territory polygons so each rep's expected revenue is as close as possible to the team mean, subject to contiguity (each rep's territory must be a single connected region, no scattered postcodes). This is a constraint satisfaction problem — computationally hard, but solvable at typical team scales (under 50 reps) with integer linear programming.

The solver takes 30–120 seconds depending on team size and the number of postcodes. It outputs a JSON file with new polygon definitions for each rep. Brain flags any scenarios where rebalancing would require moving customers between reps — this is the human approval step.

Step four: sales ops reviews the proposal. The UI shows side-by-side comparisons: old territory vs new territory, old expected revenue vs new expected revenue, before/after fairness ratio (highest earner's expected revenue ÷ lowest earner's expected revenue). If it looks good, one click applies the redraw. The system runs a point-in-polygon query (ST_CONTAINS in Postgres) against every customer record, updating ownership based on their location's new territory assignment.

The whole flow takes 20 minutes from "let's rebalance" to "territories are live".

The Math of Fairness — ±10% Variance Bounds

Brain targets ±10% variance around the team mean expected revenue. For a 10-person team with $10M total expected revenue, the team mean is $1M per person. The rebalancing solver targets each rep's territory to yield between $900k and $1.1M in expected revenue.

Why ±10% and not perfect equality? Because perfect equality is impossible given real postcode geography and contiguity constraints. Some postcodes will always be hotter than others. Some territories will have awkward shapes. The solver accepts that tradeoff and gets as close as the math allows. In practice, most rebalances land in the ±5% range.

The fairness metric is transparent. Sales ops can see which reps benefited from the rebalance and which took a slight hit. If a rep's expected revenue drops, it's because their territory was genuinely over-represented in deal density and the rebalance corrected it. If a rep's expected revenue stays flat, they didn't move. If it increases, they've been given cold postcodes that have growth potential.

Occasionally a rep will push back: "My expected revenue went down by $50k, but I've got relationships in three postcodes that just moved to Alice." Brain handles this with a secondary rule: reps can flag specific postcode relationships to preserve across the rebalance. The solver re-runs with the constraint "rep X keeps these three postcodes" and rebalances the rest of the team around it. It's not a free lunch — other reps shift — but it's fairer than hard-coding historical relationships into the initial territory assignment.

What Rebalancing Actually Looks Like In Practice

Let's walk through a real scenario. Velocity X customer, 12-person sales team, AUD 18M ARR pipeline. Six months ago, they hired two new reps (bringing the team from 10 to 12). At hire-time, they gave the new reps "overflow" territory — left-over postcodes that didn't fit cleanly into the existing 10-person split. Result: the new reps inherited cold postcodes and are struggling to hit quota. Meanwhile, the original 10 reps are busier than ever.

Brain runs a rebalance. It reads six months of deal data. The original reps' postcodes show high deal density. The new reps' postcodes show low deal density. The solver redistributes: each rep loses one or two postcodes, the new reps gain one or two of the hot postcodes, and expected revenue converges.

The proposal shows: new rep A's expected revenue goes from $1.2M to $1.5M (hot postcode incoming). New rep B's expected revenue goes from $900k to $1.1M (medium postcode incoming). Original rep C's expected revenue drops from $1.7M to $1.45M (losing one hot postcode to new rep A). The fairness ratio before rebalance was 1.89× (highest to lowest). After rebalance, it's 1.23× — still not perfect, but dramatically fairer.

Sales ops clicks approve. Within 90 seconds, the system updates every customer record. The next day, the new reps are working hotter territory and have a fair shot at quota. Nobody's unhappy about it because the fairness metric is transparent and defensible.

The Contiguity Constraint — Why Fragmented Territories Don't Work

Contiguity is a hard requirement, not a nice-to-have. Without it, the solver could produce "optimal" rebalances where a rep's territory is scattered across 20 non-adjacent postcodes. That's useless in practice — a rep can't build a route across fragmented territory. They'd waste two hours a day driving between zones.

Contiguity is defined as: each rep's territory must be a single connected polygon (topologically connected — you can walk from any postcode to any other postcode in your territory without leaving your territory). Postgres PostGIS validates this with ST_IsValid and ST_Covers. The solver enforces contiguity by only proposing polygon redraws that preserve connected regions.

This constraint tightens the fairness bounds slightly. Some hypothetically fair rebalances become impossible if they'd fragment a territory. The solver accepts the tradeoff: contiguity always wins. A slightly less fair but contiguous territory is better than a slightly fairer but fragmented one.

One-Click Approval — From Proposal to Live Territory

The approval UI shows a map with two layers: current territories (semi-transparent) and proposed territories (overlay). Sales ops can toggle between them to see the diffs. A table below shows before/after expected revenue for each rep, sorted by absolute change. Green cells for increases, orange for decreases, grey for no change.

If the proposal looks good, sales ops clicks "Apply Rebalance". The system does three things: (1) updates the territory polygon definitions in Postgres, (2) re-runs the ST_CONTAINS query for every customer against the new geometries, updating ownership, (3) sends a Slack notification to each rep saying "Your territory has been updated. Here's your new postcode list and a map." Reps have one working day to read the notification and push back if something is egregiously wrong.

Edge case handling: if a customer has no owner after rebalance (e.g. their location doesn't fall into any polygon due to a data error), they're flagged in the system. Sales ops assigns them manually. This is rare — maybe 0.1% of customers in a typical rebalance.

Frequently Asked Questions

How often should we rebalance?

Once a year is the sweet spot. More frequently and you risk churn (reps keep losing territory). Less frequently and drift accumulates (fairness deteriorates). Annual reviews mean new deal density data feeds into the next year's rebalance, and the system stays fresh without disrupting reps mid-year.

What if a rep just closed a mega-deal that skews their territory's deal density?

Brain's aggregation window is 180 days (6 months). A single mega-deal is noise in that window. If a postcode's deal density is genuinely driven by one customer, the rep can flag it as a relationship-preservation exception and the solver re-runs with that postcode pinned.

Does rebalancing affect existing customer relationships?

Ownership changes only based on customer location. If a customer's postcode moves to a new territory, their "owner" in Velocity X changes. But the CRM record (HubSpot, Pipedrive, Attio) stays with the original person unless you manually re-assign. You can configure Velocity X to auto-sync ownership changes back to the CRM, but that's a separate decision point. Most teams prefer to review ownership changes manually before syncing.

What if my team has customer segments (enterprise vs SMB) that should be territory-blind?

Brain supports multi-dimensional territories. You can run separate rebalances for different customer segments. Enterprise deals might be owned by a specialist team that's territory-blind; SMB deals are geo-based. Each segment gets its own territory definition and rebalancing schedule.

How does rebalancing work with reps who have secondary territories?

Primary territory gets 100% of the expected revenue credit. Secondary territories are weighted at 50% (configurable). The rebalancing solver sees each rep's total weighted expected revenue (primary + 0.5 × secondaries) and optimises to fairness around that. Secondaries stay more fluid and are easier to rebalance without disrupting primary assignments.

Can I seed a rebalance with constraints (e.g. "rep X must keep postcode Y")?

Yes. Before running the solver, sales ops can flag specific postcode relationships as "locked". The solver treats them as immovable and rebalances the rest of the team around them. Useful for preserving key customer relationships without sacrificing fairness elsewhere.

The Verdict

Territory rebalancing is the one operational task that unites most sales teams in dread. It's political, it's slow, and it's never defensible enough to avoid resentment. Brain doesn't eliminate the politics — humans always feel something when they lose territory — but it removes the debate. You can't argue with the math. Expected revenue per square km is objective. Contiguity is verifiable. Fairness variance is transparent.

The result is rebalances that happen on schedule, take 20 minutes, and land you territories where every rep has a fair shot at quota. No more top performers burning out because they're sandbagged by cold postcodes. No more junior reps demoralised by unwinnable territories. Just the fairness that math delivers.

If you've spent the last three years avoiding a territory review because the politics felt too heavy, Brain is the tool that makes you rethink it. One number, one algorithm, one click. Fairness on demand.