For sales leaders, operations managers, and anyone being asked to build or fix a sales ops function. Written for people who have to make decisions about it, not for people studying the org chart.
Sales operations is the business function that makes a sales team more efficient by owning its processes, its data, and its technology, so that reps spend more of their time actually selling. In practice that means four planning disciplines (territory, capacity, quota, and compensation), the administration of the CRM and the wider sales stack, and the reporting that turns pipeline activity into forecasts leaders can act on. The stated goal is always the same: give selling time back to the people who sell. That goal is worth taking literally, because the numbers behind it reveal a gap that most descriptions of sales ops never address.
Key takeaways
- Sales operations owns the processes, data, and technology behind a sales team, with one explicit aim: increase the share of a rep's time spent selling. That gives you a test for any initiative, namely whether it returns time to sellers or consumes it.
- The discipline was invented at Xerox in the 1970s by J. Patrick Kelly, who described it as the number work nobody wants but every strong sales force needs.
- The remit consolidates into four areas: strategic planning (territory, capacity, quota, compensation), the sales stack, data and forecasting, and process design. Hire one generalist first, not an analyst, or you get excellent reporting on a process nobody has defined.
- Salesforce reports that the average rep spends about one third of their time selling. Part of the other two thirds is CRM admin, which sales ops already targets. The rest is client-facing document production, which almost never reaches the roadmap.
- Sales operations, RevOps, sales enablement, and deal desk are four functions with four different units of work: the sales process, the whole revenue funnel, the individual rep, and one live deal.
- Measure five things: selling time as a share of total time, forecast accuracy, cycle length, revenue per rep, and win rate. Treat a single quarter as noise, and be honest about attribution.
What is sales operations?
Sales operations, often shortened to sales ops, is the function responsible for the systems a sales team runs on. It does not carry a quota and it does not talk to customers. It designs and maintains the conditions under which the people who do carry a quota can hit it: how territories are drawn, how many reps are needed, what they are paid for, which tools they use, and what the numbers say about whether any of it is working.
The useful way to think about it is by unit of work. A sales manager owns people. A rep owns deals. Sales operations owns the machine both of them run inside, and it is measured on whether that machine gets faster and more predictable over time.
Where the discipline came from
Sales operations was invented at Xerox in the 1970s by J. Patrick Kelly, who described the job as all the unglamorous number work that nobody wants to do but that a great sales force cannot do without. That origin, reported in the Harvard Business Review in December 2014, still explains the shape of the function fifty years later. It was created to absorb the administrative and analytical load that was pulling sellers away from selling, and every subsequent expansion of the remit has followed the same logic.
That history matters for a practical reason. It tells you what the function is for, which gives you a test for whether any given sales ops initiative is worth doing: does it return time to the people who sell, or does it consume it?
What does a sales operations team actually do?
The remit varies by company, but it consolidates into four areas.
Strategic planning. This is the part that recurs on an annual cycle and it breaks into four buckets: territory planning (which reps cover what), capacity planning (how many reps are needed to hit the number), quota planning (what each of them is expected to deliver), and compensation planning (what behaviour the pay structure actually rewards). Get compensation planning wrong and no amount of process work will fix the resulting behaviour.
Compensation deserves a note of its own, because it is where sales ops absorbs the most friction for the least visible credit. Beyond designing the plan, the function usually ends up calculating commission, arbitrating the disputes that follow, and explaining to a rep why a deal that closed on the last day of the quarter landed in the next one. That work is unglamorous and consumes real capacity, and it is the reason compensation is often the first thing a growing team tries to automate.
Technology and the sales stack. Sales ops owns the CRM as the single source of truth, plus whatever sits around it: forecasting tools, dashboards, automation, conversation intelligence, enablement platforms. Ownership here means more than administration. It means deciding what enters the stack, what leaves it, and whether adoption is real or theoretical.
Data, reporting, and forecasting. Sales ops turns activity into a forecast leaders can commit to, and turns outcomes into a diagnosis. This is where most of the credibility of the function is won or lost, because a forecast that is wrong twice in a row costs more trust than a year of good process work earns.
Process design. Documenting the sales process, defining stage exit criteria, setting handoff points with marketing and customer success, and identifying which behaviours of high performers can be turned into standard practice for everyone else.
Sales operations roles and job titles
Sales ops teams range from one generalist to several dozen specialists. The common progression looks like this:
- Sales operations representative or coordinator. Entry level. Data hygiene, report updates, tracking against goals, administrative support to reps.
- Sales operations analyst. Reporting, dashboards, pipeline analysis, and the recommendations that come out of them.
- Sales operations manager. Turns strategy into day to day process, owns tooling decisions, defines and enforces best practice.
- Director or VP of sales operations. Owns the planning cycle, partners with the CRO, and decides how the function scales.
If you are building the function from nothing, the sequence that works is to hire one generalist who can handle process and technology, then specialise as volume forces it. Hiring an analyst first is a common error: you get excellent reporting on a process nobody has defined yet.
Sales operations vs RevOps vs sales enablement vs deal desk
These four are used interchangeably in job ads and they are not the same thing. Separating them by unit of work is the cleanest way to keep them straight.
The pairing that causes the most confusion is sales operations and RevOps. RevOps is not a rebrand of sales ops. It is a wider remit that absorbs marketing operations and customer success operations alongside it. Plenty of companies run RevOps as a title while doing sales ops work, which is fine as long as everyone knows that is what is happening.
The two thirds problem: what non selling time is actually made of
Every definition of sales operations rests on the same promise: give reps more time to sell. Salesforce puts a number on the starting point, reporting in its State of Sales research that the average sales rep spends about one third of their time selling. The entire justification for the function sits in the other two thirds.
So it is worth asking what that two thirds is made of. Some of it is exactly what sales ops already targets: CRM data entry, internal reporting, pipeline reviews, chasing approvals, administrative overhead. Automation and better tooling genuinely reduce that load, and it is the part of the problem the discipline has been attacking for fifty years.
The rest of it is document production. Building the proposal. Rewriting last quarter's deck for a different client. Assembling the response to a formal solicitation. Pulling the pricing together into something presentable. Reformatting a technical summary so it matches the brand. This work is client facing, it directly determines whether the deal is won, and it is almost never on the sales ops roadmap.
Read the standard explainers on sales operations and the pattern is hard to miss. Data, CRM and pipeline are everywhere. The document, the proposal, the RFP, the template, the deliverable, the statement of work: close to absent.
That imbalance is the finding, and it is not a gotcha about vocabulary. It reflects a real division of labour. Sales operations was built to own systems of record, and a proposal is not a system of record. So the CRM gets a full time owner and a budget line, while the documents that decide the outcome of the deal get produced by whoever is free, from whatever version they can find, at whatever hour the deadline demands.
The consequence shows up in quality variance rather than in the dashboard. Two reps with the same quota, the same territory, and the same CRM will send client facing documents of visibly different quality, and nothing in the standard sales ops toolkit detects that or fixes it.
There is a structural reason the gap persists. Document production crosses more stakeholders than almost anything else sales ops touches: the rep owns the client relationship, marketing owns the brand and the approved messaging, product or engineering owns the technical accuracy, legal owns the commitments, and finance owns the numbers. No single one of them owns the finished artefact. Ownership that is split five ways is ownership nobody has, which is precisely the kind of alignment problem sales operations was created to solve everywhere else in the funnel.
Treated as a workflow rather than as a writing task, the problem becomes tractable in the same way territory design did. You can define what a good version looks like, build it once from an approved source, and let people adapt rather than start over. The efficiency gain comes from removing the blank page, not from asking anyone to write faster.
What this looks like when it is owned
Teams that treat document production as a process rather than a personal skill get measurable results from it. At Open, an IT services group, Engagement Executive Thierry Wawrzyniak reports that building a proposal from scratch used to take two to three hours, and that the team now gets a framework version in about five minutes, leaving the remaining time for adaptation to the client. Open puts the overall reduction in response time at 50 percent.
The point is not the tool. The point is that this was measurable, repeatable, and therefore an operations problem all along. It was simply sitting outside the function's remit. Cobl exists for that layer specifically, and the pricing page sets out where it starts.
How to measure sales operations
Sales ops is a support function, which makes attribution hard and vanity metrics tempting. Five measures carry most of the signal:
- Selling time as a share of total time. The founding metric of the discipline. If it is not moving, nothing else you report matters much.
- Forecast accuracy. The percentage gap between predicted and actual revenue, tracked over several quarters rather than one.
- Average sales cycle length. Cycle time is the cleanest read on whether process changes actually removed friction.
- Revenue per rep. Total revenue divided by headcount, which exposes whether growth is coming from productivity or just from hiring.
- Win rate. Closed won deals over total opportunities. Slow to move and easy to misread quarter to quarter, but the number that ultimately validates the rest.
Two cautions. First, treat any single quarter as noise. Second, be honest about attribution: a rising win rate after a territory redesign might be the redesign, or it might be a competitor stumbling. Sales ops earns credibility by being careful about that distinction, not by claiming every improvement.
How to build a sales operations function
- Write down the sales process you actually run. Not the one on the slide. Stage definitions, exit criteria, and who does what at each handoff.
- Fix the data before the dashboards. Reporting on unreliable CRM data produces confident wrong answers, which are worse than no answers.
- Hire a generalist first. Someone who can handle process and tooling. Specialise later, when volume makes the case.
- Take one thing off the reps' plate in the first ninety days. Something visible. Credibility with the sales floor is the constraint on everything you do afterwards.
- Inventory the client facing documents. List every artefact a deal produces, then mark which come from a reusable source and which are rebuilt manually each time. This is usually the step that gets skipped, and it is where a large share of the non selling hours are hiding. It is also the step that tells you whether a tool like Cobl would pay for itself, because the answer is simply the count in the second column.
- Instrument, then change. Establish a baseline on selling time and cycle length before you start redesigning, or you will never be able to prove the redesign worked.
What breaks a sales operations function
Three failure modes account for most of the sales ops teams that quietly stop mattering.
It becomes a reporting desk. The function drifts into producing whatever dashboard leadership asked for last, loses the process mandate, and ends up as an analytics service with no authority to change anything it measures. The tell is that nobody consults sales ops before a decision, only afterwards to quantify it.
It optimises the wrong end. Enormous effort goes into forecast precision while the reps are still spending their evenings rebuilding decks. Precision on a number is easier to demonstrate than time returned to sellers, so it attracts the effort, and the founding purpose of the function gets quietly abandoned.
It loses the sales floor. Process is imposed without adoption, reps route around it, CRM data degrades, and the reporting built on that data becomes fiction. Recovering from this is slow, which is why the ninety day rule above matters more than it looks: the first thing sales ops does should visibly help the people it needs to cooperate later.
On complex, multi stakeholder deals the document load is heavy enough that a separate function usually forms around it, which is where sales ops starts overlapping with the pre-sales role, process, and tools. Knowing where that boundary sits saves a great deal of duplicated work.
