How to build a territory and quota sync

What matters here

• Protect deals past a stage. A relationship mid-negotiation is worth more than a tidy territory map.
• Apply on the effective date. A plan entered in December for January should not move anything in December.
• Model coverage before sign-off. An uncovered segment discovered in February is a quarter lost.
• Keep the history. Commission is calculated against the plan as it was, not as it is.
• Report accounts with no owner after every change. That list should be empty and rarely is.

Who this is for

You run revenue operations or sales operations. The plan changes annually, it is applied by hand or by a script somebody wrote once, and the first month afterwards is spent fixing ownership.

How it works in practice

The sequence, from a plan being agreed to the field working to it.

1. 1

   The plan is modelled before it is approved

   Coverage, balance and quota against historical performance, so gaps are visible while they can still change.

2. 2

   Accounts are assigned by rule, not by list

   Segment, geography and industry from data, so the plan survives an account changing shape.

3. 3

   Application waits for the effective date

   Entered whenever, applied on the first, so nothing moves early.

4. 4

   In-flight deals keep their owner

   Past a stage, the deal and the relationship stay put regardless of the new map.

5. 5

   Everybody is told what changed and why

   Reps, managers and customer success, before the date rather than on it.

6. 6

   The old plan is retained

   Because commission for the previous period is calculated against it.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Begin by modelling coverage before anything changes

   A gap found in February is a quarter lost.

   Headless skills build-workflow tray-patterns

   Copy

   Use build-workflow. The systems in play are Salesforce and Snowflake,
   or whatever we run in those seats.
   
   Before applying any plan, model it: for each proposed territory, the
   account count, total addressable spend, current pipeline, historical
   closed revenue, and the quota proposed against it.
   
   Then show me coverage multiple per territory, and flag any that is far
   above or below the others, plus any segment with no owner at all.
   
   An uncovered segment discovered in February has cost a quarter. The same
   gap seen in a model in November is a five minute conversation.

2. 2

   Define territories as rules, not lists

   So an account changing shape does not require a manual move.

   Headless skills build-workflow

   Copy

   Use build-workflow. Express each territory as a rule over account
   attributes: country, region, employee band, industry, and named account
   list where one genuinely applies.
   
   Rules evaluate in a fixed order and stop at first match, exactly as lead
   routing does, so an account can never belong to two territories.
   
   Named accounts are the exception, not the mechanism. A plan made
   entirely of named lists needs manual maintenance every time a company
   grows, and nobody does that maintenance.
   
   Show me every account that matches no rule. That list is the plan gap and
   it is never empty on the first run.

3. 3

   Apply on the effective date, and protect what is in flight

   A relationship mid-negotiation is worth more than a tidy map.

   Copy

   Apply the plan on its effective date, not when it was entered. A
   plan agreed in December for January changes nothing in December.
   
   Then protect in-flight work. Any opportunity past a stage I set, or with
   activity in the last fortnight, keeps its current owner through the
   change, with an end date on that protection.
   
   Reassigning a deal in negotiation because the territory map changed is
   how a deal is lost. The new owner has no history, the customer has to
   start again, and the outgoing rep has no reason to help.
   
   Show me the protected list before applying, so somebody can decide on
   the exceptions instead of discovering them.

   Protection needs an end date. Without one, an opportunity that stalls keeps its old owner indefinitely and the map is quietly wrong forever.

4. 4

   Tell everybody before the date

   Because the first they hear should not be a missing account.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then communicate before the effective date, not on it:
   
     Each rep: which accounts they gain, which they lose, and which they
     keep because a deal is in flight
     Each manager: their team's coverage and quota
     Customer success: which of their accounts changed owner, so the next
     customer conversation is not confused
   
   Handle these: an account in an active support escalation, which should
   flag rather than move silently; a customer whose champion has a personal
   relationship with the outgoing rep, which is a judgement rather than a
   rule; and a mid-year change, which needs prorating for quota and
   commission.

5. 5

   Keep the history, and check for orphans

   Commission is calculated against the plan as it was.

   Copy

   Store ownership as history with valid-from and valid-to, not as a current
   field. Commission and attainment for a past period are calculated against
   the plan that was in force then, and a current owner field cannot answer
   that.
   
   After every change, report:
   
     Accounts with no owner, which should be zero
     Accounts owned by somebody who has left
     Opportunities whose owner no longer owns the account
     Territories with no rep assigned
     Coverage multiple per territory after the change
   
   Run those the day after application, not a month later. Every one of them
   is a gap somebody is not working.

6. 6

   Test it, then hand the rules to RevOps

   Because territories change more than annually in practice.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run the whole plan in preview first and have sales
   leadership read the movement list.
   
   Then open the same workflow in Tray Build so revenue operations can amend
   territory rules, protection thresholds and effective dates in the visual
   canvas.

What it connects to

The plan is a model, the CRM is where it lands, and everybody affected needs telling.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides