This series is brought to you in partnership with Airspeed. They build AI that reads what customers actually say and writes it back into your CRM, which is a genuinely useful thing to have when you get to article four. But we're starting where most of us actually start: with nothing. Thanks to the Airspeed team for backing a series that spends three articles on the unglamorous part!
The Forecasting Series:
There's a spreadsheet. It lives on the VP of Sales' laptop. It gets rebuilt every Monday morning before the leadership meeting, it has a tab nobody else has ever seen, and it disagrees with the CRM by seven figures.
If you've been in ops for more than a few years, you've met this spreadsheet. Maybe you've been handed it. Maybe you've been asked to "just make the CRM match."
Here's the thing about that spreadsheet, and I want to be fair to the person maintaining it: the board and your CEO don’t really care that your VP of Sales manages the forecast in a spreadsheet. A sales exec who calls the number correctly, quarter after quarter, can run their pipeline reviews on cocktail napkins and nobody upstairs will say a word. It drives revenue operations absolutely insane, but it's true.
What the board cares about is whether the VP of Sales can read the signals correctly. Predict too high and get surprised at quarter close? You can't coach and you can't read a deal. Come in consistently low? You're a sandbagger, taking the pressure off yourself while sitting on deals you knew were live. Call it right more often than not, and you've bought yourself an enormous amount of latitude.
The reason why a system is always better than a spreadsheet is what happens on the day the number is wrong. Because it will be wrong eventually. And when it is, the board doesn't want the story. They want the pipeline, from the system, with history. They want to see close date pushes and stage movement and when the amount changed.
If your entire methodology is living on a laptop, you can’t produce a detailed report, and the roast that follows is not about forecasting. It's about credibility.
Treating your pipeline like it requires cloak-and-dagger clearance is the fastest way to lose the trust of a board. It also creates a slow, grinding friction with the rest of the leadership team, who would very much like to log into the CRM on a Tuesday afternoon and figure out what's happening without scheduling a meeting to ask.
So getting everything into the system isn't a RevOps hygiene mandate. It's the difference between spotting product-market fit signals while they're still actionable and finding out about them in an exit interview. It's the difference between a sustainable career as a sales leader and a short one.
That's why RevOps should care. Now let's build the thing 💪
Ask a leadership team if they forecast and almost all of them will say yes. Ask three follow-up questions and watch it fall apart.
You do not have a forecast if:
A forecast without rigor is a pipe dream with a spreadsheet attached to it. And I'll be honest with you about the hardest version of this problem: I've worked at companies where leadership had no interest in forecasting at all. Not hostility. Just indifference. That is nearly impossible to fight from an ops seat. I want to save you some heartache by telling you to focus where they appreciate the effort and save yourself some burnout.
What actually changes it is pressure from the CEO or the board, and that pressure only shows up when the team isn't performing. Which means if your numbers are good, you may be waiting a while. Plan accordingly, and don't burn your political capital pushing a rock uphill.
In the meantime, you have two scenarios and they call for different plays.
Scenario one: there's no sales leadership filling the gap. Then RevOps steps into the role. Not permanently, and not with a title, but somebody has to start instituting a process around pipeline qualification and put cadences on the calendar for pipeline and forecast review. If you're waiting for someone to ask you to do this, you'll wait forever. Start small, publish something consistently, and let the habit build its own case.
Scenario two: you have a sales manager who genuinely wants to forecast but walked into an org with no system. This is the good version. Now you get to compromise and build something together. Your job in that conversation is to advocate relentlessly for simplicity. They will want more. It’s easy for RevOps to build even more than that. Strive for something as simple as possible while still getting the business the data they need.
This is the single most common reason a rollup is garbage, and it's worth slowing down on, because a lot of people have been using these two terms interchangeably for years without anyone correcting them.
Pipeline stages reflect where the deal is in the sales cycle today. They're detailed, and their definitions are tied to real, observable actions and signals. Qualified means a qualification effort actually happened and somebody confirmed budget, authority, need, and a timeline. That's BANT, the most simplistic version available. Maybe your org runs MEDDPICC, or SPICED, or something a consultant sold you in 2019. The framework matters less than whether the stage definition points at something a human did.
Forecast categories reflect where the rep believes the deal will be at the end of the quarter. That's a prediction, not an observation. It's the rep's read on the future.
At the beginning of the quarter, those two things can look wildly different, and that's correct. An auto-renewal sitting at stage 1 that expires at the end of the month absolutely belongs in commit, assuming somebody has actually had a conversation with the customer. Low stage, high confidence. That's not a data problem, that's just how renewals work.
By the end of the quarter, though, they should converge. Stage and category should tell the same story.
Catching that is the manager's job. Thorough pipeline reviews, actually looking at logged activity, and verifying the deal sits in the right stage. If you don't have a manager doing that, congratulations, it's your job now. See scenario one above.
Keep it to four. Every category you add is another conversation you'll have to referee. What I generally propose is:
Those percentages are guardrails, not math. Nobody should be calculating a weighted forecast off them and presenting it to the board. What they do is give you shared language, which is the entire point. When a rep says commit and a manager says best case, you now have a specific thing to argue about instead of a vibe.
One rule worth defending: the category is a judgment call, and judgment calls need a reason. If a deal moves from best case to commit, something changes. Somebody should be able to say what.
Every time a new Sales VP walks in the door, they want to put their stamp on pipeline stages and forecast categories. Every time. Set your watch on it.
And the preferences vary enormously. Some want their sellers to choose the forecast category. Some want to own it themselves and treat the rep's input as advisory. Some want to micromanage as little as humanly possible. Some want an alert every time a deal over a certain amount so much as twitches.
Our job is to support the way they want to run their team without turning the system into a monument. That means asking before you build, and it means pushing back when what they're asking for is going to collapse under its own weight.
I've had a Sales VP ask me for four closed-lost types with fifteen loss reasons under each. Sixty options. I've always seen it as my job to push back on that, and not because I'm precious about picklists. Push back with questions, not opposition:
That last question is newer than the other two, and it changes the calculus more than people have adjusted for. A lot of what we've historically demanded from reps in the CRM exists because there was no other way to capture it. That's less true every quarter. Hold onto that thought; it's most of article four.
Here's the part that actually matters, though. If you build something your sales management team doesn't like, you have handed them a permanent, unassailable excuse to never use it. "It doesn't work the way I need it to" ends every adoption conversation you will ever have.
So get alignment before you build. Not after. The rebuilding is expensive and the begging for people to try again after you “fix” something is worse.
And extend some grace here. A lot of sales managers are fiercely protective of their teams because they know how brutal the job is. They will not tolerate a badly configured system that makes their reps' lives harder without giving them anything back. That's not obstruction. That's a manager doing their job.
You can build the most elegant forecast architecture anyone has ever seen and it will rot in ninety days if nobody is accountable for the number.
Think about what actually drives behavior here:
There are CROs who want a forecast but not accountability. And you will meet that person. They want the dashboard. They want visibility. They do not want their own accuracy tracked over time, and they will find a lot of thoughtful reasons why now isn't the right moment for that.
You cannot fix this with better training or a slicker interface. What you can do is make it visible. Start tracking forecast accuracy quietly, by rep and by manager, from day one. Don't publish it yet; we'll get to that in article three. Just start collecting it. The day somebody upstairs finally asks about it, you want to be the person who already has the answer.
Version one is not sophisticated. Version one is stages that map to your actual qualification process and the major signals in your deal cycle. Here's the structure I keep coming back to:
Seven active stages, numbered so they sort correctly and so people can say "it's a three" in a meeting without ambiguity.
Notice how much of the definition points at something that either happened or didn't. A meeting occurred. A proposal went out. A contract was sent. Those are verifiable. The moment a stage definition depends on how a rep feels about a deal, you've built a forecast category and mislabeled it.
Then you can set forecast categories to automatically update with stage changes with the option for people to overwrite them. Or use your forecasting tool in your CRM, which will have similar override functionality and usually requires you to map stages to forecast categories.
You now have stages, categories, executive alignment, and a reason to believe anybody can and will use it. That's version one, and version one is genuinely an accomplishment. Some orgs never get here.
But a forecast isn't a build. It's a habit, and habits are built by repetition under load. The structure you just created has to survive contact with a weekly meeting, a quarter-close panic, and a rep who has committed the same deal three periods running.
Next up in this article series is the cadence, sales methodology, and the question that starts more fights in this community than any other, which is whether RevOps facilitates the forecast call or owns it.
Your turn. What did your version one look like, and what did you have to rip out six months later? Drop it in the community. The graveyard of over-engineered picklists is one of our great shared traditions.
