How to build a quota and territory planner

What matters here

• A territory planner is four parts: the account universe, territory rules, a quota model tied to territories, and a comparison view.
• Define territories as rules, not lists. A rule reassigns new accounts automatically; a hand-picked list is stale the week you publish it.
• Attach quota to the territory, not the rep. When a rep leaves, the territory keeps its number and the gap is visible instead of vanishing.
• Measure fairness with more than account count. Total addressable value, existing revenue base and travel or timezone load all matter.
• Keep every version of the plan. The value of a planner is comparing two plans, not producing one.
• Territory and quota data is sensitive across a sales org, so scoped access is a design requirement rather than a nicety.

Who this is for

You run revenue operations or sales strategy. You already know your segments and your capacity model. What you want is to test three versions of a plan in an afternoon and show the leadership team what each does to coverage.

How it works in practice

What a planner actually does with it, in order. Each step depends on the one above it.

1. 1

   Load the account list

   Upload a CSV of every account you could sell to, with the attributes you segment on. The app reports which columns it did not recognise instead of quietly dropping them.

2. 2

   Write territories as rules

   Each territory is a set of conditions over those attributes rather than a hand-picked list, so new and changed accounts assign themselves. A short exceptions list handles the handful that have to be placed by hand.

3. 3

   Fix the plan bugs before anyone sees them

   The app lists accounts matched by two territories and accounts matched by none. Both are invisible in a spreadsheet and both surface in month three as a rep complaint.

4. 4

   Set the quota inputs, read the coverage

   Enter base, retention, expansion and new business per territory. Quota is derived from those, and the coverage multiple flags any territory whose addressable base cannot support its number.

5. 5

   Check the plan is even

   Compare territories on account count, potential value, existing base and travel load at once. The goal is not identical territories, it is knowing where the plan is uneven before a rep tells you.

6. 6

   Compare versions, then publish

   Put the proposed plan next to the live one, see which accounts moved and what it does to each rep's number, then export the approved version for the CRM.

1. 1

   The account list and the territories

   Get the universe in, and slice it in a way that survives new accounts.

   Copy

   In this Helix project, build me a territory planner.
   
   Start with the part I argue about most: which accounts sit in which
   territory.
   
   I will upload a CSV of every account we could sell to. It has the
   attributes we actually segment on: industry, employee band, revenue band,
   country, region, whether they are already a customer, what they spend
   today, and an estimate of what they could be worth. Read the headers and
   tell me which ones you did not recognise rather than dropping them
   quietly.
   
   Then let me define a territory as a rule over those attributes, not as a
   list of account names. "EMEA, enterprise band, not already a customer"
   should be a territory I can write once and have new accounts fall into on
   their own. I also need a small exceptions list for the accounts that have
   to be placed by hand, and every exception has to carry a reason.
   
   Show me, per territory: how many accounts, what they are worth today, and
   what they could be worth.
   
   Two lists matter more than anything else on this screen. Accounts matched
   by two territories, and accounts matched by none. Put both where I cannot
   miss them.
   
   I sign in through Helix, so do not build a login page. Read the signed-in
   user from the runtime. If you need to reach Salesforce later, tell me and
   I will create the connection in my workspace rather than putting a key in
   the code.

   Worth knowing. The two mismatch lists are the highest-value thing here. In a spreadsheet plan they surface in month three, as a rep complaint, and by then the plan is live.

2. 2

   Quota that belongs to the territory

   Derive the number instead of negotiating it, and keep it when a rep leaves.

   Copy

   Now add quota.
   
   For each territory I want to enter four things: the existing annual base,
   what we expect to retain, what we expect to expand, and what we expect to
   win new. Derive the quota from those and show every input separately, so
   when someone argues with the number they have to argue with a specific
   assumption rather than the total.
   
   Add a coverage multiple: the territory's total potential value divided by
   its quota. Flag anything below a threshold I set. That is a territory
   being asked for a number its account base cannot support, and it is a
   planning error rather than a performance one.
   
   Keep reps separate from territories. A rep is assigned to a territory
   with a start date and a ramp, and the quota belongs to the territory. When
   somebody leaves I want the gap to stay visible on the plan instead of
   disappearing with them.
   
   Roll the quota up by segment, by region and for the whole plan, and let me
   compare the total against the number I have been given.

3. 3

   Is this plan even?

   Answer the question every rep asks the day the plan is announced.

   Copy

   Add a view that answers "is my territory fair".
   
   Rank every territory side by side on account count, total potential,
   existing base, quota, coverage multiple, and quota as a multiple of the
   base. For each of those show how spread out the territories are, so I can
   see at a glance which dimension is the unbalanced one.
   
   Include timezone spread and country count too. Account counts hide travel
   and coverage load, and that is the part reps actually feel.
   
   Highlight the three best and three worst territories on each dimension.
   
   I am not trying to make every territory identical. I am trying to know
   exactly where the plan is uneven before a rep tells me in a QBR.

4. 4

   Compare two plans

   The reason to build this rather than open a spreadsheet.

   Copy

   Make plans versioned.
   
   Every plan is a named version with a status: draft, proposed, approved,
   live. Let me clone a version so I can experiment without touching the
   live plan.
   
   Then give me a comparison of any two versions: which territories were
   added or removed, which accounts moved and where they went, and how each
   territory's quota changed.
   
   The screen I care about most is per rep: what they lose, what they gain,
   and what it does to their number. That is the conversation the plan has to
   survive, and I would rather have it with the data in front of me.
   
   Let me export an approved version as a CSV for the CRM load, and record
   which version was exported and when.

   Worth knowing. The per-rep impact view is what makes a territory change explainable. Without it, every reassignment reads as a punishment.

5. 5

   Connect it to real systems

   The step that turns a working prototype into something with your data in it.

   Copy

   Now connect it to the systems we actually run, so it works on real data
   rather than the rows you seeded.
   
   Anything in angle brackets is a placeholder. Swap it for whatever we use
   instead, and have the app name the connection it wants rather than assume
   a vendor, so changing my mind later is a config change and not a rewrite.
   
   <Salesforce>. Read the account universe with the attributes you segment
   on, then export an approved plan back.
   
   <NetSuite>. Read current spend per account, which is what quota is
   actually built from.
   
   <Workday>. Read who is in seat, their start date and ramp, so assignment
   reflects reality.
   
   <a CSV export>. Import the account list to start, before any of the above
   is connected.
   
   <Snowflake>. Read historical performance by account and segment, which is
   what a coverage multiple is checked against.
   
   <Looker>. Feed coverage and balance into the planning dashboard leadership
   already reviews, so the plan is argued from one view.
   
   <Okta>. Resolve reps and managers, so assignment reflects the actual team.
   
   Only write where I have said to write. Everything else is read only.
   
   Do not write a key, a token or a connection string anywhere in the code,
   and do not ask me to paste one. Tell me which connections you need and I
   will create each as an authentication in my Helix workspace. Reference
   them by alias.

   Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.

6. 6

   Ship it

   The last step of every build: a URL, and the right people on it.

   Copy

   Deploy my app.

   Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Before you send it round, open the project in the Helix console and set Access Control, so planning stays with the people running it until the plan is published.

What it connects to

Planning happens outside the CRM and then has to land in it. Both halves need a connection.

• Salesforce

  Read the account universe with the attributes you segment on, then export an approved plan back.

• NetSuite

  Read current spend per account, which is what quota is actually built from.

• Workday

  Read who is in seat, their start date and ramp, so assignment reflects reality.

• A CSV export

  Import the account list to start, before any of the above is connected.

• Snowflake

  Read historical performance by account and segment, which is what a coverage multiple is checked against.

• Looker

  Feed coverage and balance into the planning dashboard leadership already reviews, so the plan is argued from one view.

• Okta

  Resolve reps and managers, so assignment reflects the actual team.

Each line says whether the app reads, writes or both. Anything not described as writing should be read only.

Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.

Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.

Related guides