OMX Innovation · Deck 22 · Territory Management Web App
A web app that loads targets, manages territories, and optimises them — built for OMX, cheaper than the Salesforce code we walked away from.
Covers every D buyer, gives sales-ops one place to balance, target, and reallocate without re-engineering the CRM.
01 / 06
Why now

The wedge.

02 / 06
What this covers

What's in scope.

01
Why the SF build stalled
$25k in, no clear path to delivery; root cause = SF custom code is expensive per change
02
The fit-for-OMX app
web UI (Lens design language) + Snowflake-native data + thin Postgres for state — same pattern as the rest of the library
03
Target loading
bulk + per-rep + by category/period; pulls from F_AGG_SALES_PERFORMANCE_* and F_CUST_TARGET_* (already in Snowflake)
04
Territory definition
postcode-based, customer-based, or sector-based; visualise on map
05
Territory optimisation
balance reps by account potential / drop density / current workload (links to Deck 12 owner-driver zone data)
06
Reassignment workflow
when a rep leaves, joins, or load needs rebalancing
03 / 06
The problem

What's broken.

01
SF code at $25k and counting
every change is custom code; budget runaway
02
Targets in spreadsheets
bulk loading is manual, error-prone, version-chaos
03
Territory boundaries are tribal
only Sales-Ops knows where the lines are
04
D buyer coverage gaps
not visible who's covered, who isn't, who's overloaded
05
Reassignment is a project
when a rep changes, the rebalance is a weeks-long effort
06
Optimisation never happens
no tool to model "what if we redrew the lines"
04 / 06
The benefits

The value story.

Lever
Mechanism
Sizing
SF code reclaim
Stop SF build; redirect spend to fit-for-OMX
At least the $25k sunk — and the future spend that would have followed
Sales-ops capacity
Console vs spreadsheets
Hours per week per ops manager reclaimed
Rep load balance
Optimisation = fewer over/under loaded reps
Productivity lift; less attrition
Coverage gaps closed
D buyer visibility = no orphan accounts
Direct revenue protect
Reassignment speed
Days → hours when a rep changes
Onboarding + offboarding accelerated
05 / 06
The ask + roadmap

What we need.

Now
Cover
sales-ops manager at console with NZ map + rep list + load bars
P2
Problem vector grid (4)
: SF-code-overrun / Targets-in-sheets / Tribal-boundaries / Coverage-gaps
P3
The walk-away moment
"we stopped at $25k" — anchor the why-now in evidence
P4
Console walkthrough
map view, load bars, account-potential heat, target tracker
P5
Optimisation model
before/after redrawing territories with same rep count
Audience
Primary: Sales Director + Sales Operations Lead + Commercial Director. Secondary: Field reps + AMs (users of the territory boundaries). Tertiary: CFO — the cost reclaim from the walked-away SF build.
References
  • Memory: OMX has F_AGG_SALES_PERFORMANCE_ACCOUNT + F_CUST_TARGET_ACCOUNT_DLY + F_CUST_TARGET_BY_REP_DLY in lens/Current/libraries/dbt/models/presented/ — territory app reads from these
  • Memory: Sales Leader hierarchy = SHIP_TO REP_CODE → reporting hierarchy → AM → Sales Mgr → Sales Leader (project_lens_sector_hierarchy_rules) — territory tool must respect this chain
  • Memory: Sector rollup (Care / T&I / Services / Education) uses BILL_TO sector — not pre-joined fact (project_lens_sector_hierarchy_rules)
  • Memory: AKL local + line-haul channel split (reference_omx_akl_local_vs_linehaul_dispatch) — drop density data lives here
  • Industry: Salesforce custom territory-management build cost — typically $50k-$300k initial + ongoing change cost; matches OMX walked-away pattern
06 / 06
← All decks