Customer operations in healthcare technology is the end-to-end chain of work that runs after the sale: onboarding and go-live, implementation and interface mapping, support and escalations, eligibility and enrollment questions, claims and EDI rejections, renewals, and the customer success motion that keeps clinicians actually using the product. In a PE-backed healthtech company it is also where your net revenue retention lives or dies, which is why the operating partner usually owns this decision before anyone else does.

If you are the operating partner, you have seen this pattern across the portfolio: a healthtech company with strong logo growth and a customer ops function that scales linearly with headcount, eating the margin the thesis was built on. The CEO sees it as a board-metric problem (NRR, gross retention, CSAT). The COO sees a support queue that never empties and a go-live calendar that always slips. The CTO sees a stack of tools that nobody fully integrated. They are all looking at the same machine from different doors.

Here is the thesis this page will defend: in healthcare technology, customer operations does not break at the chatbot or the CRM. It breaks at the handoff between the part of the work that is automatable and the part that requires regulated, payer-specific, clinically aware judgment, and almost nobody owns that handoff.

Where does customer operations actually break in a healthtech portco?

Most customer ops work in healthtech is the same shape as everywhere else: a long manual chain, often 30 to 50 steps, that moves a request from intake to resolution. What makes healthcare different is the cost of a single wrong step and who is taking it.

Walk a real support escalation. A provider client emails about a batch of denied claims. A tier-one rep reads it, opens the ticket, pulls the patient and payer context, checks the 835 remittance, identifies whether it is an eligibility issue (270/271), a coding issue, a clearinghouse rejection, or a real product defect, classifies it, routes it, and drafts a response. Every one of those steps touches PHI. The rep doing it is frequently the most junior person in the building, and a single misclassification or an over-disclosure in a reply is not a slow ticket, it is a HIPAA exposure or a misrouted defect that festers into a churn conversation with a health system.

That is the operating reality that generic customer-service advice misses. In healthtech, the expensive failure mode is not response time. It is a junior person making a six-figure mistake on a checkbox: routing a clinical-safety issue to billing, pasting PHI into a tool that should never see it, or telling a client the eligibility file is fine when the payer changed a rule last Tuesday. The chain is long, the judgment is buried inside it, and the people running it are the cheapest you employ.

Go-live is the same pattern stretched over months. Interface mapping (HL7, FHIR), credentialing, payer enrollment, sandbox testing, and clinical workflow configuration are a long sequence of hands-on-keyboard steps punctuated by a few genuine judgment calls. When go-lives slip, it is almost never the judgment calls that slipped. It is the manual chain between them.

Why does the customer ops AI pilot keep stalling at "production"?

You have probably already run a pilot. A vendor demoed a support assistant or an auto-triage model, it looked great on curated tickets, and then it stalled the moment it had to touch real data. This is the classic AI-pilot death, and in healthcare it has a specific cause.

The pilot worked on sanitized examples. Production tickets carry PHI, payer-specific edge cases, and the institutional knowledge that lives in your senior reps' heads, not in your knowledge base. The model can draft a plausible answer. It cannot decide whether a disclosure meets minimum-necessary, whether this payer's rule changed, or whether a clinical issue needs to escalate now. Nobody owned that last mile, so the thing that shipped was a demo, not a function.

The tool was never the hard part. The tool is roughly five percent of the gap. The other ninety-five percent is the operating discipline: which steps move to agents, which steps stay with a senior human, how PHI is handled at every hop, and who is accountable when the chain produces a wrong answer. Pilots that skip that work stall every time, regardless of how good the model is.

There is a second, quieter failure mode: the internal build. You hire a sharp new customer ops leader. They spend a quarter mapping the mess, they restructure the team, they identify exactly what is broken, and then they leave before the fix actually ships. The diagnosis was right. The org just never carried it to production. If that has happened to you twice, the problem is not the people you hired.

What does good look like, and how do you sequence it?

Start by separating the chain into two piles, and be honest about which is which.

Pile one is the hands-on-keyboard work: intake, context gathering, classification, routing, EDI rejection lookups, status checks, draft responses, data entry across systems. This is most of the chain by volume and almost none of it by risk. It is where agents belong.

Pile two is the judgment: PHI disclosure decisions, clinical-safety escalations, payer-rule interpretation, renewal risk calls, anything where being wrong costs six figures or a relationship. This stays with named senior humans, and they get more time for it precisely because the agents cleared pile one.

The sequencing rule that matters: do not start with the customer-facing chatbot. Start with the internal chain that feeds your reps, because that is where the volume and the misroutes live, and because it never touches a patient directly while you are proving accuracy. We have seen this exact collapse work in adjacent operations. A PE-backed company's 50-step quote-to-cash process was collapsed onto an agent-run spine, removing 12,450 manual sourcing events a year. A PE-owned software platform moved classification data coverage from 53 percent to 81 percent on integration work. The healthtech version of that is ticket triage and EDI rejection classification, the same shape of problem.

What good looks like in numbers you can put on a board slide: misroute rate, first-contact resolution, go-live cycle time, and the share of escalations a senior person actually touched. If automation is working, that last number goes up, not down, because the experts are finally spending their time only on the calls that need them.

CFO's question: is this predictable, and where is the risk?

The honest risk in healthtech customer ops automation is not the model hallucinating a billing answer. It is PHI handling and the chance you spend a budget that looks like consulting and ends in another stalled pilot. So the only structure worth your time is one where the price is fixed, the scope is fixed, and the outcome is the named metric, not a pile of hours.

That predictability is an operating discipline, not a sales promise. A fixed price is only honest if every change runs in a live environment on a real copy of the data and replays every check before it ships. In a regulated environment that discipline is the point: you prove the agent handles PHI correctly and produces the right classification against real tickets before it ever touches a live customer. If the named metric does not ship, the work continues at no additional cost until it does. That is the line a CFO should hold any vendor to, including us.

How Salfati Group approaches this

We take customer operations as a Mandate: a fixed-price, fixed-scope, KPI-anchored business outcome with a named architect who owns it end to end. Agents do more than eighty percent of the work, your senior people keep the judgment calls, and you own the system that ships. The metric is something your board already tracks, like misroute rate or go-live cycle time, and it is backed by an Outcome SLA, so if we miss it we keep working at no additional cost until it lands. After it ships, a named architect stays on through the Vigilance Layer to maintain it and surface what is next.

If your customer ops scales with headcount and your last pilot died at production, start a Discovery conversation at /apply.

Reviewed by Elon Salfati·17 June 2026