RepOps Is a Category. Here's Why It Took This Long.
Every medical device company runs on RepOps. The function that gets the right rep, the right kit, and the right preference card into the right OR — every single day — is the engine of surgical sales.
And until now, it has never had its own software category.
Not because it didn’t matter. Because it was too specific for the categories that own software, and too operational for the people who own the field.
This is the post where we stake the claim: RepOps is a category. Here’s how it got buried, why now is the moment it surfaces, and what changes when it does.
What RepOps actually is
I spent years as a full-line ortho rep — total knee at 8am, revision hip in the afternoon, and two trauma add-ons that weren’t on the schedule when I left the house. The job wasn’t selling. The job was coordination.
Coordinating which kit was at which hospital. Which rep was covering which case. Whether SPD had the tray flipped in time. Whether the loaner was still on the truck or already in someone’s trunk. Whether the surgeon’s preference card had quietly changed since the last time we ran the procedure. Which group chat to check at 9pm so I wasn’t blindsided in the morning.
That work — the work between the surgeon’s office and the OR table — is RepOps.
It’s not the sales pipeline. It’s not the financial close. It’s the connective tissue between surgeons, reps, ops, and inventory that makes a case actually happen.
Every device company runs on it. Almost none of them have a system for it.
Why it never had a category
Software categories form when three things line up: a job that’s painful enough to pay for, a market big enough to fund a company, and builders who understand the job well enough to design for it.
RepOps had all three. It just had them in the wrong order.
The pain was always there. Anyone who has run an orthopedic territory, dispatched loaners on a Sunday night, or reconciled a case report against an ERP that doesn’t know which rep covered the case has felt it.
The market was always there. The U.S. medical device industry is enormous, and the field operations layer underneath it is the same shape across thousands of companies — manufacturers, distributors, and 1099 networks alike.
But the builders weren’t there. The people who lived inside the problem — reps, ops coordinators, regional managers — weren’t typically the ones writing software. And the people writing software didn’t understand the job well enough to know what was missing.
So adjacent categories absorbed the pieces.
- CRMs stuffed RepOps into “opportunities” — but a case isn’t an opportunity, and a surgeon isn’t a lead. Reps look at a Salesforce instance built for SaaS pipelines and bounce.
- ERPs stuffed RepOps into line items and inventory transactions — but an ERP can tell you a SKU was consumed; it can’t tell you which rep was in the OR, which case it served, or whether the kit got back to the warehouse afterward.
- Spreadsheets, notes apps, and group chats absorbed the rest. They’re flexible enough to model anything, which is why every ops team in the country is running their field operation out of them. They’re also lossy, untraceable, and quietly burning out the people who maintain them.
None of those tools are wrong. They’re just not the right tool for this.
The three layers RepOps actually requires
When you look at what a real RepOps system has to do, it splits into three layers that no single existing tool unifies:
Field execution. Reps, territories, coverage logic, surgeon ownership, and the communication layer that ties all of it to the case record. The thing that needs to be on a phone, in a hospital basement, with bad signal, and still work.
Inventory and chain of custody. Kits, consigned trays, loaners, trunk stock, and the chain-of-custody events that move them between warehouses, hospitals, and reps. With lot, serial, and UDI capture clean enough to satisfy an audit.
The case itself. A surgical calendar that knows the surgeon, the procedure, the OR, the assigned rep, the required kits, and the preference card snapshot at the time of the case. That moves a case through a real lifecycle: scheduled → confirmed → in progress → completed → billed.
Each layer is a real piece of software in its own right. The reason RepOps has never had a category is that none of them stand alone — and unifying them is the entire job.
The case is the spine. Everything else is an answer to “what does this case need, and is it on track?”
That’s why CRMs miss it (no inventory, no kits, no case lifecycle). That’s why ERPs miss it (no field workflow, no rep-facing app). And it’s why spreadsheets miss it (no integration, no real-time, no audit trail). The three layers are inseparable in the work, but the existing tools split them apart.
Why now
If RepOps is a category, why is it surfacing now and not ten years ago?
A few things have shifted at once.
Mid-market device companies are scaling faster than they can hire ops. Most of the growth in surgical sales is happening at the $5M–$500M tier. Those companies are big enough to feel the pain of fragmented operations and small enough that another five spreadsheets won’t fix it. They’re hiring fewer ops people and asking those people to do more. There is no path to that ratio without software.
PE roll-ups are forcing the issue. When a sponsor combines three small device companies into one platform, the operational reality is three different ERPs, three different rep networks, and three different sets of group chats. Trying to run the combined business on the existing patchwork is how revenue gets lost in the seam.
Reps live on phones. Their tools live on desktops. The default device of a rep in 2026 is an iPhone in a scrubs pocket. The default device of an enterprise software vendor is a desktop browser. Every field tool that doesn’t start mobile-first is dead before it ships.
Talent is leaving the big incumbents. Reps and ops leaders who spent a decade at the major manufacturers know what good looks like. When they move to a smaller manufacturer or distributor, they refuse to go back to running a region out of a shared Google Sheet. They’re the buyers of a real RepOps system because they already know it should exist.
Surgical case volumes keep climbing. Joint replacement and trauma volumes are growing. Ambulatory surgery centers are taking more of the case mix. Every additional case is another set of coordination handoffs. Without leverage, the ops team breaks before the rep team scales.
When pain, market, and builders line up at the same time, a category is born. RepOps is at that moment.
The bet we’re making
Naming a category is a wager. We’re betting that field operations in surgical sales — coordination, inventory, cases — deserves its own software, designed by people who have lived the problem, for the people still living it.
We’re not here to replace your ERP. We’re not here to compete with a CRM you may not even have. We’re here to fill the layer in the middle — the one every device company runs on and almost none of them have a system for.
If you’ve ever stood in a sterile core wondering whether the right kit was actually flipped, scrolled through six months of texts trying to figure out who covered a case in February, or watched a quarterly cycle count tell you the inventory is wrong but not where it went — you already know what we’re talking about.
That’s RepOps. It’s a category now.
See what a system built for the work actually looks like.
If you run surgical sales operations and any of the above sounds uncomfortably familiar, we’d like to show you Covalt.