Medical device and diagnostics companies use Salesforce to run the commercial side of the business: hospital and IDN accounts, surgeon and lab relationships, capital deals, consumable pull-through, GPO contract visibility, installed equipment and service. The quality system, ERP and contract system stay the systems of record. Salesforce becomes the place where reps, clinical specialists, service engineers and marketers see the same customer and hand work to each other cleanly.
How should a device company model hospitals, IDNs and GPOs?
Model the buying structure first: health system, member facility, department and the GPO each account belongs to. Get this wrong and every territory, contract and revenue report inherits the error.
A typical structure uses the standard account hierarchy for the IDN and its hospitals, ambulatory surgery centers and labs. Departments such as cath lab, OR or core lab often matter more than the facility. Many teams store them as child accounts or as a related object, depending on how they are sold and serviced.
- GPO membership: a separate related record linking each facility to one or more GPOs, with start and end dates. Avoid a single picklist; facilities change affiliation.
- Ship-to and bill-to: synced from ERP as account identifiers, not retyped by reps.
- Physicians and lab directors: contacts related to several facilities, because surgeons often operate at more than one site.
- Value analysis committees: tracked as a buying-stage milestone with members and meeting dates, since many capital and new-product deals stall there.
Keep the clinician record clean. One surgeon duplicated across three hospitals makes territory credit, HCP spend tracking and marketing consent unreliable.
Do capital equipment and consumables need different sales processes?
Yes. Capital is a long, committee-driven opportunity; consumables are a recurring revenue stream you protect and grow. Forcing both into one opportunity process gives you a bloated pipeline and a useless forecast.
Capital deals fit standard opportunities well: stages tied to clinical evaluation, value analysis, budget approval and installation. Placement models complicate this. Reagent rental, usage-based placement or a system placed against a consumable commitment all blur capital and recurring revenue.
For consumables, most teams stop opening an opportunity per order. They load shipped or invoiced revenue from ERP and compare it to targets by account and product family. Opportunities are reserved for conversions, new departments and competitive takeaways.
| Revenue type | How it is tracked | System of record | What reps act on |
|---|---|---|---|
| Capital equipment | Opportunity with evaluation and committee stages | ERP for orders and invoicing | Stage, close date, approvals, installation date |
| Placed or rented systems | Opportunity plus a placement or agreement record | Contract system or ERP | Commitment versus actual usage by account |
| Consumables and reagents | Revenue loaded from ERP against targets | ERP | Accounts trending below baseline or commitment |
| Service contracts | Renewal opportunity or service contract record | ERP or Service Cloud | Expiring coverage and uncovered installed units |
How do GPO contracts and pricing tiers reach Salesforce?
Usually by integration, not by rebuilding the contract system. Reps need to see which agreement and tier an account is on; they rarely need to author pricing in Salesforce.
Device pricing depends on GPO agreements, local agreements, tier qualification and sometimes rebates. That logic normally lives in ERP or a dedicated contract and pricing system. Integrate it by category:
- Agreement headers: GPO, agreement number, effective dates and eligible facilities, read-only in Salesforce.
- Tier status: the account's current tier and how close it is to the next one, refreshed on a schedule.
- Pricing for quotes: either pulled from the pricing source at quote time or kept in price books loaded from it.
- Rebates and chargebacks: summarized for reps if useful, but calculated and paid outside Salesforce unless you adopt a product built for it.
If you quote in Salesforce, decide which system wins on price before go-live. Two price sources that disagree will generate disputes and manual credit memos.
How do field reps and clinical specialists coordinate case coverage?
Give procedure support its own scheduled record, separate from sales activity. That record should name the facility, physician, procedure date, products needed and the assigned specialist.
Clinical specialists often support cases, train staff and attend implants or first uses. Their calendar is driven by hospital schedules that change late. A generic design that works for many companies looks like this:
- A coverage request, created by the rep or the account, with procedure details and required kit.
- Assignment based on territory, product certification and availability, with a visible queue for unfilled requests.
- A link to field inventory or loaner kits, so specialists can see what must be at the site.
- A short post-case record capturing outcome notes and any product issue, which can start a complaint if needed.
Keep patient details out of these records unless your compliance team has approved storing them. A procedure date and facility are usually enough for coverage.
How should installed base and service run in Salesforce?
Track every placed unit as an asset tied to the facility, with serial number, model, install date, warranty and software version. Service Cloud or Field Service then works cases and work orders against that asset.
The asset record answers questions sales and service both ask. Which systems are near end of life? Which hospitals have uncovered units? Which serial numbers share a field action?
Service Cloud handles phone, email and portal cases, entitlements and repair returns. Field Service adds scheduling and dispatch of engineers, preventive maintenance plans, parts and mobile work orders. Smaller service teams often start with Service Cloud and add Field Service once dispatch volume justifies it.
How should complaints reach the quality system?
Salesforce captures and routes the first report; the regulated quality management system owns investigation, decisions and reporting. Treat this as design guidance and confirm specifics with your regulatory and quality teams.
Device companies hear about product problems through support calls, service visits, reps and case coverage. Each of those channels can live in Salesforce. The common pattern is to capture once and pass it on:
- Any case, work order or post-case note can be flagged as a possible complaint by the person who heard it.
- Required intake fields capture product, lot or serial number, event date, description and whether a patient was involved.
- The record is sent to the quality system through an integration, and the quality system's reference number comes back.
- Salesforce users see status, but closure and any regulatory decision happen in the quality system.
What should marketing to HCPs account for?
Consent, audience separation and spend visibility. These are design points to review with your compliance and legal advisers, not legal advice.
- Consent by channel and purpose, stored on the person and synced between Salesforce and your marketing tool.
- Separate audiences and journeys for clinicians, procurement and, where relevant, patients, with different content approvals.
- Open Payments awareness: meals, educational items, grants and other transfers of value given to covered recipients may be reportable under the Sunshine Act. Design capture so reps record these consistently, then feed your transparency reporting process.
- Clinician identifiers such as NPI stored once on the contact, so spend, consent and activity tie to the right person.
Our medical device marketing rescue shows why the data layer matters. The company could not log into Pardot and was over its prospect limit. We migrated it off the deprecated Classic version onto Account Engagement in Lightning and removed 970+ invalid prospects.
The rebuild added lead scoring, templates, Engagement Studio automations, and forms for trade shows and sample requests. The outcome was working automation for both B2B and patient audiences.
Life Sciences Cloud, or Sales Cloud and Service Cloud?
Start by mapping your processes against both. Salesforce now positions Life Sciences Cloud for MedTech as well as pharma, so it deserves a look before you build custom objects.
Salesforce describes Life Sciences Cloud as covering clinical, medical, commercial and patient services work for pharma and MedTech. Its MedTech material names field execution, field inventory, order management, contract compliance and rebate capabilities. Trailhead content also covers surgical case visits and field inventory. Licensing, editions and exact feature scope change, so confirm with your Salesforce account team.
- Lean toward Life Sciences Cloud when field inventory, consignment, surgical case visits and contract compliance are central and you want packaged objects for them.
- Lean toward Sales Cloud and Service Cloud when the need is mostly hierarchy, pipeline, installed base and service, and contracts stay in ERP.
- Either way, ERP, the contract system and the quality system remain separate systems of record.
Health Cloud is a different question. It is aimed at patient and member care, which is rarely what a device commercial team needs.
Which reports does a device commercial team rely on?
Reports that join account structure, ERP revenue, installed base and service. Pipeline alone tells a device leader very little.
- Consumable revenue versus baseline by IDN, facility and product family.
- Capital pipeline by stage, with deals waiting on value analysis called out.
- Installed units by age, warranty and service coverage, with renewal gaps.
- Case coverage requests filled, unfilled and late by territory.
- Open complaints by product family, with quality system status.
- GPO tier position for key accounts, showing who is close to a threshold.
Where do device CRM projects usually go wrong?
Most problems come from blurring systems of record or skipping the account model. These recur often enough to plan against:
- Building pricing and rebate logic in Salesforce when ERP or the contract system already owns it.
- Running consumables as one opportunity per order, which buries the capital forecast.
- Letting complaints close in Salesforce instead of the quality system.
- Duplicate surgeons and facilities from trade show lists and distributor files.
- Storing patient identifiers in coverage or service notes without a deliberate decision.
- Choosing an industry cloud before mapping the processes it would replace.
What should a device company build first?
The account model, capital and consumable selling, and a working ERP feed. Service, case coverage and marketing follow once the customer data is trusted.
- Phase one: IDN, facility, department and GPO structure; clinician contacts; capital opportunities; ERP sales history and targets; agreement and tier visibility; core dashboards.
- Phase two: installed base assets, Service Cloud cases and complaint intake integrated with the quality system.
- Phase three: case coverage scheduling, Field Service dispatch, field inventory and HCP marketing with consent and spend capture.
Teams with an existing org should start with a health check of the account data. Fixing hierarchy and duplicates first makes every later phase cheaper.

