Sales forecasts are wrong by Thursday because they are copies. Someone exports the CRM on Monday, pastes it into a sheet, adjusts the deals they know are wrong, and presents a number that was true at the moment the export ran. By Thursday two deals have slipped, one has closed early, a champion has gone quiet, and the sheet still says Monday. The fix is not a smarter model on top of the copy. It is to stop making the copy: compute the number from the live pipeline, keep every commit so accuracy can be measured, and score the deals under it from what has actually happened on them.
That is the whole argument. What follows is the longer version, because "stop making the copy" sounds obvious and almost nobody does it, and the reasons why are worth understanding before you buy anything.
The Monday ritual
Here is how the forecast gets made in most mid-market teams, and if this is not your team you can skip to the next section with our congratulations.
On Monday morning, or Sunday night, someone in RevOps or the sales manager themselves runs an export. It goes into a spreadsheet that has been copied forward every quarter for years and has tabs nobody remembers building. Each rep's deals are listed with a stage, an amount, a close date and a confidence percentage the rep picked. The manager walks the list before the call and adjusts what they know: that one is not really at 80, that close date is fiction, that rep always sandbags. Then the call. Each rep says a number. The manager writes the numbers down, rolls them up, and sends the total upward.
Every step of that is reasonable. The people are doing their best with a system that only knows what someone typed into it. And every step of it is why the number is wrong three days later.
Three reasons it drifts
1. The forecast is a copy, and the pipeline does not wait
The moment the export runs, the sheet and the CRM begin to diverge. Deals move. Amounts change. Someone finally updates a close date that was wrong for a month. None of that reaches the sheet, because the sheet is a photograph. So the conversation on Thursday, or at the next call, opens with fifteen minutes of "what changed?", and the answer is reconstructed from memory by the people who moved the deals.
The obvious objection is "just export again". Teams do, and then they have two sheets, and the manual adjustments from Monday are lost, and someone spends Thursday afternoon reapplying them. The copy is the problem, not the freshness of the copy.
2. The commit is not kept
Each rep says a number on the call. Where does it go? Into the manager's notes, or into a cell that gets overwritten next week. By the end of the quarter, the question "what did we commit on the 3rd, and what closed?" cannot be answered without an archaeology project, so it is not asked. Forecast accuracy, the one number that would tell you which reps to trust and which deals to inspect, becomes a matter of who remembers what.
This is the quiet one. Nobody notices it week to week. It shows up as a team that has been forecasting for five years and cannot say whether it is getting better.
3. Deal risk is a feeling
The confidence percentage on each row is a mood. Everyone knows this. A deal at 80% is a deal the rep feels good about, and the manager's adjustment is a second feeling applied to the first. Neither is connected to what actually happened on the deal: whether the economic buyer has been on a call, whether the champion replied last week, how many days it has sat in stage, whether the objections raised on Tuesday were answered.
The information exists. It is in the call recordings, in the email threads, in the contact list. It is just in three other products, and the person who could connect it to the forecast row is the rep, on a Friday afternoon, who has better things to do.
Why a better model does not fix this. There is a whole category of software that puts a prediction on top of the CRM export. Some of it is clever. But a model that reads a copy inherits every problem of the copy: it is scoring stale rows, it cannot see the calls, and it produces one more number that nobody can argue with. The forecast does not need a better guess. It needs to stop being a copy.
What fixing it looks like
Each of the three problems has a specific structural fix, and none of them is "try harder on Monday".
Stop making the copy
The forecast should be a view of the live pipeline, not an export of it. When a rep moves a deal, the number moves. When a close date is corrected, the quarter changes. There is nothing to refresh, because there is nothing separate to be stale. This sounds like a feature; it is actually a decision about where the data lives, which is why it is rare. A forecasting product that sits beside your CRM cannot do it. Only the system that owns the pipeline can.
Keep every commit
Every submission stored, with who, when and which deals were behind it. Not overwritten next week. Then two things become possible that were not before. First, accuracy: for every rep and every quarter, what was committed on each date against what closed, as a chart rather than a recollection. Second, the waterfall: between any two submissions, exactly what moved in, out, up and down, and which deal did it. The fifteen-minute "what changed?" becomes fifteen seconds of looking at it.
Score the deals from what happened
Replace the mood with factors. Every deal carries a health score computed from engagement, momentum, qualification gaps and days in stage, and the factors are printed next to the score, so a manager can say "the economic buyer has not been on a call in three weeks" instead of "I don't feel good about this one." That only works if the calls and the threads and the buying committee are in the same system as the deal. Which brings us back to the copy.
What Thursday looks like afterwards
The forecast is open and it is current, because it is the pipeline. The commit waterfall says two deals slipped and one closed early, and names them. The deal that slipped has a health score with the factor that fell, and the recording of the call where the timeline moved is on the deal, summarized, with the objection extracted. The manager asks one question about one deal instead of fifteen about the sheet, and the call is twenty minutes shorter.
At the end of the quarter, the accuracy chart updates itself, and the team can say for the first time whether it is getting better at this.
The forecast does not need a better guess. It needs to stop being a copy.
The honest caveat
None of this replaces judgment. A manager who knows that a particular customer always signs on the last day of the quarter is holding information no system has. The point of fixing the structure is to spend the call on that kind of judgment, rather than on reconstructing what the sheet would have said if it had been updated. Software should do the assembly. People should do the part only people can do.
How EmpireOS does it
The forecast in Empire Command is a view of the live pipeline; there is no export. Every commit is stored, per rep and per manager, and each past quarter keeps what was committed on each date against what closed. The commit waterfall shows what moved between any two submissions. Every deal carries a health score with the factors printed, computed from the calls, the threads and the buying committee that live on the same record. There are eight views of the same number, and the board deck is generated from it rather than screenshotted from a sheet.
Forecasting is not a module or a tier. It is part of the one plan at $129 per user per month. You can see the waterfall and the forecast record on the guided tour, and drive them yourself in the live demo, which runs on a real workspace with more than 700 closed deals of recorded outcomes.