Revenue operations, usually shortened to RevOps, is the function that connects the parts of a company's revenue engine that normally run separately: demand generation, the CRM, follow-up, the handoff from sales into delivery, and reporting. It is not a tool, and it is not a job title you have to fill. It is the layer that decides what happens, when, who owns it, and how information moves between each part.
In a large company, RevOps is a department. In a founder-led service business, it is usually a set of decisions nobody has made yet. That is why revenue ends up depending on the founder remembering things.
The five parts revenue operations connects
Each part usually functions on its own. The failures happen at the joins, which is the whole reason the function exists.
| Part | What breaks at the join | What it looks like connected |
|---|---|---|
| Demand | Leads arrive by form, inbox, referral, and phone, and only some of them reach the CRM | Every lead lands in one place with its source attached |
| CRM | Stages describe what a deal is called rather than what has to happen next | Each stage has an exit condition, so the record reflects reality |
| Follow-up | Whether a lead gets chased depends on who happened to see it | The sequence fires on lead type and stage, not on memory |
| Sales to delivery | The week after signing is improvised, and the client feels it | A defined handoff with an owner, a checklist, and a start date |
| Reporting | Numbers get rebuilt by hand and then argued about | A few numbers everyone trusts, read on a fixed schedule |
Demand
Leads arrive by form, inbox, referral, and phone, and only some of them reach the CRM
Every lead lands in one place with its source attached
CRM
Stages describe what a deal is called rather than what has to happen next
Each stage has an exit condition, so the record reflects reality
Follow-up
Whether a lead gets chased depends on who happened to see it
The sequence fires on lead type and stage, not on memory
Sales to delivery
The week after signing is improvised, and the client feels it
A defined handoff with an owner, a checklist, and a start date
Reporting
Numbers get rebuilt by hand and then argued about
A few numbers everyone trusts, read on a fixed schedule
What a revenue operations consultant actually does
Four kinds of work, roughly in this order.
- Diagnoses. Interviews everyone who touches a deal, traces a live opportunity from first contact to invoice, and reads the data rather than the org chart. The goal is to find where the motion breaks, which is rarely where it is reported to break.
- Designs. Decides what the process should be, where ownership sits, and which numbers the business will run on. This is judgment work and the hardest part to outsource well. It is also the actual reason to hire someone.
- Builds. Configures the CRM, the automations, the templates, and the reporting, then tests them against real deals rather than a demo record.
- Hands over. Documentation, training, and a support window while habits form. Skip this and the build reverts to the old behavior within a quarter.
Notice how little of that is software configuration. Someone who opens with a platform recommendation is solving the last problem first.
What revenue operations is not
- Not CRM administration. An admin keeps the system running. RevOps decides what the system should do in the first place.
- Not sales management. A manager works the pipeline. RevOps designs the pipeline they work.
- Not marketing automation. Sequences are one component of one part of the motion.
- Not a dashboard. Reporting is an output of the function, not the function. A dashboard built on data nobody maintains is a faster way to be wrong.
RevOps in a founder-led business
Most published RevOps advice is written for software companies with a marketing team, a customer success team, and a few hundred employees. Territory design, quota modeling, and compensation architecture are real parts of that job and almost entirely irrelevant below 20 people. Translate before you apply any of it.
The founder-led version answers three questions. What happens to a lead the moment it arrives? What has to be true before a deal moves forward? What does the team look at, and how often? Answer those three in writing and enforce them in the system, and most of the chaos goes away.
What you end up with is a sales operating system. The relationship is simple: revenue operations is the practice, and the sales operating system is the thing it produces.
When a business needs it
The signs are consistent across businesses of this size.
- You do not trust the pipeline number well enough to make a hiring decision on it.
- Follow-up happens when the founder chases it and stalls when the founder is busy.
- You cannot say where your last 10 clients came from without reconstructing it from memory.
- Delivery finds out about new work when the client emails them.
- A new salesperson would need months of shadowing, because the process is not written down anywhere.
One caveat. If the honest problem is that not enough people are asking to buy, this is not your constraint yet. Spend the money on demand instead, and be sure which problem you have before you spend anything.
Where to start
The cheapest first move costs nothing but 90 minutes: run the audit on your own business and see how many of the joins above are actually holding. If the gaps are wider than you can close between client work, that is the point at which outside help earns its fee.
For the next decision, use revenue operations vs sales operations. The comparison separates sales-team workflow from the wider data and handoffs across marketing, sales, and delivery.