Selling Into Healthcare: A Founder's Guide

Published by Forum Ventures in partnership with their HealthTech Council  |  September 2026

Built from interviews with 18+ healthcare buyers, operators, and investors across hospital systems, payers, retail health, and employers — including perspectives from academic medical centers, national health systems, community hospitals, and regional payers.

Forum Ventures is an early-stage B2B accelerator, preseed fund, and AI venture studio. This guide is produced in partnership with the Forum Ventures HealthTech Council, a standing group of senior operators who advise Forum portfolio companies and contribute to resources like this one. To learn more about the council, visit forumvc.com/industry-council/healthtech.

Healthcare Isn't One Buyer

TLDR; This guide draws on conversations with 18+ active healthcare buyers, operators, and investors — including leaders at health systems, payers, academic medical centers, and employers — convened through the Forum Ventures HealthTech Council.

Healthcare isn't one buyer. A hospital system, a payer, a retail health operator, and a self-funded employer each evaluate a new product through a completely different lens, and the sales motion that works for one will actively work against you with another. Most of what goes wrong in an early healthcare sales process traces back to treating these as the same conversation.

This guide exists to shorten that learning curve. It's built from real conversations with people who actually sit in these buying seats, not from theory. It won't hand you a guaranteed path to a signed contract, healthcare buying doesn't work that way for anyone. What it can do is compile the thinking, advice, and specific stories that usually only come from getting a few deals wrong first, so some of that trial and error doesn't have to be repeated from scratch. It's organized around the decisions a founder actually has to make: who you're selling to, how you get in the door, who else needs to say yes, how long it really takes, and what tends to kill a deal without ever producing a clear no.

It isn't exhaustive, and healthcare buying changes faster than any guide can keep up with. Treat this as a map of the terrain other people have already walked.

One thing to say plainly: not everything that trips founders up here is actually healthcare-specific. A lot of it is just enterprise sales, contracts don't get won by a single decision-maker, they need buy-in from a real consortium inside the buyer's organization, and that's true selling into any large company, not just a hospital or a payer. This guide focuses on what's actually particular to healthcare, but it's a good idea to check your own instincts against general enterprise sales practice too, since some of what feels like a healthcare mystery is really just a founder's first time doing enterprise sales at all.

Six things that determine healthcare sales outcomes

There are six things that determine how you need to sell into a healthcare organization. You’ll see these themes come up throughout the guide.

1. Buyer types are unique and should be treated as such. Hospital systems, payers, employers, and retail health operate on entirely different decision logic. You need to deeply understand the logic of the area you’re selling into. 
2. Innovation posture likely won’t work in healthcare. Most health systems want to be third or fourth, not first. Take this into account as you frame your pitch. 
3. Access to a champion matters less than whether that champion has real cross-functional standing to push a deal through.
4. A reference only works if it resembles the buyer in size, specialty, and operating model. 
5. Compliance timing needs to be early. Surface BAA requirements, data handling, and AI governance questions early. Bringing this up mid-process costs trust as well as time.
6. For most large health systems, knowing where your category sits on Epic's internal roadmap is table stakes before the first real conversation.

Know Who You're Actually Selling To

TL;DR: Healthcare isn't one buyer. Hospital systems, payers, retail health, and employers each run on different decision logic, and the sales motion that works for one will actively work against you with another.

The market is not one thing, and the differences aren't cosmetic:

• Academic medical centers. Research-driven, subspecialized, and held to a high compliance bar, which shows up most in the legal review stage. That review is often the real bottleneck, and a fully cautious process can stretch well past a year. It can also move fast when clinicians are already frustrated with an existing vendor and pushing to switch, since legal work done on a prior contract often carries over to the next one.

• Large regional systems. These systems move faster and are actively consolidating vendors rather than adding new ones for their own sake. They want proof before committing: a working integration somewhere else, a reference client, evidence that reimbursement or patient experience actually improved. Being their second or third adopter isn't a defect, it's usually the point of entry that works.

• Community and critical access hospitals. Procurement itself can be simpler here, fewer layers to get through, but the real constraint is capacity. These systems often don't have the IT staff to support a complex new integration, regardless of appetite, so the pitch needs to account for what the system can actually absorb, not just what it wants.

• Pediatric systems. These often look and move like academic medical centers procedurally, but anything not specifically relevant to pediatric care needs to be framed with that in mind. A general-purpose tool pitched without pediatric context reads as generic, even when the underlying technology would work fine.

• Rural health systems. Often more open to new solutions than their size would suggest, because the need is more pressing and less is already in place to compete with. That same lack of existing infrastructure cuts both ways: less inertia to overcome going in, but also less internal capacity to manage the deployment once the deal is signed.

• Private practices and physician groups. An entirely different buying motion, usually a shorter cycle with the physician-owner making the call directly. A working deployment here rarely transfers as a reference once the next conversation is with a large health system, since scale, IT infrastructure, and specialty diversity are different problems entirely, not a bigger version of the same one.

That gap between a practice and a system matters in a different way too. Health systems are multi-specialty, and each specialty runs almost like its own business unit, so a product that's worked in cardiology hasn't been proven in oncology. Treat every new specialty inside the same system as a fresh sale, not an expansion.

Innovation posture matters before the first pitch, not after. A small group of systems are genuine first movers, usually larger, urban, and affiliated with academic medicine, and they're the exception rather than the rule. Most systems are fast followers: they want a working integration, a case study, a reference client, and would rather be third or fourth than first, since being first means absorbing risk nobody's paying them to take on. A remaining group prioritizes stability and compliance above all else, and treating them as an innovation opportunity is usually a wasted meeting, no matter how good the product is.

Different buyer types also run on different underlying logic, not just different processes. A health system is generally trying to engage patients in low-acuity care as a way of feeding specialty referrals and filling the OR. A retail health operator is optimizing for trust and loyalty inside its own footprint, converting that into a larger basket size. A payer is asking whether a specific, urgent problem for a specific internal stakeholder gets solved well enough and cheaply enough to justify the deal at all, which is covered in more depth in the payer section later in this guide.

One risk specific to retail health stands on its own. If the product being pitched is something a well-capitalized retailer could plausibly build in-house, that's real competition, since retailers often have more capital and technical talent to spare than the vendor pitching them. Health systems generally can't compete on technology development at all, which makes them a steadier bet for a product a retailer might otherwise just build itself.

Fit with a given buyer isn't permanent, either. A vendor can be signed in good faith to serve one segment and drift toward a different one as the business grows, at which point the relationship can end even though the product itself never changed. The lesson isn't to avoid that kind of growth, it's to stay honest with existing accounts about which segment they're actually in as things evolve.

One more mismatch to check before building anything: the actual end user rarely looks like the person most founders picture. A large share of healthcare spend comes from patients well past retirement age, not the twenty- and thirty-somethings founders tend to default to when imagining a user, who are usually healthy enough to barely touch the system at all. A product designed around a younger, healthier user can miss the population it actually needs to serve, even when the buyer itself is correctly identified.

Getting In The Door

TL;DR: The fastest way into a health system is borrowed credibility, such as a trusted referral, a matched reference client, or a structured intermediary relationship. Cold outreach rarely works with larger buyers, and relationship building happens long before any specific need exists.

The fastest way in is rarely a cold pitch, it's borrowed credibility. A few channels reliably work, and they compound on each other rather than competing:

• A trusted network connection. The single most effective opener is a reference from someone the buyer already knows and trusts, ideally a champion client who's been taken all the way to real value and is willing to say so to their own network. This matters more than almost anything else on this list, because it substitutes months of credential-building with a single phone call.

• A comparable reference client. A reference only does real work if it resembles the buyer sitting across the table right now. A giant academic medical center doesn't prove much to a mid-size regional system, because the two operate under different constraints entirely, so the match needs to be genuine, not just a recognizable logo. The client also needs to be willing to actually get on a call and vouch for the product directly, since a name mentioned in a slide deck is a much weaker claim than a real person telling a prospective buyer it worked. The story itself needs a specific number behind it too: saying a tool was used by five hundred nurses says nothing about whether it actually helped, while saying it cut charting time by twenty minutes a shift gives a new buyer something concrete to evaluate. A reference that mismatches on size or specialty barely transfers at all, since a system already knows a cardiology deployment doesn't say much about how a product will perform in orthopedics, or how something proven at a small hospital will hold up at ten times the scale.

• Intermediary and advisory firms. Firms that sit between vendors and health systems, evaluating and recommending technology on the system's behalf, can be a real shortcut, especially for a product that isn't obviously differentiated on its own. The pitch has to change for this audience: an advisory firm wants precise, technical differentiation from named competitors, while the health system itself wants to hear what the product actually unlocks for them, not a competitive teardown. If there's no formal intermediary and no published evaluation process, asking directly how many other vendors the buyer has already worked with is a fast way to find out whether they even know the path themselves.

• Tech transfer offices. These offices exist to commercialize an institution's own intellectual property, and their real need is finding a company to license that IP into, since they can implement something once internally but can't scale or sell it themselves. A founder open to incorporating a piece of licensable IP into their platform has a different, often faster way in than a standard vendor pitch. Cold outreach to licensing officers works better than it does almost anywhere else in healthcare, since they're used to fielding it, and they're reliably present at major industry conferences.

• Accelerators. More structured than a tech transfer relationship, typically a two-stage process: admission into a cohort, then a second, more serious look afterward to decide whether to move toward a real deployment. There's still no guarantee of implementation, but the odds are meaningfully better than cold outreach simply because the applicant pool is smaller and the institution has already opted in to paying attention.

Once a conversation actually starts, the first call is about trust, not next steps. Health systems move slowly by nature, and the goal of an early call is to demonstrate real understanding of the buyer's specific pain, not to push toward a close. A rushed pitch that skips past getting to know the institution is one of the more reliable ways to lose credibility before the conversation has really begun.

"Health systems don't move quickly. Call number one is really about, do you understand this prospective client's pain points just as well as they do. A huge red flag for most health systems is a BD team rushing to close deals before really getting to know them. It's going to take us at least six months, and that's fast, to work through our matrix organization and get champion approval, influencer approval, and buying approval." — Grant Skinner, AVIA Health

The better use of an early call is figuring out who else in the organization needs to hear about the problem, and helping the champion build a case internally rather than treating them as the entire audience.

How a pitch actually shows up matters more than founders expect. A clunky demo, an awkward transition between tools, or technology that visibly doesn't work costs real deals even when the underlying product is strong, because in a formal setting, presentation quality reads as a signal about the company itself. Many evaluations run against a specific rubric or a defined set of language and use cases the institution wants demonstrated, and the safest move is to speak in exactly those terms rather than lean on clever branding or an invented feature name that means nothing to the person watching. If no rubric has been shared, asking directly whether one exists is a reasonable move, since a serious evaluator usually has one, even if they haven't offered it up front.

The format of the pitch itself matters too. A live demo beats a deck almost every time, and showing the product working somewhere else is a reasonable substitute if a live one isn't possible yet. Buyers evaluating a small company are often really asking, underneath whatever question they say out loud, whether the team could actually support them at scale, and a well-run demo answers that better than any slide claiming it.

"It can't be a PowerPoint presentation. Show it live, show it working, or show it working somewhere else. We're just here to vet whether it's real or fake, and how big is your team. A great product with a three-person team is a real concern if you're coming to an organization five times the size of your current customer." — Kevin Yee, Henry Ford Health System

Cold inbound, in the traditional sense, rarely works with larger, more established buyers. Relationships tend to get built well before any specific need exists, not in response to one, which means conferences, in-person visits, and simple persistence over time do more than a well-crafted email ever will. The goal of an early touchpoint shouldn't be to close something, it should be to become a known, remembered name, so that when a real need eventually surfaces internally, the buyer thinks of the company that's already been showing up.

A specific version of this impatience shows up constantly: a pitch deck arrives Thursday, a first call happens Friday, and by the following Tuesday the founder is already asking if things can move forward. That pace, reasonable in most startup contexts, actively damages a relationship with a buyer this early, since it signals the founder hasn't grasped how many layers actually stand between a good first conversation and a signed deal.

How a founder describes their own story matters too, in ways that don't always transfer from other industries. Framing that reads as a credibility signal in a general startup pitch, dropping out of school to build the company full time, for example, can land as a red flag with a healthcare buyer instead, since trust and credentialing carry more weight in this world than in most. Describing the same decision as taking a leave rather than dropping out preserves the same underlying story without triggering that reaction.

Underneath all of this is a simple hierarchy: a differentiated product and a real problem-solution fit get a founder into the conversation at all, no amount of relationship-building rescues a weak product. But once that bar is cleared, relationship-building and a reasonable amount of internal politicking are what actually determine whether something gets championed and pushed through, rather than approved on paper and never actually implemented.

Who's Actually In The Room

TL;DR: The approval team scales with how much of the organization a product touches. Any AI component automatically brings in governance, ethics, legal, and IT security, regardless of how simple the product feels. Plan for that from the start.

Big health systems are a team sport, and the size of the team scales directly with how much of the organization a product actually touches:

• Non-clinical, no EMR integration, no patient data. The narrowest case. A champion plus IT and legal is often enough to get a deal done.
• Patient-facing or clinical workflow. Adds clinical informatics, a CMIO or CMO, and patient experience leadership to the mix.
• Any AI component. Brings in the AI governance committee, ethicists, legal, and IT security almost automatically, regardless of how simple the underlying product feels. This isn't optional at most large systems, even for a tool that seems clearly benign.
• EMR integration. Pulls in the Epic team, broader IT, and often outside consulting resources, since this is the category most likely to touch systems well outside the original buyer's own team.

Clinical buyers matter even when there's no EMR integration at all. A point-of-care supply chain tool with zero EMR involvement can still depend heavily on clinical stakeholders like charge nurses and nurse managers, since the integration runs through operational systems instead. The assumption that "no EMR touch" means "no clinical buyer" is a common and costly mistake.

The financial buyer deserves more attention than founders usually give it, since it's frequently the stakeholder who kills a deal that everyone else has already agreed to. A director or VP-level buyer can often approve spend up to roughly six figures on their own authority. Above that, it typically escalates to the CFO, and whether the spend was already planned into a capital or operating budget changes the approval path further. A deal that looks technically won can still die here, for reasons that have nothing to do with the product.

Finding and Using a Champion

A champion is necessary but not sufficient, since their own constraints shape what they can actually do. The strongest champions carry cross-functional credibility, not just enthusiasm within their own department. Physician champions are a particular case: they can be effective advocates, especially when a solution is tightly scoped to clinical workflows they personally own, but the same champion can become a liability once a solution needs to scale across specialties or into other departments where their credibility doesn't automatically transfer.

A related wrinkle shows up when a physician champion also holds equity in the company. The stake in the outcome can make them an even more motivated advocate, but it introduces compliance exposure that a purely enthusiastic champion wouldn't carry, and their own disclosure obligations to the institution need to be sorted out clearly before leaning on them too heavily.

Finding a champion without an existing network connection takes real legwork, but there's a reliable starting point: look for people who've spoken at conferences or appeared on panels about the specific problem being solved. Anyone whose name shows up as a speaker or panelist on that topic is more likely to actually care about it, and more likely to respond to outreach that's clearly tailored rather than generic. A mass-messaged LinkedIn connection request gets ignored almost every time; a specific note referencing the exact talk someone gave, and why the problem they raised connects to what's being built, gets read. Building a list of ten or fifteen real candidates and expecting most not to respond is a more realistic plan than hoping one perfect cold email lands.

Champions and key opinion leaders function differently enough that founders often waste effort treating them as the same target:

Both are lending their own reputation, so under-preparing either one is a real risk, not just a missed opportunity.

Escalating too early, to either of them or past them, has a real cost. Pulling in senior leadership to force a decision can speed things up, but it's not something to spend on every deal, since it draws down a kind of internal credibility that doesn't replenish quickly. The deals that move fastest tend to be the ones with a clear, quick payback story and a reference client solving the exact same problem, since that combination gives an internal champion something concrete to act on without having to call in a favor at all.

Owning the budget and owning the decision are not the same thing. A single budget owner can sign off on spend, but very little actually gets deployed without lateral buy-in from data, marketing, and clinical partners, especially once a deployment touches more than one team's systems. Deals that move fastest tend to be the ones a founder can keep contained within a single team's control; anything requiring end-to-end integration across departments needs those lateral partners brought in from the start, not looped in after the fact.

Clinical and back-office buyers rarely share a vendor, and the reason is more structural than it first appears. Vendors tend to build real depth and relationships on one side or the other, rarely both, so a company that understands the back office well often doesn't understand clinical workflows with the same depth, and vice versa. This becomes a real problem when the actual need spans both sides. A cross-functional coordination gap, like a care pathway that needs primary care, specialty care, and community resources to work together, often has no existing vendor solution at all, not because the technology is hard, but because no company has built relationships deep enough on every side of the problem to solve it.

Most large organizations really run as three separate worlds, and most people, founders included, only understand one of them.

A real bridge between two or three of these worlds is rare and valuable when you can find one. A practical tactic: ask for people by role rather than letting the institution decide who belongs in the room, naming the specific title needed rather than accepting whoever gets sent by default.

Whether physicians are employed by the health system or independently affiliated changes who actually holds leverage over a purchasing decision, and it's a fair thing to ask directly, early. Where physicians are employed, finance and administration tend to have more unilateral authority regardless of physician enthusiasm. Where physicians are independently affiliated, the institution often has to work harder to keep them satisfied, which can give a physician champion real additional pull they wouldn't have in an employed model.

Pitching a health system well means pitching several different audiences at once, not one composite buyer:

• Finance wants to know the return: how much this saves or makes, and what it costs.
• Clinical leadership wants to know how much administrative burden this adds or removes.
• Operations wants to know whether this replaces something already in place, or does the same job more efficiently.
• IT and security want to know about data security, scalability, and how the product connects to existing systems.
• Whoever owns forward-looking strategy wants to know how the product holds up against upcoming payment model or regulatory changes, not just today's rules.

"You almost have to pretend like you're on Shark Tank, and each shark is going to look at it differently. Finance is going to look at ROI. Your clinical leader is going to ask how much administrative burden this adds or removes. Your COO is going to ask if this replaces anything you already have. Your CTO is going to ask about data security and how you connect to different EMRs. And I'm going to ask how you adapt to the latest CMS payment models." — Ryan Mackman, Ascension Wisconsin

One generic pitch deck usually isn't enough for all five of these at once. Building distinct versions tailored to each audience, knowing named competitors well enough to answer direct comparison questions, and treating this as a team sale rather than a solo pitch, ideally with someone who can speak credibly to the technical, financial, and relationship sides of the deal, all matter more than most founders expect going in. A useful pressure-test before the real meeting: recruiting former employees of similar organizations onto an advisory board, specifically so the pitch gets challenged by someone who thinks like the actual buyer before it's tested on the buyer themselves.

A specific framing mistake is easy to fall into and easy to avoid once it's named: pitching a value proposition around reducing headcount, directly to the person whose own headcount would shrink, guarantees resistance no matter how real the efficiency gain is. The same underlying value, freeing up capacity to handle more without adding staff, lands very differently when it's framed as enabling scale rather than cutting people, even though the math is identical.

Legal deserves its own mention, since it functions differently than the other stakeholders on this list. General counsel can act as a real detractor but rarely as an effective champion the way a CFO or CIO can, and legal teams have their own structural incentive to slow a deal down and add cost, since caution and thoroughness are the job. The more reliable path through this isn't avoiding legal, it's working directly with the actual legal counterpart to shape workable terms proactively, rather than submitting something generic and waiting to see what a standard review turns up.

A related trap: having a health system as an investor doesn't guarantee adoption. Even when a system has a financial stake in a company's success, the clinical vetting process tends to stay separate from the investment relationship, for both ethical and practical reasons. The upside of that investment is usually earlier guidance on what "good enough to adopt" actually looks like at that institution, not a shortcut around the review itself.

Timing matters even for a conversation as basic as asking what a buyer can actually approve. Asking about budget thresholds and approval paths too early reads as presumptuous, before there's real alignment on the problem and the proposed solution, that kind of question doesn't have anywhere to land. It becomes a fair question only once real trust and alignment exist, often several months into a longer sales process, not in an opening conversation. On pricing itself, the safer instinct is not to negotiate against yourself: present the number that actually reflects the business first, rather than guessing at a discount preemptively. Buyers will often volunteer the real constraint themselves, mentioning that a given number triggers a committee review, at which point it's fair to ask whether a different number avoids that friction, without either pushing so hard it looks like an attempt to dodge a legitimate process, or dropping the price so far that it undercuts the credibility of the original number.

Language, Timelines, and Money

TL;DR: The right language matters during a pitch. For example, many health systems have been burned by pilots that went nowhere, and so pitching a “pilot” signals risk. Most hospital systems run on margins under one percent, often in the red, and a sales pitch that doesn't account for the financial reality of the buyer reads as out of touch before the conversation really begins. Procurement runs 4 months to 2 years depending on scope; surprises that surface mid-process don't just cost time, they cost the trust that made a faster path possible.

At some institutions, one particular word tends to cost more credibility than founders expect: pilot. It's not universal, but at systems that have already lived through too many pilots that went nowhere, the word itself can signal risk and open-ended commitment before the actual conversation even starts. Swapping in proof of concept, phased deployment, or initial scope costs nothing, and asking a champion directly what language their own organization responds to is a reasonable step before using any term in a formal setting, since the reaction can vary more than the underlying process does.

A lot of what looks like unnecessary bureaucracy usually isn't arbitrary. Reimbursement rules and EMR constraints shape far more of a health system's process than founders tend to assume, and walking in assuming the friction is just institutional slowness, rather than a real constraint someone else has to live inside, is one of the faster ways to lose credibility with a champion who's been navigating that constraint for years. Coming in already understanding why a rule exists, rather than treating it as an obstacle to argue around, changes how a first conversation lands.

The financial reality underneath all of this matters too. The average hospital system is running on a net margin under one percent, and a meaningful number are operating in the red outright. Most of the money that does flow through the system ends up with insurers, not providers. A founder pitching a six-figure tool into that environment is competing against a thin margin for attention, not against a system that simply doesn't want to spend.

Procurement timelines are rough bands, not fixed rules, and they move around a lot based on scope:

That academic-medical-center timeline isn't fixed, either. A deal can move in roughly six months even at that kind of institution when clinicians are already frustrated with an existing vendor and pushing to switch, and when legal has already done due diligence on similar contract language during an earlier relationship with a different vendor. An existing relationship, even a bad one, can create a real shortcut for the next one.

The pattern underneath most of the "slows it down" column is the same: something the buyer needed to know early showed up late instead. Surprises don't just cost time directly, they cost the trust that made the fast path possible in the first place.

The Epic Playbook

TL;DR: If your target buyer runs on Epic (and most large systems do) find out how many engineers Epic has allocated to your category before you pitch. That number tells you more about your real competitive situation than almost anything else.

Epic isn't just a system most hospitals happen to use, it's close to the central fact of the market for a huge share of health tech sales. If a target buyer runs on Epic, and most large systems do, everything else in this guide still applies, with one additional layer on top.

Before pitching an Epic-based health system, find out where the category being sold into actually sits on Epic's own roadmap. Most sophisticated buyers evaluate this through a single question to their own internal Epic relationship: how many engineers are allocated to this build. A one- or two-engineer allocation signals a multi-year horizon, and the system will likely look outside for a solution in the meantime. A hundred-engineer allocation signals Epic is close to shipping it themselves, and most systems will simply wait rather than sign a new vendor. This information usually isn't available by asking Epic directly, it tends to come secondhand, through a system's own IT and strategy leads who ask as part of normal planning.

A real product being better than Epic's own version doesn't guarantee it wins. A strong illustration: Epic's own sepsis prediction model launched at 67% accuracy, later revised to 82%, while at least one outside vendor's model was independently validated through peer-reviewed studies and had FDA clearance, a meaningfully stronger product by any clinical measure. The outside vendor still struggled, because too many systems reason that Epic's version is free, already integrated, and one less vendor relationship to manage. A sharper way to counter that logic exists and rarely gets used: framing the comparison directly around what's actually at stake, a model that misses a meaningful share of real cases versus one that's been independently validated, rather than competing on integration convenience alone.

Part of why a weaker incumbent survives is structural, not just financial. In a large system, the person buying a solution and the person living with its failures every day are often different people, with no clean feedback loop between them. IT capacity compounds this: most IT teams are already stretched thin and don't want to integrate another new system, regardless of merit, since every integration is real, ongoing work for a team that's already overcommitted. That combination makes the existing, already-integrated option the path of least resistance for almost everyone involved except the end user.

The politics inside the buying organization work in Epic's favor by default. There's almost always a contingent internally advocating that Epic can eventually do whatever's being pitched, whether or not that's actually true, and a health system is not going to abandon Epic in favor of a point solution. Even a roadmap item that's two to three years out can be enough to stall a deal, unless the pitch is differentiated enough to justify an immediate return during that gap. Disclosing EMR relevance upfront, even when the product has nothing to do with the EMR directly, tends to help rather than hurt, since someone non-technical in the room will be wondering about it regardless.

What actually happens at the end of this road tends to follow a predictable pattern. Epic's typical move isn't acquisition, it's absorption: building a comparable capability into the core platform, or taking the underlying idea, unless there's a real patent behind it. Ambient AI documentation is a live example of a category Epic appears to be racing toward for exactly this reason, since once a capability lives inside the EMR workflow itself, new and existing clients alike tend to just use what's already there, squeezing outside vendors out of the market over time. Epic's own recently announced partnership with a major AI lab is a current example of the same instinct playing out at a larger scale: bringing frontier AI capability into the core platform directly through a big-tech partnership, rather than through acquiring or partnering with smaller point-solution vendors.

‍None of this means there's no room to build. The strongest protection isn't a feature, it's trust and data. Systems increasingly favor founding teams that read as long-term partners over vendors that read as another transaction, and a company's own proprietary data source matters more than most other differentiators, since most systems, outside of a handful of very large networks, simply don't have enough internal data to build something comparable themselves.

That said, the competitive landscape here is shifting. A growing number of systems are consolidating vendors rather than adding new ones, and turning to forward-deployed-engineer partners, teams that pair people who understand healthcare workflows with engineers who build directly against a system's current infrastructure, as a cheaper alternative to buying an existing point solution. Getting through that filter tends to come down to three things: a specific problem, real speed in solving it, and clear value handed back to the buyer, not just to the product's own roadmap. Missing any one of the three makes it a hard door to get through right now.

The friction that actually kills adoption is usually smaller and more mechanical than founders picture. A common pattern: a clinician gets a result from an outside tool that lives in its own separate application, with its own login and no write-back to the chart, so acting on it means leaving the EHR, finding the patient in a different system, interpreting the result, and returning to the EHR to document and place orders by hand. That's five or six extra clicks and a full context switch, multiplied across a full patient list, and multiplied again by every additional standalone tool doing the same thing.

Those clicks land on physicians who are already operating with almost no slack. A typical schedule allows only a short window per patient, and documentation already eats a large share of it before a single extra tool is added. In that environment, clicks aren't a minor annoyance, they're direct competition with either the next patient in the waiting room or the physician's own evening, since unfinished documentation doesn't disappear, it gets pushed into personal time after the workday ends. Physician burnout tied specifically to EHR burden and documentation load is a widely documented problem across the industry, not a fringe complaint, which is exactly why a tool that adds friction gets abandoned quickly regardless of how good its underlying output is. An algorithm's quality stops mattering once this is the actual experience of using it.

The Payer Playbook

TL;DR: Selling to a payer looks more like traditional enterprise sales than the population-health pitch founders usually build. The gating question isn't whether your outcomes are good but whether you're solving a top-five priority for a specific person, right now, at a price that beats the alternative.

Selling to a payer looks much closer to traditional enterprise sales than the population-health logic the pitch often gets built around. Good outcomes for a population don't automatically unlock a budget. The real question a payer is asking is narrower and more personal: is this a top-five concern for a specific person right now, is it urgent enough that it can't wait, and is the solution meaningfully better or cheaper than the alternative, not just marginally so. Founders who've already sold enterprise software into a large company tend to have the right instinct here already. Founders coming from a purely clinical or population-health background often don't, and the gap tends to widen rather than close as the payer gets larger.

Who actually makes a decision varies enormously, more than the rest of this guide's buying-team advice would suggest, so it's better to check directly than assume a single model applies. A smaller, more centralized payer might have one person evaluating network additions end to end. At a larger national payer, the answer depends on which part of the organization is being sold into: a value-based care team might own national contract decisions state by state, while a health system's own local provider network is managed separately and locally. The honest first step with any payer is figuring out which part of the organization actually owns the specific thing being sold, rather than assuming "the payer" has one throat to choke.

One standard here cuts against a lot of standard startup advice: readiness needs to come before the contract, not after. A national payer generally isn't interested in financing a company's scale-up. The expectation, especially among the largest payers, is closer to already having the integrations, the provider roster, and the utilization data in hand before a serious conversation even starts, not a plan to hire and build once the contract lands. A pitch built around "give us the contract and we'll figure out delivery" tends to read as a real risk rather than a growth story at this level.

The plainest version of this standard, heard directly from a payer operator during a live discussion: a two-person team in a garage isn't ready for a deal with one of the largest national payers, and founders need to size their sales ambitions to match where the company actually is, not where they hope to be by the time the contract closes.

Talking to a payer in its own financial language helps more than founders expect. Framing a product's value specifically around cost of care and medical loss ratio, the standard measure payers use for how much of every premium dollar goes to actual care versus overhead, lands better than a generic efficiency or population-health pitch, since it maps directly onto what the payer is already being measured on internally. And the urgency test that opens this section works best when it runs in both directions: the strongest pitches make the case that the problem is a real, immediate priority for the buyer and that the solution earns the buyer's own urgency to adopt, not just a nice-to-have from the vendor's side.

There's a meaningful exception here. A health system entering a new value-based care model for the first time can sometimes get an easier yes on a modest first contract, even without a track record in that specific model, because the health system already has the deployment infrastructure, data integration, and staff capacity to absorb the work without adding operational risk. The bar isn't "have you done this exact thing before," it's "can you actually execute at the scale you're proposing, starting now," and that's a real distinction from how the rest of this guide describes buyer timelines.

What gets screened for often surprises founders coming from the health-system side of this guide. Security posture and compliance, which loom large in a hospital's own vendor review, are frequently not the limiting factor in a payer's decision to add something to its network. The more common gating questions are about clinical footprint, geographic coverage, specialty fit, and whether there's real member demand for what's being added. Execution readiness tends to matter more than a security questionnaire at this stage of the relationship.

An employer is a different buyer than the payer covering the same population, not a variation on the same pitch. Where a payer reasons in something close to actuarial terms, an employer tends to reason experientially: access, and whether employees feel cared for, carries real weight in a way it doesn't for a payer weighing population-level cost. That difference cuts both ways. A model like Direct Primary Care can pitch well to an employer on access alone (round-the-clock availability, a doctor who knows an employee by name), but the same pitch runs into a real objection a payer wouldn't raise the same way: it reads as an additional cost stacked on top of a health plan that already includes primary care. Framing that additional cost as net savings, and addressing it head-on rather than avoiding it, tends to matter more with an employer than with almost any other buyer type in this guide.

Patient-Facing AI: Where the Brakes Are

TL;DR: Administrative AI is accelerating inside health systems. Patient-facing AI is largely stalled due to  institutional trust. Treat the two as separate adoption curves.

Administrative AI is moving fast inside health systems. Patient-facing AI is moving much more slowly, and the gap between the two isn't really about what the technology can do, it's about trust.

The concern founders run into most often isn't about accuracy, it's about what happens to the information afterward. Patients worry about AI being used against them: insurance implications, a system knowing about a prior condition it shouldn't factor in, a decision made about them rather than with them. Every positive use case comes paired with a version of that same question in the back of someone's mind, which is why health systems have been deliberately sequencing adoption, going after clear administrative wins first rather than risking a visible failure on something patient-facing.

That caution shows up in public view too. Mayo Clinic's former Director of Research Operations, Traci Tamiko Eto, filed a federal lawsuit in July 2026 alleging she was demoted and fired after raising internal concerns that the health system's AI programs, including flagged accuracy issues in one of its own tools, weren't being reviewed or disclosed the way federal research oversight requires. Mayo has stated it's committed to responsible AI development and declined to comment further given the active litigation. Whatever the case's outcome, the fact that it surfaced publicly at all is itself a signal of how exposed institutions feel on this front right now, and why a system that's otherwise moving fast on AI can still be slow and cautious the moment a product touches a patient directly.

The three categories don't move at the same speed, and treating them as one adoption curve is a common mistake:

This pattern holds beyond any one institution. Multiple health systems are pulling back on patient-facing AI specifically while accelerating administrative use, and the caution shows up even in adjacent fields, behavioral health in particular treats therapy bots and voice AI as an area to move on deliberately slowly, not quickly.

A newer wrinkle is showing up on the administrative side too: token cost accountability. Several systems are moving away from unmetered internal AI use and starting to charge token costs back to the specific business unit using them, which makes leadership more wary of pilots that never make it to production and just accumulate cost in the meantime. A founder pitching an administrative AI tool now sometimes has to answer a cost-per-use question that wouldn't have come up even a year ago.

What would actually move patient-facing AI forward isn't a better model, it's better trust design:

• Opt-out mechanisms that are simple to use, not buried in a settings menu
• Patient-facing language and consent flows written in plain terms, not legal or clinical language
• Case studies that demonstrate patient satisfaction directly, not just operational efficiency gains
• A value proposition that stays clearly separate from sensitive data categories like genetic information or the full medical record, even when the underlying product doesn't strictly need to touch them

What Happens After You Win the Pilot

TL;DR: Winning a pilot isn't the same as implementing one. 'Free' for the buyer still means project management time, data integration work, and QA on their side. Vendors who don't seem to know that lose credibility fast. The four things that most reliably kill a pilot before it starts: unseen implementation costs, timing conflicts with a competing initiative, budget cycle mismatches, and gaps in the buyer's operational readiness. What predicts success isn't the technology but whether the internal champion who asked for the pilot still has the standing to push it through.

A pilot that gets signed isn't the same as a pilot that gets implemented well, and the gap between the two is where a lot of otherwise promising deals stall out. A few realities tend to surprise founders here, since they only show up once implementation actually starts.

"Free" is not the same as costless for the buyer. Even when a vendor waives the fee entirely, the health system still absorbs project management time, data integration work, and QA and testing on its own side. A vendor who doesn't seem to know this reads as out of touch with the reality of the stack they're plugging into, not as generous.

"It'll work across your practices" means something different once hundreds of locations are involved. A tool that works cleanly for one location doesn't automatically know how to handle a system with hundreds of practices, each with its own configuration and workflow quirks. Assuming otherwise, or worse, not having an answer ready when asked how the tool handles that scale, is one of the faster ways to lose credibility mid-deal.

Timelines that promise "six weeks to live" tend to read as a red flag rather than a selling point. Nothing at a health system moves that fast, and a founder who doesn't seem to know that comes across as unfamiliar with the environment. What actually builds confidence is demonstrating awareness of everything that has to happen in parallel, not a single fast number.

A useful tactic here: offering a sandbox environment with synthetic data, set up in advance for the buyer to explore on their own terms, tends to go a long way, especially when what they see in the sandbox transfers cleanly to the real deployment.

“We’ve seen pilots that were successful with the end user who asked for the pilot only to get shut down by the CIO or other senior leaders within the health system. Make sure you understand who will be involved in the ultimate purchase decision and what success looks like for all of them, not just the front line users that asked for the pilot” - Michael Cardamone, Founder & Managing Partner at Forum Ventures

Four things reliably kill a pilot before it even gets going:

What actually predicts whether a pilot succeeds is less about the technology and more about who's asking for it. Pilots that solve a problem both patients and staff are already asking about tend to succeed, and staff, nurses, front desk teams, physicians, tend to be the real champions for anything consumer-facing, more so than any executive sponsor.

Two contrasting examples make the pattern concrete. A secure texting feature built quickly during COVID, originally intended as a stepping stone toward a bigger CRM push, ended up beloved by front desk staff for reasons that had nothing to do with the original pitch. A facial recognition check-in tool, on the other hand, was engineered carefully into the existing workflow and still failed, because it turned out ID checks weren't actually being performed consistently in practice before the tool existed. The tool added a step that existed on paper but not in real life, and both patients and staff resented it. The lesson isn't that either tool was well or poorly built, it's that the real workflow, not the documented one, determines whether something lands.

Getting the success metric right matters as much as getting the product right. If a contribution margin isn't worked out ahead of time, and something else, a marketing campaign, a seasonal shift, happens at the same time a new tool launches, the tool won't get credit for results it may have actually helped produce. One automated phone system hit its contracted quality metric (percentage of calls resolved successfully) while completely missing the metric that actually mattered (reduction in call volume to live agents), partly because a meaningful share of the original call volume had been silent, abandoned calls that never showed up in the baseline the metric was measured against. Try-before-you-buy arrangements tend to work best when there's an established baseline to compare against, and worse for a newer category where nobody yet knows what "normal" looks like. A full quarter of patience before drawing conclusions tends to be a safer bet than judging results too early.

Not every product is trying to prove itself against a quality metric, either. When the value case is closer to "the right thing to do" than a specific measurable clinical or financial outcome, that story needs to be framed differently, and it's a harder sell than it used to be, since most institutions are focused on the next year or two of operating margin rather than a longer-term bet. A related pattern shows up in consumer health products that start out selling directly to individuals: many eventually hit a ceiling and pivot toward selling through an enterprise buyer instead, at which point the pitch, the metrics, and the entire value story need to shift to match that buyer's priorities rather than the original end user's.

A word on reimbursement, since it comes up constantly. Whether a reimbursement-dependent product is fundable tends to come down to four things: a payment pathway that already exists today, a clearly identified economic buyer along with an honest account of why that buyer comes out ahead under current payment terms, an evidence plan sized to the specific claim being made, and unit economics that survive a slow path, since reimbursement almost always takes longer than the deck says.

What to do when there's no existing billing code doesn't have a single answer, but there are real precedents. Some companies pursue a new code directly, HeartFlow's path to a set of codes built specifically for its coronary artery disease diagnostic is a workable model, and Out-of-Pocket's breakdown of how the CPT process actually works covers the mechanics well. Others build toward a code indirectly: at least one founder has described having pharma sponsors pay to use his product for their own real-world evidence collection, then using that data to eventually request a new code from CMS, covered in a MedCity News writeup of a conference panel on the topic. And some sidestep the billing-code question entirely by structuring payment as a direct membership or subscription fee rather than a per-service claim, a path that requires real EHR integration and its own reporting obligations to CMS in ACA-regulated markets.

How Deals Actually Die

TL;DR: The risk that actually kills a deal is rarely regulatory: it's whether a new tool disrupts existing internal power dynamics, and oftentimes this is never fully admitted. Leadership transitions can also freeze every live vendor conversations or, alternatively, accelerate one that has stalled. Ask directly which way a transition is likely to move rather than assuming.

Most deals that fail don't end with a clear no. They end by going quiet, and learning to read that pattern early can save a founder months of chasing something that's already over.

The clearest version of this: a health system had already built its own internal tool solving a specific clinical problem, when a senior executive, unaware that work existed, separately signed a deal with an outside vendor to build essentially the same thing. The internal team felt blindsided. The new tool wasn't as good as what they'd already built themselves. Once it launched, nobody trusted it and nobody used it, and it eventually just faded away without anyone ever officially killing it. Nobody said no. There was no specific complaint to respond to, no clear objection to overcome. There simply wasn't enough internal buy-in to keep it alive, and it withered in the absence of anyone actively pushing for it.

There's a real reason deals die this way instead of ending with an honest no. Acknowledging a failed initiative out loud requires a level of internal trust and psychological safety that's the exception inside most large organizations, not the rule. Silence and quiet abandonment carry much less personal risk for everyone involved than standing up and saying a decision didn't work out, which is exactly why apathy, not rejection, is the more common ending.

The risk that actually kills a deal is rarely regulatory in the way founders expect. Requirements like Joint Commission or CMS standards are generally well understood and can be addressed head-on, in a factual conversation with a clear answer. The deeper, harder-to-name risk is whether a new tool will slow clinicians down or force them to see fewer patients, a concern that's only gotten sharper since COVID. That's a much less concrete fear to overcome than "does this meet a specific regulatory requirement," and it's usually the real thing sitting underneath a stalled deal, even when the stated objection is about something else entirely.

A related pattern shows up when an institution hides behind a process argument instead of engaging with a decision directly. One example: a health system refused to adopt an already well-established heart failure therapy until it appeared in formal clinical guidelines, even with a national coverage decision and published literature already in place, and cardiology guidelines can take a decade to update. When a system leans this hard on a process technicality, it's often standing in for a missing or unconvinced clinical champion inside the specific department that would need to adopt the tool, and it's a sign that not enough clinicians are actually in the room making the call.

Founders chasing a guaranteed win are chasing something that doesn't exist. No pilot outcome can be promised in advance, and pretending otherwise doesn't buy real trust with anyone who's been through this before. The more honest version of de-risking a deal is finding a champion willing to speak candidly about the actual appetite for testing something that might not work, rather than convincing yourself in advance that it will.

Leadership transitions can move a deal in either direction, and finding out directly which way is a better bet than assuming. A CEO retiring or a CIO leaving can freeze every live vendor conversation during the handoff, since nobody wants to commit to something their successor might reverse. A major systems transition can do the same thing at even greater scale: one health system paused 70 to 80 percent of its digital initiatives during the first phase of an EMR migration alone. Leadership change can just as easily do the opposite: new leadership arriving with something to prove can move faster on exactly the kind of decision that had been stuck. Both patterns are common enough that asking directly where an institution stands in a transition, of either kind, beats guessing based on which way seems more likely.

Regulatory change can create real urgency where none existed before, though it's a less reliable lever than it might seem. This is a different question from the reimbursement pathways covered earlier in this guide, that's about whether a specific product can get paid for at all; this is about whether a regulatory shift creates enough urgency to move a stalled sales conversation. A newly proposed rule can threaten an incumbent's business model and open a real window for a new entrant, but the timing takes real care, and a rule's actual downstream implications are often not clear until well after it takes effect, the Affordable Care Act being a good example of impact that took years to fully play out. A typical rule has a public comment period, needs to be finalized well before its effective date, and the language can still shift before that happens. Betting too early on the exact wording of something not yet finalized risks overcorrecting in the wrong direction before the rule even exists in its final form. A more dependable lever, when available, is appealing directly to what a CFO or CIO has to gain or lose personally, since regulatory timelines are unpredictable in a way that an executive's own incentives usually aren't.

Where the Real Opportunity Is

TL;DR: Four categories keep coming up as places where the problem is larger than the current supply of good solutions: revenue cycle and prior authorization, care delivery shifting out of hospital settings and into community and home, population health data integration (specifically connecting EMR and claims data, which most institutions still handle manually), and AI governance tooling as agentic tools multiply. Population health management itself, by contrast, may already be saturated; most large systems have something in place and aren't paying for a second.

A few categories keep coming up as places where the actual problem is bigger than the current supply of good solutions.

Revenue cycle and prior authorization show up more than any other category. There's a real sense that insurers and providers are locked in an ongoing arms race over who has better automation on their side of a claim, and most institutions don't have a full, accurate picture of how much they're actually billing versus what they're actually collecting. A tool that could reliably surface money already being missed, not projected savings, actual dollars, tends to get attention fast. Prior authorization and other clerical burden around it remain persistent pain points for the same underlying reason: a lot of institutional effort still goes into work that produces no clinical value at all.

Care is shifting away from the hospital building itself, into community settings, clinics, and the home, and that shift still has a long way to run. Most of the infrastructure and tooling built for care delivery still assumes a hospital or clinic setting by default, which leaves real room for anything built specifically for care that happens somewhere else.

Population health data integration is a real, unsolved problem for a lot of institutions, specifically the basic task of getting EMR data and claims data to talk to each other. Right now that work often happens manually, by people, because no reliable automated bridge exists between the two systems.

AI governance and monitoring tooling is becoming its own category as agentic tools multiply across an enterprise. The open question for a lot of institutions isn't whether to adopt more of these tools, it's how to monitor, audit, and keep guardrails around dozens or eventually hundreds of them running at once, with no clear category leader yet solving that specific problem.

One caution belongs alongside the opportunities above: population health management itself may already be saturated. A lot of both small and large companies have been building in this space for a while, and it's increasingly a question of survival among existing players rather than room for a new one, since larger health systems typically already have some version of this software in place and show little appetite to pay for a second one doing roughly the same job.

What Not To Do

TL;DR: Most of what goes wrong in healthcare sales is around buyer mismatch, i.e. applying one buyer's logic to a different buyer, moving too fast for how the institution actually works, or treating a clinical problem as simpler than it is.

A short list of specific, recurring mistakes, the kind that show up across nearly every account gathered for this guide.

• Don't run one playbook across every account. Health systems, payers, retail health, and employers evaluate on different logic entirely. A single pitch deck and a spreadsheet of the top fifty targets rarely produces results, no matter how good the product is.

• Don't assume the problem is easy just because it looks obvious. A founder who walks in convinced they'll immediately solve something an institution has struggled with for twenty years reads as naive rather than confident, and tends to get tuned out fast.

• Don't lean on a generic "AI for X" pitch. This framing has already cycled through most parts of the healthcare value chain, and by now it reads as dated rather than novel, even when the underlying technology is actually new.

• Don't treat presentation polish as an afterthought. A clunky demo or an awkward transition between tools has cost technically superior products real deals. In a formal buying environment, how something shows up gets read as a signal about how the company itself operates.

• Don't go in solo. A team that combines technical depth, financial fluency, and relationship-building tends to outperform a single generalist founder trying to cover all three at once, especially the larger the deal gets.

• Don't assume every pitch deserves to win. Most products pitched to a buyer simply aren't strong enough yet, and that's a more common explanation for a no than any objection about timing, budget, or process. If the answer is no, the more useful response is figuring out whether the product needs to change, not looking for a way around the no.

• Don't imply you understand a clinical problem better than the physicians who live with it. Even a hint of this can get a founder dismissed on the spot, regardless of how strong the underlying idea is.

• Don't go around a frontline contact to reach their boss. Even when the boss is receptive, the frontline person, who's actually needed to make anything work day to day, loses trust the moment they're sidestepped. If a conversation stalls, the better move is asking the boss who else should be involved, and letting that introduction flow back down rather than skipping straight to the top.

• Don't skip the homework on the specific clinical space. Knowing the current standard of care, and why it's the standard, doesn't require matching a specialist's expertise, but it's the minimum fluency needed to be taken seriously once a physician with strong opinions is in the room.

• Don't assume a workflow problem is automatically a technology problem. A tool can be well built and still fail if the actual issue is how people behave rather than what software they're using, and that distinction deserves an honest, skeptical look before building around it.

Before You Go

This guide only exists because people who actually sit in these buying seats were willing to talk through what usually only gets learned the hard way. This guide is a living document, and that's by design. If you're reading this and something doesn't match your own experience, or you have a story that could sharpen a section further, we'd genuinely like to hear it!

This guide is a Forum Ventures HealthTech Council resource. If it helps you sell more confidently and knowledgeably, consider applying to the Forum Ventures program at forumvc.com/pitch-us or learning more about the council at forumvc.com/industry-council/healthtech.

Acknowledgments

This guide exists because a group of people who actually sit in these buying seats were willing to share it, in one-on-one conversations, in the questions they'd let us shorten the sales cycle by asking, and in the discussions and side comments during regular council meetings. Whether the connection came through a formal interview or a comment made in passing during a session, all of it shaped what's here.

Thank you to Julia Bernstein (Brightside Health), Phil Eaves (Ascension), John Joshua (One Health Collective), Andrew Kaplan (Arizona Heart and Vascular), Zain Ismail (Walmart Health & Wellness), Eli Lourie (CHOP), Ryan Mackman (Ascension Wisconsin), Errol Norwitz (Babson College), Rick Peng (Memorial Sloan Kettering), Jeremy Rogers (Beacon Health System, formerly IU Health), Shai Ran Sapir (formerly Mayo Clinic Ventures), Dov Shamir (J.P. Morgan), Grant Skinner (AVIA Health), Alex Tang (Metriarch), Vijay Venkatesan (IKS Health), Kevin Yee (Henry Ford Health System), Darrell Williams (Eli Lilly), Xavier Barnes (Aetna), and Emily Kagan (formerly Northwell Health).

‍

Frequently Asked Questions

How long does healthcare procurement actually take?

It depends on scope. A non-clinical tool with no EMR integration can move in roughly 4 to 6 months. A clinical workflow with some data integration typically takes 9 to 18 months. Full EMR integration, patient data, or an AI component stretches to 12 to 24 months. Large academic medical centers often run on a 1.5- to 2-year timeline driven by legal review. The single biggest speed variable isn't interest — it's whether compliance questions surface early or late.

Who actually needs to approve a health tech deal?

It depends on what the product touches. A non-clinical tool with no EMR integration and no patient data typically needs a champion, IT, and legal. A clinical workflow adds clinical informatics and a CMIO or CMO. Any AI component — no matter how simple it seems — almost always adds an AI governance committee, ethicists, legal, and IT security. EMR integration brings in the Epic team, broader IT, and often outside consulting resources.

How do I get into a health system?

The fastest routes are borrowed credibility: a reference from someone the buyer already trusts, a matched reference client willing to get on a call and vouch for you, or a relationship with an intermediary advisory firm that evaluates technology on the system's behalf. Cold outreach rarely works with larger, established buyers. Relationships get built before a specific need exists — through conferences, in-person visits, and consistent presence over time.

How does Epic affect a health tech sale?

Significantly. If your target buyer runs on Epic — and most large systems do — you need to know where your category sits on Epic's own internal roadmap before your first serious conversation. The key data point is how many engineers Epic has allocated to the category. A small allocation signals a multi-year build timeline, and systems will look outside in the meantime. A large allocation signals Epic is close to shipping it — and most systems will simply wait. Even a technically superior product can struggle against an already-integrated Epic alternative that is free and removes one vendor relationship.

What is different about selling to a payer versus a health system?

Selling to a payer looks much closer to traditional enterprise sales. Good population-health outcomes don't automatically unlock a budget. The real question a payer is asking is narrower: is this a top-five concern for a specific person right now, is it urgent enough that it can't wait, and is the solution meaningfully better or cheaper than the alternative? Readiness also needs to come before the contract, not after — national payers generally aren't interested in financing a company's scale-up. And security posture, which looms large in hospital vendor reviews, is frequently not the gating question for payers. Clinical footprint, geographic coverage, and member demand tend to matter more.

What mistakes do founders most commonly make in healthcare sales?

The most common: running the same playbook across every buyer type, assuming a problem is easy because it looks obvious, leading with generic 'AI for X' framing that has already cycled through the market, treating presentation polish as secondary, and moving at a startup pace with a buyer that needs months to move through its own internal layers. See the 'What Not To Do' section for the full list.

What is Forum Ventures' HealthTech Council?

The Forum Ventures HealthTech Council is a standing group of senior healthcare operators — including buyers, system leaders, payer executives, and investors — who advise Forum Ventures portfolio companies and contribute to resources like this guide. The council convenes regularly to share current buying intelligence and practitioner experience with founders who are selling into healthcare for the first time. Learn more at forumvc.com/industry-council/healthtech.