A territory rule replaces manual round-robin and spreadsheet lookups with a condition the CRM evaluates every time. The point is not just speed. It is a record of why each account went to each rep, in a system reps and leadership both read from.
A territory rule is a piece of automated logic inside a CRM that assigns a record to a specific user the moment it is created or updated, based on criteria like ZIP or state, ARR band, industry code, account tier, or named-account list membership. Rules run in a defined order, match-first-wins, with a fallback pool for records that match nothing. Every match is written to an audit log, which is what makes a rule-driven system defensible when comp disputes come up.
What a territory rule is, what it reads, how it fires, and why it beats a manual round-robin.
A territory rule is a condition the CRM evaluates on a record (lead, account, or deal) to decide which user owns it. If the condition matches, the rule sets the owner and stops. The rule runs on create and on any update to a field it reads, so coverage stays correct as records change.
Five fields do most of the work. Geography (ZIP, state, country), segment by ARR or employee band, industry by SIC or NAICS code, account tier (strategic, enterprise, mid, SMB), and named-account list membership. Compound rules combine two or more of these on a single row.
Rules are ordered. The engine walks the list from top to bottom and stops at the first match. The first rule to match sets the owner, which means rule order is a design decision, not a cosmetic one. Named-account rules sit above geo rules so a strategic logo always wins over a ZIP match.
Every rule set ends in a fallback: a round-robin pool, a shared queue, or a specific user who triages leftovers. The fallback stops records from sitting unowned when a lead comes in from a ZIP nobody carved or an industry nobody has yet. No record is orphaned.
Each time a rule fires, the CRM writes a row: the record, the matched rule, the resulting owner, the timestamp, and the field values that drove the match. The log is what makes rules defensible in comp disputes, territory audits, and reassignment reviews.
Manual assignment is a human picking an owner from a dropdown. Territory rules move that choice into logic the system enforces for every record, every time, without someone remembering to do it. Reps leave. Teams reorg. The rules stay the carve.
A rule is only as good as the fields it can evaluate. The useful criteria are the ones that reflect how the business actually carves the market, which means standard firmographics plus any custom fields RevOps maintains on the account. The six patterns below cover almost every rule set in production.
The oldest and most common criterion. A rule reads the billing or shipping address and routes by ZIP range, state, country, or region. Works for field sales, outside sales, and anywhere physical proximity matters. ZIP tables can be imported in bulk and refreshed when carves change.
A rule reads a revenue or headcount field and routes to the matching segment pod. Enterprise above 1,000 employees, mid-market 100 to 1,000, SMB below 100. The band thresholds live as rule conditions, so moving the line is one edit and not a data-migration project.
Vertical teams need industry routing. A rule reads a SIC or NAICS code (or a Strkr industry taxonomy field) and routes to the matching vertical pod. SaaS to the SaaS pod, manufacturing to the manufacturing pod, healthcare to the healthcare pod, regardless of the account's size or geo.
Tier is a labelled attribute that sales leadership controls directly, independent of revenue or headcount. A rule reads the tier field and routes to the matching coverage model. Tier is what lets a small logo count as strategic because of brand value or network effect.
A named-account rule reads list membership as a boolean. If the account appears on a given list (enterprise target 100, EMEA strategic, platform logos), the rule assigns the designated owner. Lists are managed as a saved view, so adding a logo to the list routes ownership automatically.
Real territory models are hybrids. A compound rule combines criteria on a single row: industry equals SaaS and ARR band equals mid-market, routed to the SaaS mid-market pod. The engine still evaluates match-first-wins, which keeps the model deterministic even when the carve is layered.
A rule set is a sequence, not a bag. The engine evaluates rules in a specific order on every create and every relevant update, picks the first match, writes the assignment, and logs the result. Understanding the sequence is how RevOps keeps the system predictable when the carve gets layered.
A new lead lands from a form fill, a new account is added from an import, or an existing record changes industry or ARR. The trigger is the data event. Every rule set defines which events fire the engine, so updates that do not touch a rule field never run the sequence.
The engine reads rule 1, evaluates its condition against the record, moves to rule 2 if it does not match, and so on. There is no scoring or ranking across the full list. The first condition that returns true is the winner, which is why order is a design decision.
When a rule matches, the engine stops. The matched rule writes the owner, applies any associated team or queue, and triggers downstream actions (notification, SLA clock, task creation). No other rule in the set gets a vote on the same record for the same event.
If the engine walks the entire list without a match, the fallback fires. The fallback is a round-robin queue, a shared team inbox, or a specific triage user. The record is never left unowned, so reps and managers never have to scan a view for orphaned leads.
The engine writes a log row: the record ID, the matched rule (or fallback), the resulting owner, the timestamp, and the field values that drove the match. The log is append-only and queryable, which is what makes the system defensible in comp and territory audits.
Assignment is the start, not the end. Once the owner is set, the engine runs any attached actions: notify the owner, start the first-touch SLA, create a task, add the record to the owner's priority view, or push to an outbound sequence. One rule, many downstream effects.
Teams that run on manual assignment feel the limits as the pipeline grows. The next six cards cover what a rule-driven system fixes, in the order the pain usually shows up: speed, consistency, scale, defensibility, visibility, and continuity.
A manual queue has a backlog. A rule fires on create. The owner is set before the record is visible in a report, which means first-touch SLAs start on the clock the market actually set and not when a RevOps assistant got around to triaging the queue.
A human triager is tired on Friday, generous to the rep they like, and unaware of yesterday's rule change. The engine applies the same condition the same way on every record. Policy, not personality, decides who gets what.
A rule set scales horizontally. One hundred rules evaluated against one million records runs in bulk without a human in the loop. Manual triage caps at whatever one person can process in a day, which is why fast-growing teams run out of hours before they run out of territory.
When two reps argue about a deal, the audit log says which rule matched, when, and why. The dispute moves from opinion to data in one query. The same log answers territory audits, acquisition handoffs, and the question of who gets credit on a long-cycle enterprise deal.
Dashboards built on the audit log show accounts per rule, orphaned records, over-matched pods, and segments with no coverage. Leadership stops asking "who owns EMEA mid-market?" and starts reading the answer on the same screen as the forecast.
Reps leave. Managers rotate. The rules stay. A new RevOps lead can read the rule set and understand how the carve works in an afternoon. A manually assigned carve lives in the head of whoever has been triaging for the last two years, and leaves with them.
Strkr evaluates territory rules on every create and update, writes the matched rule and resulting owner to an audit log, and runs the routing engine inside the chosen pod. Match-first-wins, named-account rules on top, fallback at the bottom, every assignment defensible on day one.
Manual assignment is a user picking the owner from a dropdown on a record. A territory rule is a condition the CRM evaluates automatically on every create and on every relevant update, with the first matching rule setting the owner and the result written to an audit log. The rule runs the same way for every record, every time, without someone remembering to do it.
Rules are evaluated in order from top to bottom. The engine stops at the first rule whose condition matches the record and uses that rule to set the owner. No other rule in the set gets a vote on the same record for the same event. This is why rule order is a design decision: named-account rules usually sit above geo rules so a strategic logo wins over a ZIP match.
The common five are geography (ZIP, state, country, region), segment (ARR band or employee band), industry (SIC, NAICS, or a custom taxonomy), account tier (strategic, enterprise, mid, SMB), and named-account list membership. Compound rules combine two or more of these on a single row, which is how hybrid territory models are expressed as logic the engine can evaluate deterministically.
Every rule set ends in a fallback. The fallback is usually a round-robin queue inside a shared team, a specific triage user, or a general inbox. The record is never left unowned. The fallback also surfaces gaps in the carve: if the fallback queue fills up with a specific industry or geography, that is the signal to add a rule rather than keep triaging by hand.
Yes. Every time a rule fires, the CRM writes an audit log row with the record ID, the matched rule (or fallback), the resulting owner, the timestamp, and the field values that drove the match. The log is append-only and queryable, which is what makes rule-driven assignment defensible in comp disputes, territory audits, and reassignment reviews.
Yes. A single rule row can specify compound conditions such as industry equals SaaS and ARR band equals mid-market, routed to the SaaS mid-market pod. The engine still evaluates match-first-wins, which keeps the model deterministic even when the carve is layered. Most mature territory models are expressed as a small set of compound rules rather than a long list of simple ones.
They work together. A territory rule picks the pod that owns a record. Lead routing picks the specific rep inside that pod, usually by round-robin, capacity, or workload. In Strkr the two run in sequence on create: the territory rule assigns the pod, the routing engine picks the individual owner within the pod, and both results are written to the audit log.
The rule set should be reviewed on the same cadence as the carve itself, which for most teams is annually with a mid-year checkpoint. Between formal reviews, the fallback queue is the signal: if the fallback starts collecting records that match a visible pattern, that is a prompt to add a rule rather than wait for the next re-carve. The audit log makes those patterns easy to see.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
