How to build a sales process without RevOps

Building a sales process without RevOps means making the decisions a revenue operations function would normally make by hand, then writing them down, rather than buying a system that makes them automatically. Those decisions are usually invisible until they are missing, which is why an undefined process looks identical to a working one until a deal gets stuck and nobody can say why.

What is a sales process, and how is it different from a CRM?

A sales process is the agreed sequence of stages a deal passes through, with a written rule for what has to be true before it moves to the next one. Owning a CRM is not the same as having one. A deal board with column headings and no stage rules is a filing cabinet that produces a total. The full mechanics of choosing a stage count and writing exit criteria two people read the same way are covered in how to build a sales process; what changes here is who does that deciding, and how, when nobody holds the role that would normally own it.

A deal has sat in "proposal" for six weeks. The rep says it is still live, the forecast says it closes this month, and nothing written down anywhere says which of them is right, because nobody ever defined what proposal means or how long a deal is supposed to hold there. Those decisions do not go away when nobody is titled to make them; they just stop getting made.

What does RevOps actually do, and what happens when nobody does it?

Revenue operations is a function inside a company, and in the companies large enough to staff it, RevOps owns the definitions and the reporting sitting underneath sales, marketing and customer success: what a stage means, what gets recorded on a deal, where a lead goes next, and what the numbers are allowed to say. The confusion for a smaller team is that RevOps is usually described as an analytics role. At this size, most of the work that matters is deciding something and writing it down where the team can find it.

What is the difference between RevOps and sales ops?

Sales operations serves one team. Revenue operations serves the whole revenue line, which is why the shared definitions matter more: a lead handed from marketing to sales has to mean the same thing on both sides of the handover, or the two functions report different numbers for the same month and both are technically correct.

In a company running one sales team and one marketer, that distinction collapses. The practical question stops being which function to build and becomes which jobs are currently going undone.

Which RevOps jobs still need doing in a team without one?

Five jobs survive the absence of the function. They are the parts of RevOps that are decisions rather than analysis, and a decision does not stop being needed because there is nobody titled to make it. Call them the five unowned jobs.

1. Definitions decide what each stage means and what has to be true before a deal is allowed to leave it. Without an owner, two people describe the same deal differently, and the pipeline total stops meaning anything.
2. Capture governs what gets written on a deal, by whom, and at what point in the process. When nobody owns it, half of the lost deals carry no reason, so nothing can be learned from them afterwards.
3. Routing is the rule for who picks up an inbound lead and within what window, plus what happens if nobody does. Left unowned, enquiries sit untouched over a weekend, and nobody notices until the following week.
4. Measurement sets which numbers get produced, how often, and from which source they are pulled. The symptom of neglect is familiar: three people quoting three different conversion rates in the same meeting.
5. Review decides who revisits the rules once they stop working, and on what schedule. Without a review owner, the stage names and scoring rules still date from the day the CRM was first implemented.

None of the five is a full-time job at this size, and none of them requires new software. Together they add up to a small weekly commitment, most of it landing in the fortnight the rules are first written.

What breaks first when those jobs go unowned?

Definitions break first, and the failure is quiet. Nothing errors, no report goes red, and the pipeline keeps producing a number that everybody continues to treat as meaningful.

The order after that is fairly consistent:

• Capture goes next, because a rep with no stated reason to fill a field will not fill it, and a closed-lost reason is the field that suffers most
• Measurement follows automatically, since a conversion rate computed over undefined stages and missing fields is arithmetic on noise
• Routing degrades slowly, usually surviving on the memory of whoever handled the last one
• Review never starts at all, because reviewing a process requires a written process to compare against

Every one of those is downstream of the first. A team that fixes only the definitions gets most of the value, which is why the definitions are where the work starts.

How is a sales process built without RevOps?

Building a sales process without RevOps is mostly an afternoon of decisions and one page of writing. The tempting version is a project: a workshop, a template from a CRM vendor, and a document still in draft four months later. What ships instead is shorter, and it gets edited the first time it meets a real deal.

Who writes the exit criteria, and how long does it take?

The person carrying the number writes the first version alone, in one sitting, on one page. Committee drafting is how this becomes a quarter-long project, and there is no ops function here to run that committee even if the team wanted one.

The team then edits it once, against real deals rather than in the abstract. Pull the last ten open deals, place each one in a stage using only the written criteria, and note every deal that two people place differently. Those disagreements are the rewrite list, and there are usually three or four.

Write the qualification criteria from deals that already closed, not from what the team assumes a good lead looks like. Pull the last twenty closed deals, wins and losses both, and note what the wins had in common that the losses did not. The losses matter as much as the wins: a trait shared by every customer and also by every account that said no predicts nothing. The method is in how to build an ICP scorecard from closed-won deals.

Who owns the CRM, and what has to be recorded on a deal?

One named person owns the CRM. Not "the sales team", not "whoever set it up", and not a rotating responsibility, because a system owned by everybody is maintained by nobody. In a small team that person is usually the founder or the first sales hire, and the commitment is a light weekly check plus the quarterly review.

Ownership means three specific rights: deciding what fields exist, deciding what is required, and deciding when a rule changes. It does not mean doing the data entry.

What belongs on every deal record?

A short list, and short is the point. Each field below exists because a named person reads it for a named decision:

• Stage, matching the written criteria
• Value, at whatever precision is honest, revised rather than hopeful
• The named person who can approve the spend, which is a different field from the main contact
• Next step, with a date, since a deal with no dated next step is not a deal in progress
• Source, recorded once at creation
• Closed-lost reason, chosen from a fixed list of six or seven options

The loss reason has to be a picklist. Free text cannot be counted, and a loss reason that cannot be counted is a note nobody will ever read again.

What should never be a required field?

Anything a rep cannot answer at the moment they are asked, and anything with no named reader. A field required despite failing either test trains the team to type whatever passes validation, and that habit corrupts every number downstream of it.

The rule that holds up: each required field names the person who reads it and the decision it changes. A field failing that test is made optional or deleted. Deleted is usually correct, because an optional field that nobody fills is still clutter on the form the team sees every day.

How does the record stay accurate without an admin?

The record is updated at the point of the event. A call ending at 3pm gets its next step and its stage set before 3:15, while the detail is still recallable.

Weekly hygiene sweeps are what a team does after the capture rule has already failed. They work briefly, they depend entirely on somebody remembering to run them, and they produce reconstructed data rather than recorded data. A deal remembered on Friday tends to read warmer than the same deal would have read on Tuesday, because reconstruction pulls in a few days of hindsight the original record never had.

Join the MeetIQ waitlist →

What should a team measure without an analyst?

Three numbers, produced from the CRM's own reporting, with no spreadsheet export and no analyst. More than three and the reporting becomes a job somebody has to be assigned, which is exactly the constraint being worked around.

Which three numbers are worth the effort?

• Stage-to-stage conversion. What proportion of deals entering each stage leave it forwards. This says where the process leaks, and the leak is almost never where instinct puts it.
• Time in stage. How long deals sit before moving. This says which deals are dead without having admitted it.
• Closed-lost reason distribution. Which reason grew this quarter. This says whether the leak is a targeting problem, a price problem or a product problem, and those three have completely different fixes.

Conversion alone is the trap. A stage that converts almost everything while holding each deal for three months is a waiting room the rep eventually chases deals out of, and on a conversion report it will read as the healthiest column on the board.

How is a stalled deal spotted before it dies?

By writing an expected duration for each stage at the same time as the exit criteria, then saving one view that lists every deal past it. The expected duration is a first guess and it will be wrong. That does not matter, because the first quarter of real data corrects it, and a wrong threshold still surfaces the deal that has been in negotiation since March.

A written threshold beats somebody's sense of how long is too long, which drifts with how busy the quarter has been. Anything past it gets one of three decisions at the weekly meeting: a specific action with a date, a stage change backwards, or closed lost with a reason. Leaving it untouched is not one of the three.

Pipeline stages built for forecasting do not say which account to work today

The standard pipeline template exists to roll a forecast up to somebody who asks for one. That is a real job in a company with a board meeting, a revenue plan and a finance function comparing this quarter to the last four.

A team of three or four quota carriers rarely has that requirement, and the process inherited from the template answers a question nobody is asking while leaving the daily one open. The daily question is which of the accounts in the pipeline, plus the ones showing interest and not yet in it, deserve the hours available this week.

Writing the process and following it are two different jobs, and the second one is where it breaks. In a team this size the person who wrote the stage criteria is also carrying a number, and the first deal they push forward without meeting the criteria is the one that teaches everybody else the criteria are optional. Someone has to check the stages at the weekly review, out loud, including on the founder's own deals.

What changes when the process is built backwards from that question?

Two things change, and the first is a simplification. Stages start earning their place by changing what somebody does that day, which merges the administrative ones out of existence: "proposal sent" becomes part of whichever stage carries the follow up. The board gets shorter, and each remaining column implies a different action, which is the only reason a column should exist.

The second change is an addition. A forecast-shaped process orders deals by stage and age, both of which describe what the selling team did. Neither describes what the buyer is doing right now, and a deal that has been in negotiation for five weeks looks identical on the board whether the buyer went quiet in week one or opened the contract twice yesterday.

Where does the prioritisation input come from?

From systems the team already runs, each holding a different part of the picture:

• The website, which shows what a buyer is reading and how often, including people at the account who never filled in a form
• The calendar, which shows meetings booked, rescheduled, and quietly cancelled without a rebooking
• The shared inbox, which shows reply latency and who else got copied in partway through
• Call recordings, which hold the objection that actually stalled the deal, usually in a sentence nobody wrote down afterwards
• The CRM's own activity log, which already holds fragments of all of the above and surfaces none of them on the deal board

Which of those are worth watching, and which are noise dressed as urgency, is a longer subject: the taxonomy and the directional weights are in the working guide to B2B buyer intent signals, and the shortlist of the ones that most reliably precede a purchase is in five B2B buyer intent signals that predict purchase readiness. The point for a process is narrower. A stage board ordered by age answers "what did the team do", and a team without RevOps has to source the answer to "what is the buyer doing" somewhere else, because no analyst is going to assemble it on request.

Where does a founder-run process break?

The failure modes are consistent, and none of them is a failure of the document itself. Each is a failure of enforcement, which is why writing a better process never fixes them.

What goes wrong most often?

• Written once and never enforced. The document exists, the team reverts to habit within a month, and the pipeline goes back to meaning whatever each rep intends by it.
• Copied from a template and never fitted. The stage names came from the CRM's default pipeline, so they describe how a vendor imagines a deal moves rather than how this business actually sells.
• Stages added to describe exceptions. One unusual deal produces a new stage, four of those produce a board nobody can hold in their head, and the process is now a taxonomy of edge cases.
• Fields required for a report nobody reads. Reporting requirements accumulate and never get deleted, so the form grows and the data quality falls.
• The owner exempting their own deals. A founder who overrides the process on the deals they personally run has taught the team the process is optional, and no amount of restating it undoes that.

The last one is the most common and the least discussed, because the person best placed to notice it is the person doing it. It is also the cheapest to correct: run the founder's own deals through the same board, visibly, in front of the team.

Who reviews the process, and how often?

Once a quarter, thirty minutes, the same person who owns the CRM. Three questions go into the calendar invite so the meeting cannot drift: which stage has the worst conversion, which stage holds deals longest, and which loss reason grew. Anything that has not changed a decision in two consecutive quarters gets deleted, including fields, stages and the review itself if nothing ever comes of it.

Quarterly is the honest cadence. Monthly reviews of a process that changes twice a year produce meetings about nothing, and annual reviews arrive after a broken definition has already contaminated four quarters of reporting.

What to build in the first week

Five things, in order, none of which requires anybody new:

1. Write the stages on one page, with an observable exit criterion for each, drafted by one person in one sitting.
2. Name the CRM owner in writing, in whatever the team actually reads, and state the three rights that ownership carries.
3. Cut the required fields to the ones with a named reader, and replace the free-text loss reason with a picklist of six or seven.
4. Set an expected duration per stage and save the view that lists every deal past it.
5. Put the quarterly review in the calendar with the three questions in the invite body.

Then test the page against the last ten open deals and rewrite whatever two people read differently. That test takes an hour and finds the three or four definitions that would otherwise have quietly produced a year of unusable numbers.

All of it comes down to somebody deciding what a stage means and writing it where the rest of the team can read it. That takes an afternoon, and it gets deferred for years, because nothing breaks loudly on the day it is skipped.

The pipeline total is only ever as honest as the definition underneath it. A team that has written that definition down can say whether a six-week proposal is live or dead. Without it, both answers are guesses, and the total on the board inherits both.