LINET: CPQ and order management for complex medical-device sales.

The challenge

Medical-device sales sit at the hard end of quote-to-cash. The product is engineered and configurable: options depend on other options, some combinations cannot be manufactured, and others cannot be sold into a given market. The buying process is just as demanding — tenders, distributor channels and direct sales coexist, each with its own pricing logic and paperwork.

Two failure modes dominate CPQ projects in this space. The first is a quote that drifts from reality: sales configures something the back office cannot build or deliver as quoted. The second is pricing that decays into exceptions — discounts and market-specific terms maintained in spreadsheets outside the system, invisible to approvals and impossible to audit. We wrote about that dynamic in designing CPQ pricing that survives real-world deals.

The quote is also only half of the problem. An accepted quote has to become an order the back office can execute — complete, decomposed and never re-keyed by hand. In device sales, a mistyped order line is not a nuisance; it is a delivery and compliance risk.

Complexity also compounds quietly. Every market variant, every channel exception and every tender-specific term added to the model makes the next one harder to add, until the configuration itself becomes the bottleneck. A CPQ platform for this industry has to be designed for the tenth year of its life, not the demo — which is an architecture problem before it is a tooling problem.

That is the industry backdrop. The published scope of our work with LINET is specific: CPQ and order management for complex medical-device sales, running on Salesforce.

Our approach

We applied the same discipline we bring to every engagement: discover, design, build, run. Discovery means mapping processes, data and systems before touching a single object — and being honest about what Salesforce should and should not own. Design means a clear architecture and a phased plan, so value lands early instead of arriving as a year-long big bang. Build means config, code and integrations delivered in tested increments. Run means the same senior engineers who scoped the platform stay to operate and evolve it.

For CPQ specifically, the discipline that matters most is restraint in the product model. A catalog modelled for selling is not a copy of the manufacturing bill of materials; it exposes the choices a salesperson actually makes and hides everything else behind rules. Approvals are treated as commercial policy, not workflow decoration. The reasoning behind these choices is laid out in our complex-CPQ playbook.

Phasing matters more in CPQ than in most builds. Our default is to prove the model on the product lines that carry real quoting volume, get sales working in the system, and only then extend coverage — because a configuration model that has survived live deals is worth far more than one that is merely complete on paper. Each increment ships tested, so pricing behaviour is verified before a salesperson ever depends on it.

Architecture, at pattern level

We publish client architectures at pattern level only — enough to show the shape of the build without disclosing internals.

Product and configuration

Constraint-based configuration rules keep invalid combinations out of quotes at the moment of selection, not at order review. The catalog is structured for quoting, with market and channel context applied as data rather than cloned product records.

Pricing and approvals

Pricing is layered — list price, then market, channel and deal-level adjustments — so every number on a quote has a traceable origin. Approvals act as guardrails on the exceptions, which keeps discounting visible instead of pushing it into side channels.

Quote to order

Accepted quotes generate orders inside Salesforce, and order management decomposes commercial orders into lines the back office can execute. This is the standard shape we describe in order-to-cash on Salesforce: one governed path from configuration to executable order, with no manual re-keying between stages.

Integration boundaries

Salesforce is the commercial system of record; back-office systems own manufacturing and logistics truth. Validation lookups run synchronously where a salesperson is waiting; order handoff runs asynchronously with retries and idempotency, so a downstream outage delays fulfilment rather than corrupting commercial data. Deciding which logic belongs on-platform followed the framework in when to write Apex — and when to walk away.

Maintainability

Configuration and pricing rules are treated as data wherever possible, so product and pricing owners can extend the catalog without an engineering release. The rules that do live in code are covered by regression tests, because a pricing engine no one dares to touch is technical debt with a commission attached. This is the difference between a CPQ that ages and one that calcifies.

Outcome

We do not publish client metrics without agreement, so the outcome here is stated qualitatively: the published scope — CPQ and order management for complex medical-device sales — runs on Salesforce as one governed path from product configuration to order. Complex quoting happens in a single system with pricing and approvals under control, and accepted quotes become orders without manual translation.

Related reading