Designing product, pricing, stock and transaction visibility without turning CRM into ERP
A fictional, composite case: sellers need products, prices, stock, orders and invoices in front of them. The work was to decide how much of the ERP the CRM should actually hold.
Independently created. Contains no employer or client implementation detail, internal names or figures.
The case in brief
Current reality
Sellers need operational context from the ERPs—products, prices, stock, open orders, invoices—and the default answer has been “sync everything into the CRM”.
What must become true
Sellers see enough product, price, availability and transaction context to make commercial decisions—at the freshness each decision actually needs—while product, price, stock, order and invoice truth stays in the systems built to execute them.
Design question
Which ERP information should the CRM own, replicate, summarize, derive—or simply reference?
01The reality · current state
What the platform looks like today.
A fictional B2B manufacturer sells a large catalogue through several subsidiaries, each with its own ERP, warehouses and price conditions. Sellers prepare quotes, visit customers and follow up orders in the CRM, but the answers they need—what can be sold, at what price, whether it is available, what the customer has open or owes—live in the ERPs. Every request for visibility so far has been answered by copying another table into the CRM.
- The CRM holds a full copy of the item master, most of which no seller ever quotes
- Prices copied overnight are wrong by the afternoon, so sellers phone the back office to confirm them
- Stock appears as one number, although availability depends on warehouse and selling company
- Order lines and invoices are replicated in full—the ERP’s volume without the ERP’s controls
- Users edit copied fields, and the next load silently overwrites them
- Nobody can say which copy a report used, or how old it was
02The boundary problem
What is mixed today.
“Seeing” and “owning” were treated as the same request. Every time a seller needed to see something, the CRM ended up holding it.
- Seeing vs owningA price shown on a quote became a price maintained in the CRM.
- Commercial product vs ERP itemOne commercial product maps to several items, plants and variants; the copy assumed one-to-one.
- Current state vs historySellers needed to know what is open now; the copy brought years of lines.
- Fact vs signalA declining customer is a signal derived from transactions—not a reason to load every invoice.
03Key dimension · Visibility without authority
Where each domain lives—and what the CRM does with it
Every row answers the same questions: which system can change it, what the seller actually needs, how it reaches the CRM, how fresh it must be—and which decision it changes.
| Domain | Authoritative system | What the CRM needs | Interaction mode | Required freshness | Why the seller needs it |
|---|---|---|---|---|---|
| Product | ERP item master; the commercial structure is kept for selling | Sellable commercial products and their structure—not every item, plant and variant | Replicated subsetA filtered subset of what can be quoted | Daily; changes are rare and planned | What can I offer this customer? |
| Pricing | ERP price conditions per selling company and channel | The price for this customer, item and quantity when quoting—and the price used, recorded on the quote | Read on demandRead at quote time | At the moment of quoting | Which price do I commit to? |
| Stock & availability | ERP per warehouse and selling company | Availability for the customer’s delivery location—not a global total | Read on demandQueried when asked, never stored | Current, at the moment of asking | Can I promise a date? |
| Orders | ERP | Open orders and their status per account | Replicated subsetA read-only summary, updated by status events | Within the hour of a change | What does the customer have open—and what is late? |
| Invoices | ERP—the financial truth | An overdue indicator and a link to the document | ReferencedReferenced and opened in the source | Indicator daily; document on demand | Is there a payment issue before I visit? |
| Commercial signals | Data platform, derived from ERP history | Trend, gap and risk per account and period | Derived signalA published signal with its definition version | Per period | Where should I spend my time? |
Visibility is not authority. Do not move a transaction into the CRM when a governed commercial signal is enough.
05Interaction design
What crosses a boundary, when—and why.
Each read and each event is designed around the decision it serves—and around what the seller sees when the answer does not come.
| Business event | Identity | State | Who stays authoritative | Timing |
|---|---|---|---|---|
| A seller prices a quote lineCrosses: CRM → integration → ERP (read) | Commercial product → ERP item, ERP customer number, selling company | Price for this customer, item and quantity | The ERP stays authoritative; the quote keeps the price used and a timestamp | Synchronous read with a short timeout |
| A seller asks whether it can shipCrosses: CRM → integration → ERP (read) | ERP item and the customer’s delivery location | Availability and the earliest date | Read-only; nothing is stored in the CRM | On demand |
| An order changes statusCrosses: ERP → integration → CRM | Order number and ERP customer number | Status summary (confirmed, delayed, shipped, invoiced) | The CRM displays it and cannot edit it | An event on each change |
| A period closesCrosses: ERP → data platform → CRM | Commercial account and period | Signals: trend, gap to target, risk | The data platform derives them with a definition version | Published per period |
06Failure & recovery
Rejected, late, uncertain or unavailable.
Visibility that fails silently is worse than no visibility: the seller must always know what they are looking at.
| Situation | Designed response | Who repairs it | How it is detected |
|---|---|---|---|
| The price read times out | The line keeps its last price, labelled with its date, and the quote cannot be issued until it is confirmed | Seller, with pricing support | Timeout at quote time |
| Availability cannot be read | The seller sees “availability unknown”, never a stale number | Integration support | Failed or slow read |
| A status event is lost | A periodic reconciliation compares open orders and restores the summary; the ERP wins | CRM platform owner | Reconciliation run |
| A commercial product has no valid item for a company | It is not offered for that company; the mapping gap goes to product management | Product management | Mapping check on publication |
07Candidate architectures
Credible options, judged against these premises.
Replicate everything into the CRM
A small catalogue and one ERP
Cost: Stale copies, volume, duplicated truth, users editing copiesShow nothing; send sellers to the ERP
Back-office-led sales
Cost: Sellers lose context; parallel spreadsheets appearPlacement per domain: a small replicated subset, on-demand facts, read-only summaries, derived signals
Several ERPs, a large catalogue, field sales
Cost: Needs read contracts, explicit “unknown” states and an owner for placementDesign decision
Decide placement domain by domain, from purpose, authority, grain, freshness and volume: replicate only a small, stable commercial subset; read volatile facts on demand at the moment of decision; show transactions as read-only summaries that link to the source; and replace transaction history with governed signals.
08Resulting architecture
Every platform, one job—and a boundary.
What each platform owns in this design, and what it deliberately does not. These are the responsibilities for this context, not universal rules.
CRMIntegration layerERPsData platform
CRM
Where commercial decisions are taken- The quote and the price it committed to
- The commercial product structure sellers offer
- Presenting summaries, statuses and signals
- Price conditions
- Stock and availability
- Order, delivery and invoice truth
Integration layer
Reads and events across the boundary- On-demand read contracts (price, availability)
- Status events for orders
- Caching rules and timeouts for reads
- The values it returns
- What the seller decides
ERPs
Transactional truth per selling company- Item master and plant data
- Price conditions per channel and customer
- Stock per warehouse
- Orders, deliveries and invoices
- The commercial product view
- Commercial signals
Data platform
History turned into signals- Transaction history at a conformed grain
- Signals per account and period, with a definition version
- Operational values sellers act on at quote time
09Governance & operations
Who owns the boundary over time.
Placement is a decision that has to survive the next request to “just add a field”.
| What | Owner | Cadence | Evidence |
|---|---|---|---|
| The placement matrix | CRM platform owner, with the ERP owners | With every visibility request | Requests to replicate a new domain or field |
| Product–item mapping | Product management | On each catalogue publication | Commercial products without a valid item per company |
| Signal definitions | Data platform owner | Versioned per change | Signals consumed in the CRM and their definition version |
10The second layer
Questions that change the architecture.
Purpose
- Which commercial decision changes because this is visible?
- Does the seller need history—or only the current state or a signal?
- Who acts on it, and when?
Authority & grain
- Which system can change it?
- What does one record mean—and does one commercial product map to one item or many?
- Does the value depend on warehouse, company or channel?
Freshness & cost
- How current must it really be at the moment of decision?
- What does copying it cost in volume, coupling and drift?
- What does the seller see when the source does not answer?
11Decisions & outputs
What the work produces.
- 01Information placement matrix
- 02Freshness requirement per decision
- 03Product–item mapping rules
- 04Read contracts for price and availability
- 05Commercial signal definitions
- 06Replication review