Your Forecast Is Wrong Because Nobody Configured A Pipeline | Zoho CRM Stage Probability

Every quarter somebody asks why the forecast was wrong, and the conversation goes to the sales team. Coverage, discipline, sandbagging, optimism.

Sometimes that's the answer. Often it isn't. Often the forecast is wrong because it's doing arithmetic on numbers nobody in your company ever chose.

Everything on screen is a mock demo of Zoho CRM with sample data.

Let me show you where those numbers come from.

Here's a pipeline. Ten deals, each sitting in a stage. Qualification, Needs Analysis, Value Proposition, Proposal, Negotiation.

Those stage names came with the product. They're Zoho's defaults, and they describe a generic enterprise sales motion that may or may not resemble how you actually sell.

That would be a cosmetic problem, except for one thing: each of those stages carries a probability. And the forecast multiplies the deal value by that probability. So the stage isn't a label. It's a coefficient.

So where do those numbers come from. Setup, Customization, Modules and Fields, Deals — then the Stage field, and one item down its own menu: Stage-Probability Mapping. This is the table that runs your pipeline, and most people have never opened it.

Every stage, with its probability sitting beside it. Qualification, ten percent. Needs Analysis, twenty. Value Proposition, forty. Identify Decision Makers, sixty. Proposal, seventy-five.

Ask the straightforward question about your own org. Who picked those numbers? Not who typed them — Zoho typed them. Who checked your actual close rate by stage, across your own closed deals, and confirmed that a deal at Proposal really does close three times in four?

In most estates, nobody has.

And there is a fourth column on this table that does more damage than the probabilities, because almost nobody talks about it. Forecast Category. Every stage maps to one. Here, they are all set to Pipeline.

That category — not the probability — is what decides which bucket a deal lands in when a forecast gets assembled. Pipeline. Committed. Closed. Omitted.

Now read the note Zoho puts at the bottom of this very screen. On changing the forecast category of the stages, all existing deals with the respective stages will be updated with the changed category.

Sit with that for a second. One dropdown, on a table most teams have never opened, silently re-buckets every open deal you have. That is not a tidy-up. That is your forecast being rewritten underneath you.

Now the screen that tells you whether anyone ever revisited this. Setup, Customization, Pipelines. Read what's here. Create multiple pipelines with different stages for your business needs. Track your deals in the appropriate pipeline.

And then read what isn't here. There are no pipelines. This is the introduction screen — the one Zoho shows you before you've made anything. Which means every deal in this business, new logo and renewal, thirty thousand dollars and three hundred thousand, runs through one set of stages with one set of probabilities.

If you sell more than one way, the forecast is averaging things that don't belong in the same average.

Two things worth knowing before you plan around this screen. Pipelines are a Deals-only feature and they're layout-specific — so it's pipelines per layout, not per business. And you get five on Standard, ten on Professional, twenty on Enterprise, fifty on Ultimate; the free edition gets the one standard pipeline and nothing else.

One more thing, because it's the most common misuse. A second pipeline is for a different sales process. It is not where you put onboarding, or billing, or anything that happens after the deal closes. Those are not stages of a sale, and modelling them as stages is how a forecast ends up counting delivery work as pipeline.

So expected revenue is a chain, and every link in it is a configuration choice. Stage names you didn't write. Probabilities you didn't set. One pipeline for every kind of deal you sell. Multiply it out and report the total.

None of that is a discipline problem. You can hold better pipeline reviews every Monday for a year and not move any of it.

And notice what makes this hard to catch. Nothing on that screen is broken. Every deal has a stage, every stage has a probability, every number multiplies correctly — audit this pipeline for data quality and it passes. The defect sits one level up, in the assumptions the data is multiplied by, and no report in the product will show you those. You have to go and look, on a screen most teams open once during implementation and never again.

What to do, in order, and none of it is expensive.

One. Pull your closed deals from the last four quarters and compute the real close rate by stage. You now have your actual probabilities.

Two. Put those numbers into Stage-Probability Mapping — Modules and Fields, Deals, the Stage field, its own menu — replacing the defaults.

Three, and this is the one people get wrong, including me until somebody checked it. Probability belongs to the stage, and stages are one shared pool across your whole org. If two pipelines both use Proposal, they both get Proposal's seventy-five percent. You cannot give the same stage a different probability in a different pipeline.

So if two motions genuinely close at different rates, the answer isn't a second pipeline carrying different numbers. It's different stages — named for what actually happens in that motion, each with its own probability. The pipeline is how you group them. The stage is what carries the number.

Then hold the pipeline review. It'll be about the deals instead of about the arithmetic.

There's a second number the forecast doesn't look at, and it's the one that would tell you the most. Sort a single stage by how long each deal has been sitting in it. Here's one at ninety-one days.

That deal still carries the probability of its stage. As far as the forecast is concerned it is exactly as likely to close as a deal that arrived in the stage yesterday, because probability is attached to the stage and nothing decays it.

Any experienced salesperson looking at ninety-one days knows what it means. The forecast has no idea, and never will unless somebody configures it to care.

Now watch what that number actually does, because this is the part people feel. Here's a deal. Amount, one hundred thousand. Stage sets the probability to twenty-five percent. And Expected Revenue, computed for you: twenty-five thousand.

That is the arithmetic, in the open. A hundred thousand dollars of deal counts as twenty-five thousand dollars of pipeline, because a default said the odds were one in four.

Nobody in your company chose twenty-five. It arrived with the product. And every roll-up, every report, every board slide built on expected revenue inherits it.

Change the stage and the number moves. Change nothing, and it is still deciding what your pipeline is worth.

The work here is a few hours of analysis and about twenty minutes of configuration. The reason it doesn't happen is that it belongs to nobody — it isn't a sales task and it isn't an IT task.

That's the kind of thing we take accountability for. We scope it before we start, and if we estimate it low we absorb the difference.

CodeStringers. Zoho authorized consulting partner, Santa Cruz.