Custom CRM With Territory and Quota Management: Feasibility, Cost and Risk

What this looks like once real reps touch it

Territory and quota management sounds like two extra columns: an owner on the account, a number on the user. That model survives right up until the last day of a quarter.

Here is the scene that ends it. A rep closes a $340,000 deal on March 31. Two people claim it. The geographic rep owns the postal code the buyer's headquarters sits in. The named-account rep owns the parent company globally, and this buyer is a subsidiary. Both claims are correct under rules the company actually wrote down. The CRM has one owner_id, and it holds whichever value the assignment job wrote last. Finance runs commissions on April 8. One rep gets paid. The other escalates, and someone asks the obvious question: who owned this account on March 31? The database cannot answer. owner_id was overwritten on April 1 when the new fiscal year territories went live. No history, so no evidence, so no dispute process.

Four decisions have to land before anyone writes a schema: how overlapping dimensions resolve deterministically, how ownership is recorded over time, whether quota is allowed to not balance, and what happens to credit under churn and currency moves. A two-week quote has made none of them.

Territory assignment is a rules engine, not a foreign key

Real territory definitions combine dimensions: geography, named accounts, industry code (NAICS or SIC), revenue band, product line, channel, segment. Geography alone is not one field. In the US you are matching against roughly 41,000 active ZIP codes, and USPS ZIP codes are not polygons, they are sets of delivery routes. If someone proposes a spatial join on ZIP boundaries, they are thinking of Census ZCTAs, which approximate ZIPs and are not the same set. Canada gives you the FSA, the first three characters of the postal code. The UK's authoritative postcode file, Royal Mail PAF, is licensed, not free. Multi-country builds need ISO 3166-2 subdivision codes as a fallback layer.

Then the rules overlap. A competent build makes that explicit instead of pretending it will not happen:

• Rules carry an explicit priority, and ties break on a deterministic field, never on job execution order.
• Overlays are a separate assignment type. A product specialist covering the same account as the geo rep is a second, non-exclusive assignment. Forcing that through one owner column is what produces the March 31 scene.
• Account hierarchy resolves before rules run. A subsidiary matching a geo rule while its ultimate parent is a named account is the most common assignment bug we see.
• Every assignment stores the rule that produced it. When a rep asks why they lost an account, you show them a rule id, not a shrug.

Salesforce built Enterprise Territory Management because this is hard, and its shape is worth copying even in a custom build: territory models have states (Planning, Active, Archived), only one model is active at a time, and you run rules against a planning model before it goes live.

Effective dating decides the data model

Assignment is bi-temporal. Valid time answers "who owned this on March 31". Transaction time answers "what did the system believe on April 8 when we paid commissions". You need both, because realignments get applied retroactively and comp gets restated.

Concretely: no owner_id on the account. Instead an assignment table holding account, territory, assignment type, valid_from, valid_to, rule id, and a created_at that never moves. Current owner becomes a view. That costs about a day of extra design at the start. Retrofitting it after 18 months of production data, once you finally need history you never wrote, has run 4 to 7 weeks on projects we inherited, and everything before the retrofit is simply gone.

Realignment is then a job, not an UPDATE. Moving 200,000 accounts has to be batched, resumable and idempotent under retry, and it needs a dry run that emits a diff before anything is written. Sales ops will run that dry run eleven times. The hardest question in the job is not technical: do open opportunities follow the account to the new owner, or stay with the closing rep until the quarter ends? Both answers are defensible. Pick one, put it in the comp plan, encode it. Teams that skip the decision find it mid-quarter, when pipeline disappears from a forecast.

Quota does not roll up the way engineers assume

The instinct is a tree where children sum to the parent. Every sales org we have built for runs an over-assignment factor, typically 5% to 15%: rep quotas deliberately exceed the regional number so the region still lands when some reps miss. Enforce summing in your schema and sales ops cannot enter their actual plan, so they go back to the spreadsheet you were hired to replace.

What has to be modeled:

• Quota is a time series per period, not an annual number. Periods come from your fiscal calendar, which may be 4-4-5 and may not start in January.
• Spreading curves. An annual number split across quarters is rarely 25/25/25/25. Seasonality differs by segment and gets hand-edited.
• Proration. A rep starting on day 40 of a quarter, or taking six weeks of leave, needs a prorated number with an explicit rule. This is the field that gets escalated to HR (Human Resources) when it is wrong.
• Dimensions. Quota by product line, by new business versus renewal, by region. Attainment then computes per dimension, not just in total.
• Versioning. Quotas change mid-year. The old number must survive for prior-period comp.

Credit, currency and clawback

Attainment is credit divided by quota, and credit is where the money is. Decisions to force early:

• Amount type: bookings, ACV, ARR, TCV or recognized revenue. On a multi-year deal these differ by large factors, and finance and sales usually mean different ones.
• Split credit versus multi-credit. Overlays normally get 100% credit while the geo rep also gets 100%, so total credit exceeds total bookings on purpose. If your reports assume credit sums to revenue, they look broken to a CFO. Model credit as its own ledger.
• Currency. Quotas are set locally, attainment rolls up in corporate currency. Do not call a live FX API. Almost every comp plan fixes a budget rate for the fiscal year so a rep is not punished by a currency move they cannot control. That means a dated rate table with a rate type.
• Clawback. A deal closes, credit pays, the customer refunds in month two. You need negative credit events and period restatement. An immutable credit ledger handles it. A computed attainment column does not.

Visibility is derived, and recalculating it is a batch job

Territories drive who sees what. A regional manager sees their whole subtree, and the territory hierarchy is not the reporting hierarchy: both exist. Walking a deep tree with a live recursive query on every list view falls over somewhere around a few thousand users and a few hundred thousand records.

What works is materializing it: a closure table, or Postgres ltree on the territory path, feeding a grants table rebuilt when the hierarchy changes. Postgres row-level security is a fine enforcement point, but the policy reads materialized grants rather than walking the tree. Then accept the consequence. A hierarchy change triggers a recalculation that takes minutes to hours at scale. Salesforce has the same job and the same problem, which should tell you it is not a skill issue. Budget for a recalculation queue, a progress indicator, and a rule that hierarchy edits are frozen during quarter close.

What this costs and how long it takes

These are Digital Heroes delivery bands across 2,000+ projects, not industry averages.

• Territory and quota management inside an existing product that already has accounts, users and permissions: $15,000 to $60,000.
• As part of a first release, where the object model is being designed at the same time: $50,000 to $130,000, in 10 to 16 weeks.
• Full platform with planning, realignment tooling, forecast rollup and comp integration: $150,000 to $350,000 over 6 to 12 months.

What pushes this specific capability toward the top of its band, in order of impact:

• Retroactivity. "We need to know who owned it last March" is the largest multiplier. Bi-temporal plus restatement is roughly 1.5x to 2x current-state-only.
• Assignment dimensions. Geography alone is a week. Geography plus named accounts plus industry plus product overlays plus segment is a rules engine with a UI, and a month or more.
• Countries. One country is a lookup table. Five means postal data sourcing, UK licensing, and a subdivision fallback. Add 2 to 3 weeks.
• Data quality. If accounts are not deduplicated and have no parent hierarchy, assignment returns wrong answers no matter how good the engine is. On inherited CRMs this cleanup has been 20% to 30% of the project.
• User count. Under 200 users, visibility is a query. Over 2,000 with a deep hierarchy, it is a materialization and recalculation subsystem.
• Comp integration. Feeding Xactly, CaptivateIQ, Spiff or Varicent means agreeing a credit contract with finance. The engineering is small. The agreement is not.

When you should not build this

If you are a sales org rather than a software company, and you are already on Salesforce, do not build this. Enterprise Territory Management is included with Sales Cloud Enterprise and above (list price $165 per user per month for Enterprise, $330 for Unlimited at the time of writing). You get territory models with planning states, assignment rules, hierarchy-derived sharing and forecast rollup, tested on orgs far larger than yours. If you need visual balancing, Salesforce Maps Territory Planning is a paid add-on and still cheaper than a custom build. Pair it with a dedicated commission tool instead of modeling comp yourself. The test: under roughly 30 reps, one country, geography-only split, a custom build is a worse product at a higher price.

Build custom when the CRM is your product (vertical SaaS whose own customers need territories), when assignment must run against proprietary data that cannot leave your system, when territory logic derives from product usage or supply constraints rather than a map, or when you already carry the accounts and users and bolting on Salesforce creates a second source of truth plus a sync problem worse than the build. "Salesforce is expensive" is not on that list: at 30 reps, Enterprise list is about $59,400 a year, while the custom build's first year starts at $50,000 and you own it forever.

How to brief and vet a developer

Bring three artifacts to the first call: your current territory spreadsheet, your comp plan document, and your fiscal calendar. Anyone who quotes before reading the comp plan is quoting a different project.

Then ask these. The answers separate people who have shipped this from people who have read about it.

• "How do you store who owned an account on a given date?" You want an effective-dated assignment table, unprompted, with valid_from and valid_to. "owner_id plus updated_at" or "we would add an audit log" means they have never been in a commission dispute.
• "An account matches three rules. What happens?" You want explicit priority, a deterministic tie-break, and overlays as a separate non-exclusive type. "We would prevent that in the UI" is a fail. Overlaps are the design, not a bug.
• "Walk me through realigning 200,000 accounts." You want batched, resumable, idempotent, with a dry-run diff. Then listen for whether they ask you about open opportunities without being prompted. That question is the tell.
• "Do rep quotas have to sum to the regional quota?" Anyone who says yes has never sat with a sales ops leader.
• "What exchange rate does attainment use?" Correct answer: a fixed budget rate per fiscal year from a dated rate table. "We would call an FX API" means reps get paid differently based on the day.
• "A deal closes, credit pays, the customer refunds in 60 days. Then what?" You want negative credit entries and period restatement, not an UPDATE.
• "How does a VP see their subtree at 3,000 users?" You want materialized grants, closure table or ltree, and an admission that recalculation is a job with a runtime.
• Ask for the DDL. One table definition for territory assignment tells you more than an hour of conversation.