How do you architect revenue operations for a medical device distributor in 2027?

What a distributor's revenue operations actually have to do

Most RevOps playbooks assume a software company: one product line, self-serve pricing, a CRM opportunity that closes and stays closed. A medical device distributor breaks nearly every one of those assumptions, and the architecture has to reflect that or it collapses inside a quarter.

Start with the revenue event itself. In SaaS, revenue is recognized on a contract with a start date. For a distributor, revenue is recognized when product ships or when a case is consumed out of consignment — and those two things happen in very different systems. A rep may "win" a hospital account, but revenue only materializes as a rolling stream of purchase orders and case usage over the following months and years. That means the classic pipeline-to-revenue model — opportunity value × win rate = forecast — is structurally wrong here. What you actually forecast is *account run-rate*, plus new-account ramp, plus contract-driven step changes.

Second, pricing is not yours alone to set. Between the distributor and the hospital sit group purchasing organizations, integrated delivery networks, regional purchasing coalitions, and in many cases a manufacturer's own tiered rebate program. The price on a given line item is a function of which contract the shipping account is eligible for, what tier that contract sits in, and whether volume commitments have been met. If you let reps type prices into quotes, you will pay for it twice: once in margin leakage and again in chargeback disputes with your manufacturers.

Third, inventory is part of the revenue system, not a separate concern. Consignment sets sitting in a hospital's sterile core, loaner kits circulating between cases, trunk stock in a rep's vehicle — all of it represents capital deployed against future revenue. A distributor's most important operational ratio is often not CAC payback but inventory turns by account, because a poorly-turning consignment set is a direct drag on the same working capital that funds growth.

Fourth, regulatory identity is load-bearing. Unique Device Identification requirements mean each device carries a device identifier plus production identifiers — lot, serial, expiration. That data isn't compliance overhead you bolt on at the end; it's the join key that lets you connect a shipment to a case to an invoice to a recall notice. Distributors that treated UDI as a labeling problem rather than a data-architecture problem end up unable to answer basic questions like "which accounts hold expiring stock of this lot."

So the architecture question isn't "which CRM." It's: what is the smallest set of systems and contracts-of-record that can answer, reliably, *what did we sell, to whom, under which agreement, at what true margin, and what capital is tied up supporting it.* Everything else is decoration.

The adjacent version of this problem shows up in dental, veterinary, and lab-supply distribution, and in surgical-instrument reprocessing services. The mechanics differ in detail — dental has fewer GPO layers, vet has almost none, lab supply has heavier reagent-and-instrument-placement dynamics — but the shape is identical: contract-governed pricing, field-consumed inventory, and revenue that arrives as a stream rather than an event. If you have built RevOps for one, most of the pattern transfers.

Building the data spine before you buy anything

The single most common sequencing error is buying tooling first. A distributor's RevOps stack is only as good as its master data, and master data work is unglamorous, slow, and completely non-optional.

Product master. Every SKU needs a stable internal item number, a manufacturer catalog number, a GTIN where one exists, and a UDI-DI reference. You also need a product hierarchy that reflects how you actually sell — category, sub-category, franchise, therapy area — not just how the manufacturer organizes their catalog. Reps sell "trauma" and "sports medicine"; the manufacturer's file may organize by plate geometry. Build a mapping layer and own it. Expect this to surface real problems: duplicate items created for the same physical device under two manufacturer numbers, kits whose components were never decomposed, discontinued items still active in the ERP.

Customer master and the hierarchy above it. This is where distributors bleed the most analytical value. A single hospital is typically three or four entities at once: a ship-to location, a bill-to entity, a member of an IDN, and a member of one or more GPOs. Your customer master must model all four, because different questions need different levels. Margin analysis needs ship-to. Contract eligibility needs GPO membership. Executive account planning needs the IDN roll-up. Build the hierarchy as a proper parent-child structure with effective dating — hospital systems acquire each other constantly, and a hierarchy without effective dates makes historical comparison impossible.

Contract master. Every active agreement — GPO contract, local agreement, IDN-level pricing, manufacturer rebate program — needs a record with: contract number, sponsor, effective and expiration dates, eligible ship-tos, item-level pricing or tier structure, volume commitments, and rebate mechanics. This is the object that most distributors keep in spreadsheets and then wonder why quoting is slow and chargebacks fail.

Rep and territory master. Territories should be defined against ship-to accounts, not against zip codes, because hospital systems don't respect geography. Include effective dating here too, so that when you re-align territories mid-year you can still answer "what did this territory do last year on a like-for-like basis."

Sequence the work: product master first (it is the most self-contained), customer hierarchy second, contract master third, territory last. A realistic timeline for a distributor with 8,000–20,000 active SKUs and a few thousand accounts is three to six months of focused effort with a dedicated data owner. Trying to do it in six weeks around everyone's day job is the reliable way to end up with a half-migrated mess that nobody trusts.

One practical test for whether the spine is done: pick ten invoices at random and try to trace each line to a contract, a territory, a product hierarchy node, and a margin number without opening a spreadsheet. If you can't do ten out of ten, keep working on the spine.

The step-by-step build sequence

The build follows a deliberate order because each layer depends on the one beneath it. Skipping ahead to dashboards before the contract engine exists produces reports everyone argues about.

Phase 0 — baseline audit. Before touching architecture, produce a static snapshot: revenue by ship-to, by product hierarchy node, by rep, by contract, for the trailing 24 months, with gross margin at line level. Do it in whatever tool you have. The point is to establish ground truth you can compare against later, and to surface the ugly surprises early — the accounts with negative margin after rebates, the contracts everyone forgot expired, the SKUs with no contract coverage at all.

Phase 1–2 — masters. Covered above. The exit criterion for Phase 2 is that a quote line can look up its correct price with no human judgment involved.

Phase 3 — quoting enforcement. The rule is simple and absolute: reps select a customer and items; the system derives price. Reps may request an exception; they may not type a number into a price field. Route exceptions through an approval matrix with thresholds — say, up to 3 points of margin erosion approved by a regional manager, 3–7 points by a VP, beyond that by finance. Log every exception with a reason code, because the exception log becomes your best pricing-strategy input within two quarters.

Phase 4 — order-to-cash join. Every invoice line should carry the contract it priced against, the territory it credits, and the product hierarchy it rolls into. If your ERP won't store those natively, stamp them in a data warehouse layer at load time. This is what makes true margin — after freight, after rebate, after chargeback — computable rather than estimated.

Phase 5 — inventory and consignment. Instrument every consignment location as a stocking location in the system, not a note in someone's CRM. Track set composition, expiry dates, and last-usage date. The two metrics that matter most: turns by account and percentage of consigned value with under six months of shelf life remaining.

Phase 6 — field workflow. Reps need mobile capability that works in a hospital basement with no signal: offline case capture, barcode or UDI scanning for usage, and simple visit logging. Do not build a rep app that requires eleven fields to log a case; you will get zero adoption and lose the usage data that everything downstream depends on.

Phase 7 — forecasting. Model each account as a run-rate with a trend, then layer in new-account ramp curves and known contract step changes (a new IDN win, a tier threshold about to be crossed, a competitor's contract expiring). This is much closer to a subscription-revenue model than a classic sales pipeline, and it forecasts far more accurately for distribution.

Phase 8 — compensation. Once margin is trustworthy, move compensation off gross revenue. Details below.

Costs, timelines, and realistic ranges

Budget honestly, because half-funded RevOps builds are worse than none — you get the disruption without the payoff.

Time. For a distributor in the $20M–$150M range, a full build from a spreadsheet-and-ERP starting point takes 12 to 24 months to reach steady state. The phase breakdown that tends to hold: masters 3–6 months, contract engine and CPQ 3–5 months, order-to-cash and analytics 2–4 months, inventory instrumentation 3–6 months (this one runs long because it requires physical counting), field workflow 2–3 months, forecasting and comp 2–3 months. Phases overlap, so calendar time is less than the sum, but the sequencing dependencies are real.

People. The minimum viable team is one RevOps lead with real distribution experience, one data/analytics engineer, and one contract-and-pricing analyst. Below $50M in revenue you can often combine the last two, but you cannot skip the pricing analyst function — someone has to own contract loading and chargeback reconciliation as a full job, not a side task. Above roughly $100M, add a dedicated systems administrator and a second analyst.

Tooling. Rather than name vendors and prices that change, budget by category and shape. CRM seats for a field team are typically the smallest line. CPQ with contract-pricing capability is usually the largest software line and often the one people under-scope, because generic CPQ built for software subscriptions handles tier eligibility poorly and needs configuration work. A cloud warehouse plus BI is modest at distribution data volumes — you are dealing with millions of invoice lines, not billions of events. Inventory and consignment tracking may come from your ERP, from a specialist field-inventory product, or from a build; the make-or-buy line usually falls around whether you have more than about 200 consignment locations. Integration and middleware is a real line item, not an afterthought; EDI to manufacturers and to large IDN customers is a persistent cost.

Where the money actually goes. In most builds, software licensing is 25–40% of total program cost and internal labor plus implementation services is the rest. Teams routinely invert this in planning, budgeting mostly for licenses and then discovering the data work is the expensive part.

Payback signals. The fastest returns come from three places. Contract-price enforcement typically recovers meaningful margin within two quarters simply by eliminating below-contract quoting and mis-tiered pricing. Chargeback accuracy improves collection of manufacturer credits that were previously written off. Consignment right-sizing frees working capital that was sitting as slow-moving sets. None of these require the full build to be complete — which is a strong argument for the phase order above, since each early phase pays for the next.

The cost of doing nothing is mostly invisible, which is why it persists: margin leaked one exception at a time, expired product written off quietly, chargebacks abandoned because reconciling them costs more than they're worth, and a forecast that is really a negotiation.

Where teams get it wrong

Treating it as a CRM project. The single most expensive mistake. A CRM implementation delivers activity tracking and a pipeline view; neither addresses contract pricing, inventory turns, or true margin. Distributors who lead with CRM typically get 18 months in, discover the fundamental questions still aren't answerable, and have to do the master-data work anyway — now with a large sunk cost and organizational fatigue.

Forecasting with a SaaS pipeline model. Opportunity stages and probability weighting fit poorly. A hospital "close" is really an approval to be on the shelf; the revenue comes later and unevenly. Distributors using stage-weighted pipelines routinely see forecast error well beyond what run-rate modeling would produce, and worse, reps learn to game stages because that's what's measured.

Letting price be typed. Every organization believes their reps are honest, and they usually are. The problem isn't dishonesty; it's that a rep facing a purchasing manager at 4pm on the last day of a quarter, without instant access to the correct contract tier, will make a reasonable guess. Reasonable guesses cost margin points at scale and cause chargeback rejections downstream.

Ignoring the chargeback loop. When you sell at a contract price below your acquisition cost, you claim the difference back from the manufacturer. If your submitted data doesn't match their contract records exactly — customer identifier, contract number, item number, eligible date range — the claim is rejected. Distributors that don't staff reconciliation lose real money continuously and usually can't quantify how much.

Compensating on gross revenue. Pay on gross and you will get gross: reps discount to win volume, push whatever moves easiest, and have no reason to care about a consignment set that hasn't turned in eight months. Once margin is trustworthy, shift the plan — commonly a blended structure with the majority of variable comp on gross margin dollars, a portion on new-account acquisition, and a meaningful modifier on inventory efficiency in the rep's territory. Announce it a full quarter ahead and run parallel calculations so reps can see both numbers before the switch.

Building the rep app for headquarters. Field tools designed by people who have never stood in a sterile core fail. If logging a case takes more than about 60 seconds and doesn't work offline, it won't happen, and your usage data will be permanently incomplete.

No data-quality SLA. Masters decay. Contracts expire, hospitals merge, SKUs get discontinued, territories shift. Without a named owner and a standing cadence — weekly contract expirations review, monthly hierarchy reconciliation, quarterly territory audit — the spine you spent six months building degrades to untrustworthy within a year.

Over-indexing on one manufacturer's portal. Many distributors let a large manufacturer's systems become their de facto operating layer. It's convenient until you add a second or third line and discover none of your history is portable. Keep your own system of record.

Decision framework: when to choose what

There is no single right architecture; there is a right architecture for your size, line count, and consignment intensity. This is the decision tree that fits most distributors.

Under roughly $20M. Don't over-build. A well-maintained contract spreadsheet with strict version control, a lightweight CRM for activity, and disciplined monthly margin review will outperform a poorly-implemented enterprise stack. Spend on the pricing analyst, not the software. The one thing worth doing properly even at this size is the customer hierarchy, because retrofitting it later is painful.

$20M–$100M, consignment-heavy (orthopedics, cardiac rhythm, surgical implants). Inventory instrumentation first. Your working capital is the constraint, and every month of unmeasured consignment is money idle. Get set-level tracking, expiry visibility, and turns by account before you touch quoting sophistication.

$20M–$100M, low consignment (capital equipment, disposables, diagnostics consumables). Contract and CPQ first. Your leakage is in pricing, not inventory. A warehouse layer for true margin follows immediately.

Over $100M, multi-manufacturer. Build and own everything. You need your own product master because manufacturer catalogs will conflict, your own contract master because you'll manage overlapping GPO agreements, EDI to each manufacturer, and a dedicated pricing function. At this scale the cost of a bad architecture compounds fast.

Over $100M, single line. You can lean harder on the manufacturer's systems, but insist on exportability. Get a contractual right to your own transaction data in a usable format, and maintain an independent customer-and-contract master even if it duplicates theirs. Manufacturer relationships end; your data shouldn't leave with them.

Cross-cutting rules regardless of size. Never let compensation run on numbers the finance team doesn't reconcile. Never let a contract go live without an expiration reminder. Never accept a system that can't export its data. And re-run the decision annually — a distributor that adds a consignment-heavy line moves branches, and the architecture should move with it.

Adjacent workflows worth wiring in early

A few things sit just outside the core revenue architecture but pay off disproportionately when connected.

Service and repair. If you handle capital equipment, service contracts are recurring revenue with far better margin than product resale, and they're usually tracked in a disconnected system. Joining service history to the account record lets you see total account value properly and gives reps a genuine reason to visit.

Clinical education and in-servicing. Training hours delivered correlate strongly with product adoption in most device categories. If you're logging in-services anywhere, get them onto the account timeline. It also gives you a leading indicator for new-product ramp that pure order data can't provide.

Expiry and recall workflow. Because you already need UDI-level traceability, the incremental cost of a proper recall workflow is small, and the value when a recall lands is enormous. The same data supports proactive expiry rotation — moving product between accounts before it dies on a shelf.

Freight and delivery cost allocation. Emergency and same-day deliveries for urgent cases are common and expensive. If freight isn't allocated to the account and line, your margin numbers are optimistic in exactly the places that matter, since the accounts demanding most urgent delivery are often the ones already priced tightest.

Supplier rebate tracking. Beyond chargebacks, most manufacturer agreements include growth or volume rebates. These are frequently under-claimed because nobody owns tracking against thresholds. Modeling them in the contract master means you can also see when you're close to a tier and worth a push.

Related questions

How is this different from architecting RevOps for a device manufacturer?

Manufacturers own pricing and manage a distributor channel; distributors take pricing as given and manage inventory and eligibility. Manufacturers care about channel-partner performance and rebate liability; distributors care about turns, chargeback recovery, and contract compliance.

Can a distributor run this on a general-purpose CRM?

Partly. CRM handles accounts, activity, and territory. It handles contract-tier pricing and consignment inventory poorly without significant configuration or a specialist add-on. Treat CRM as one component, not the architecture.

What single metric best indicates the architecture is working?

True margin per account, computed after rebates, chargebacks, and freight, and available without a manual reconciliation. If you can produce it monthly with confidence, most of the underlying architecture is sound.

How does UDI affect revenue operations rather than just compliance?

UDI supplies the join key connecting shipment to case to invoice to recall. Used well, it enables usage-level analytics, expiry management, and lot-level margin. Treated as labeling only, it leaves those questions unanswerable.

Should compensation change before or after the analytics are trusted?

After. Changing comp on numbers finance can't reconcile destroys trust in both the plan and the system. Run parallel calculations for at least one quarter before switching.

FAQ

How long before a distributor sees measurable return on a RevOps build?

Typically two to three quarters for the first hard number, and that number usually comes from pricing enforcement rather than analytics. Once quotes derive price from the contract master, below-contract selling stops nearly immediately and the margin improvement is visible in the next full quarter's line-level data. Inventory returns take longer — usually four to six quarters — because right-sizing consignment requires a full seasonal cycle of usage data before you can safely pull sets.

Do we need a dedicated RevOps function, or can sales operations handle it?

If you have a contract-pricing analyst and someone who owns data quality, the label matters less than the coverage. What fails is when contract loading, chargeback reconciliation, and hierarchy maintenance are everyone's part-time job. Those three functions need a named owner with time protected for them, whatever the org chart calls it.

What should we do first if the current state is spreadsheets and an aging ERP?

The baseline audit. Produce trailing-24-month revenue and line-level margin by ship-to, product, rep, and contract before deciding anything. It takes a few weeks, requires no purchase, and consistently changes people's minds about what to fix first — usually by revealing that a small number of accounts or SKUs account for most of the leakage.

How do we handle a hospital system acquiring one of our accounts mid-contract?

This is why effective dating in the customer hierarchy matters. Model the account under both parents with effective dates so historical reporting stays intact, then review contract eligibility immediately — the acquired facility may move onto the acquirer's GPO agreement at different tiers, which can change your realized price materially without any negotiation on your side.

Is it worth building custom, or should everything be bought?

Buy the ERP, the CRM, and the warehouse. The area where building sometimes wins is the layer that joins contract eligibility to quoting and to invoice-level margin, because packaged CPQ often assumes subscription pricing rather than tier-and-eligibility pricing. Even then, prefer configuring a bought system first and building only where it demonstrably can't reach.

How do we keep the master data from decaying after go-live?

Named ownership plus a fixed cadence. Weekly: contracts expiring in 90 days. Monthly: customer hierarchy reconciliation against IDN membership changes and new ship-tos. Quarterly: territory and product hierarchy audit, plus a sample trace of ten invoices end to end. Publish the results — data quality that nobody sees stops being maintained.

Sources

• https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-assistance/unique-device-identification-system-udi-system
• https://accessgudid.nlm.nih.gov/
• https://www.gs1.org/industries/healthcare
• https://www.ahrmm.org/
• https://www.himss.org/
• https://www.advamed.org/
• https://www.hida.org/
• https://www.cms.gov/medicare/regulations-guidance
• https://www.gao.gov/products/gao-12-370

Related on PULSE

• How do you build a territory model for a field sales team?
• What is CPQ and when does a company actually need it?
• How do you calculate true gross margin after rebates and chargebacks?
• How should sales compensation change when you shift from revenue to margin?
• What does a RevOps data warehouse actually contain?
• How do you forecast revenue for a run-rate business instead of a pipeline business?