Order Management System — Compass 2.0

The OMS that Compass 2.0 was replacing had been in production for ten years. A decade of well-intentioned patches, market-by-market exceptions, and screens layered on top of screens. The primary users — dealers and distributors who placed orders every working day — had stopped expecting it to get faster. They scheduled their order entry the way you'd schedule an outage.

What the dealers had been telling us — for years

• —Finding the right product was slow. The catalog had grown faster than the search, and the search hadn't aged well. Dealers kept their own spreadsheets of part numbers because the system couldn't get them there reliably.
• —Product status was opaque at the moment of decision. Stock level, delivery timeline, and legal-compliance state for the destination market lived on three different screens — and an order could be partly placed before any of them surfaced.
• —Sourcing the required quantity from multiple fulfillment centers was manual work. The OMS didn't allocate across warehouses; dealers had to split orders themselves, often guessing at lead times.
• —Editing a placed order was punishment. Most changes required cancelling and re-entering — losing pricing, losing approvals, losing the order's history.

“Every minute a dealer spent fighting the OMS was a minute they weren't selling. After ten years, those minutes were the program's strongest business case.”

Behind the user pain was a structural one. A global manufacturer running eight markets. Eight fulfillment stacks. Eight definitions of what an order even *was* — some treated RMAs as a new order, some as state on the original; some acknowledged backorders as their own entity, others quietly didn't. The mandate from leadership was one Order Management System — Compass 2.0, built on Salesforce — to replace them all.

The risk was familiar: build twenty OMSes wearing one logo. Each market had developed local conventions over years — tax handling, customs declarations, dealer and distributor contracts, regulator-driven return windows — and most of those conventions reflected real constraints that couldn't be sanded off without consequence.

Who was in the room

The 20+ stakeholders weren't a single audience. They were five distinct groups, each with a different definition of "good":

• —Dealers & distributors — the channel partners who actually placed orders. They wanted predictable lead times and zero surprises.
• —Sales teams — internal account owners across markets, each with regional sales motions, incentive structures, and a long-standing relationship with the legacy stack they were about to lose.
• —Business stakeholders — program sponsors, finance, operations leadership. They wanted ROI, visibility, and a single source of truth.
• —Business analysts — the translators between markets and the platform team, owning workflow specifications and the truth of how things actually worked.
• —Salesforce developers — the engineering team building Compass 2.0. They wanted clean edges, clear extension points, and a model that didn't ask them to special-case every market in code.

“Compass 2.0 had to be designed so each of these groups could see itself in the system — without the system pretending to be five different things.”

I started where the disagreements were sharpest — in the words people used. Every market had its own glossary, and most of the "we work differently" claims dissolved the moment we put them on a single shared diagram.

The audit method

Five representative orders per market — a happy path, a partial fulfillment, a customer cancellation, an RMA with credit memo, and a credit-hold review — walked end-to-end with the local team. Every screen they touched, every decision they made, every downstream system they handed off to.

What the audit revealed

• —About 80% of "local needs" were vocabulary differences. The same workflow, three names.
• —About 20% were real divergence — usually around tax, customer rights, or fulfillment-partner contracts. These were genuinely non-negotiable.
• —Three markets had workflows nobody else had ever heard of — legitimate, regulator-driven, and worth preserving exactly.
• —Six markets shared workflows that were marked as "unique" in the kickoff but turned out to be identical once the local jargon was peeled off.

“Stakeholders stopped arguing about the system and started arguing about the words. That, it turned out, was the productive disagreement.”

A shared glossary published in week six made the system *legible* to everyone in it. Every term carried a market-specific footnote where local language differed. The glossary was boring; the glossary was load-bearing.

Running design sessions with 20+ stakeholders without it becoming theater required structure. Decisions had to be made; not all of them by consensus.

The pattern

1. 01Pre-work — each market submitted their five most painful flows and their three non-negotiables, ranked. No filtering, no pre-aggregation. Whatever each market brought, the room saw.
2. 02Side-by-side — flows posted on a single wall, market-by-market. Differences were visible, but similarities were more visible — and they outnumbered the differences roughly four-to-one.
3. 03Decision log — every "we'll do X" recorded with rationale and the dissenting voice attached. Nobody was overruled silently. Six months later, when someone asked why a decision was made, the answer was on file.

“Decision logs were more valuable than personas. Personas described users we already understood; the logs described the system we were still arguing about.”

The OMS resolved into four layers, each with a clear contract.

1. 01Order core — identity, state machine, history, and rights. Shared across every market without exception. This was the part that earned its consistency by being modeled, not assumed.
2. 02Country extensions — tax computation, RMA-window logic, customs handling, dealer-network integrations. Pluggable per market, but expressed through a shared interface so the core never branched.
3. 03UI shell — single navigation, single auth, single global search. Behavior consistent across markets so an operator moving between regions never had to relearn the system.
4. 04UI slots — designed surfaces inside the shell where market-specific data and actions appeared. A US order showed ship-to-state use-tax breakdown; a German order showed intra-community VAT routing; a Japanese order showed consignee acceptance windows. Same shell, different inserts.

Most OMS rebuilds fail not because the technology is hard but because the system becomes a battleground for whose-market-is-most-important. By giving every market a designed home for its quirks — and writing those slots into the architecture rather than treating them as exceptions — the political surface narrowed sharply.

The dealer's surface

Underneath the architecture, the system existed to serve a single user goal: a dealer placing an order in a fraction of the time the old OMS demanded. The four chronic complaints became the four explicit design contracts for the order-entry surface.

1. 01Findability — a faceted catalog driven by the dealer's own history. Recently-ordered, frequently-ordered, and saved-list shortcuts on the first screen. Type-ahead that searched part number, description, and dealer-private aliases simultaneously. The spreadsheet the dealer used to keep beside the old system became a feature in the new one.
2. 02Status at the moment of decision — stock level, fulfillment-center availability, expected delivery window, and destination-market compliance state shown inline on the product row. No more partial orders entered before discovering a hold. Compliance flags surfaced before the line item was added, not after submission.
3. 03Multi-center sourcing — the system allocated the requested quantity across available fulfillment centers, surfaced the resulting split as a recommendation, and let the dealer accept, override per line, or rebalance manually. The split happened in the background; the user saw a single order with transparent reasoning behind it.
4. 04Order editing as a first-class action — every line, quantity, ship-to, and payment term remained editable up to a clearly-marked commit point in the order lifecycle. Edits preserved pricing, approvals, and history. The phrase "cancel and re-enter" stopped appearing in support tickets.

“The architecture earned its complexity by removing the complexity dealers had been carrying for ten years.”

The numbers mattered. What mattered more is what they don't capture: two years after launch, the same twenty people were still in the room — but they were asking each other for opinions instead of fighting the system. The OMS itself had stopped being the topic of conversation.

The work of an enterprise systems designer is mostly translation. The interface is downstream of the alignment — and when the alignment is real, the interface is the easiest part.

The chapters above describe the program. This one describes my role inside it — research through delivery, with the throughline of keeping the practitioner close to both the dealer and the developer.

1. 01Conducted user research — contextual studies, live walk-throughs of the existing OMS with dealers and distributors in their working environment, structured interviews, and supplementary surveys across markets. The goal wasn't to confirm what we already suspected; it was to find out where our assumptions broke.
2. 02Triaged surfaced issues using the 80/20 rule. The 20% of problems responsible for 80% of dealer friction became the focus list. Everything else was acknowledged, parked, and revisited later — never silently dropped.
3. 03Confirmed findings with the business and Salesforce engineering teams, then produced a single consolidated problem statement. Every downstream design and implementation decision could be traced back to it — and was.
4. 04Produced wireframes early — not as solutions, but as conversation artifacts. They turned abstract debate into concrete pixels every stakeholder could point at, agree with, or push back on. The wireframe was the alignment tool; the design came later.
5. 05Built interactive prototypes for the most contested flows — multi-center sourcing and the order-edit lifecycle. Ran usability sessions with dealers to validate the design before engineering committed to it. Three significant flow revisions came out of those sessions.
6. 06Stayed embedded with the Salesforce engineering team through implementation — answering specification questions, reviewing front-end work, and helping resolve the edge cases that only appear when code meets real data. The design didn't end at handoff; it ended at production.

“Six tasks, one thread — keep the practitioner close to both the dealer and the developer, from the first interview to the last bug fix.”