Sales Forecasting Is Just Sales Reporting

The enterprise sales forecast is one of the most consequential numbers in a company's operating rhythm. It determines hiring plans, cash management, board narratives, and for late-stage companies, IPO readiness. Miss your forecast by 15% in either direction and the downstream consequences ripple for quarters.

And yet, the way most companies forecast revenue is primitive. A rep fills out a field in Salesforce. A manager applies gut-feel adjustments. A data scientist builds a regression on historical close rates by stage. Finance averages these inputs, applies a haircut, and calls it a number.

Everyone knows this is broken. The question is why it's broken, and I think the industry has been answering that question incorrectly.

The modeling fallacy

The conventional wisdom is that sales forecasting is a prediction problem, that we need better models, better features, better algorithms to divine what will happen with a deal. So companies invest in propensity scoring, machine learning classifiers trained on CRM metadata, and weighted pipeline mechanics that try to compute a probability from stage, deal size, and days-in-stage.

These models are doing something real. But they're solving the wrong problem. They exist because the data they operate on is distilled and incomplete. A deal's "stage" in Salesforce is a categorical compression of dozens of signals (buyer sentiment, competitive dynamics, procurement timelines, champion engagement, budget availability) into a single dropdown value that a rep updates when they remember to. Of course you need a model to predict outcomes from that. You've thrown away almost all the information.

The prediction model isn't sophisticated. It's compensating. It's trying to reconstruct signal that was lost the moment it was compressed into CRM fields. Imagine instead that every rep had a personal writer that chronicled every single thing they did. That would store the information we condense into compressed fields in a much more rich form. That's the point when you break down forecasting, and replace it with information reporting.

What happens when you stop compressing

Here's the thesis: when you collect and synthesize enough raw context about a deal, forecasting stops being prediction and starts being reporting.

Think about what an experienced sales leader does when they want to know if a deal will close this quarter. They don't look at the Salesforce stage. They ask the rep: Who did you talk to last week? What did the champion say about budget? Did legal push back on anything? Are they evaluating anyone else? What's the procurement timeline?

They're not predicting. They're reporting on what is actually happening, and then comparing that to pattern-matched experience from hundreds of similar deals. The "model" is just: this looks like deals that closed, or this looks like deals that didn't.

An LLM can do this at scale.

If you feed an LLM the raw, unstructured context of a deal (call transcripts, email threads, Slack conversations, meeting notes, CRM activity logs), it can synthesize a deal summary that captures what is actually happening, not what a rep remembered to log. And if you pair that synthesis with historical context about what similar deals looked like when they closed (or didn't), the resulting prediction isn't really a prediction at all. It's structured reporting with a comparison layer.

With good reporting at scale using LLMs, the line between what is forecasting and what is simply excellent reporting becomes blurry. You're not gazing into a crystal ball. You're reading the room, across every deal, all at once.

When I built a system like this and benchmarked it against the existing statistical model at my company, the LLM-based approach outperformed by over 20 percentage points on an early cohort of ~100 deals. That's not a marginal improvement. It's a category difference, and it happened because the LLM had access to the information that the legacy model never saw.

Accuracy is a function of access

This reframing has an important corollary: prediction accuracy is directly proportional to data access. Not model sophistication. Not feature engineering. Access.

Consider two deals:

Deal A is at a mid-market tech company. Every external call is recorded on Gong. The rep logs notes in Salesforce after each meeting. The buyer's procurement team communicates via email, all of which is captured. Slack channels track internal deal strategy in real time.

Deal B is a regulated government contract. Calls cannot be recorded. Email is restricted. The only data that exists is what the rep manually enters into CRM fields: stage, next steps, a brief note.

No model, LLM-based or otherwise, will forecast Deal B as accurately as Deal A. Not because the model is worse, but because the information doesn't exist. The ceiling on forecast accuracy isn't algorithmic. It's observational.

This is why "just build a better model" is the wrong frame. The right frame is: how much of what's actually happening can you capture and synthesize? The forecasting problem is a data collection problem masquerading as a data science problem.

The data access problem nobody talks about

This sounds straightforward in theory. In practice, getting access to the raw data inside an enterprise is one of the hardest problems you'll face.

Call recording alone is a minefield. Some companies have universal recording policies. Others leave it up to individual reps, which means coverage is inconsistent. Regulated industries, government contracts, and deals involving certain geographies may prohibit recording entirely. Even when recording is technically allowed, buyers sometimes decline consent, and you lose that signal for the deal.

Beyond calls, the data is scattered across systems that don't talk to each other, often owned by different teams with different access policies. The CRM is owned by RevOps. Email lives in IT. Slack is controlled by Engineering or Security. Getting a unified pipeline that pulls from all of these requires navigating internal politics, security reviews, and procurement processes that can take months.

And then there's the cultural layer. Sales teams are often skeptical of systems that ingest their communications. Reps worry about surveillance. Managers worry about liability. Even if the technical access exists, the organizational willingness to use it may not.

None of this is unsolvable. But if you're building this system, plan to spend as much time on data access and internal alignment as you do on the LLM pipeline itself. The architecture is the easy part. Getting the organization to feed it is the real work.

Architecture of an LLM forecasting pipeline

If you accept this framing, the system you'd build looks fundamentally different from a traditional ML forecasting model. Here's the architecture at a high level.

1. Context ingestion

You need a pipeline that continuously pulls raw, unstructured data about every open deal. This includes:

• Call transcripts (from Gong, Chorus, or similar)
• Email threads between reps and buyers
• Internal Slack threads about the deal
• CRM activity history (meetings logged, stage changes, field updates)
• Any notes, documents, or attachments associated with the opportunity

The key design principle is: don't pre-filter or summarize at ingestion time. Store the raw context. Let the LLM decide what's relevant during synthesis. That's what it's good at.

2. Deal summarization

For each deal, pass the ingested context to an LLM with a structured prompt that asks it to synthesize a deal summary covering specific dimensions: buyer engagement level, competitive landscape, procurement status, technical validation progress, champion strength, and risk factors.

This summary is the core artifact. It should read like what the best AE at your company would say if you pulled them aside and asked "what's really going on with this deal?", except it's generated from the full data record, not from memory.

3. Prediction as pattern matching

With a rich deal summary in hand, the prediction step becomes comparatively simple. You feed the current deal summary alongside historical examples of deal summaries and their outcomes (closed-won, closed-lost, slipped) into a single LLM call that acts as a prediction guide. The model compares the current deal's context against the patterns it sees in past outcomes and returns a probability estimate with a written rationale.

This works because the summaries are dense with real signal. The LLM isn't guessing from a stage field. It's reading a comprehensive account of what's happening and comparing it to comprehensive accounts of what happened before. The prediction dramatically outperforms models trained on raw CRM fields, because the inputs actually contain the relevant information.

A note on model selection: this is where quality matters enormously. The summarization and prediction steps require a model that can reason over long, messy, contradictory context and extract the right signal. You want the best frontier model available, not the cheapest one. Right now, that means something like Claude Opus 4.6. Cutting costs by dropping to a weaker model is a false economy. The entire value of this architecture depends on the quality of the synthesis, and synthesis quality is directly tied to model capability. This is not the place to optimize for tokens.

4. Write-back and feedback loops

The predictions and summaries need to be written back to your system of record, typically as Salesforce fields on the Opportunity object. This is where the system becomes operational rather than experimental. Revenue leaders and FP&A teams need to see these predictions in the tools they already use, not in a separate dashboard they'll forget to check.

Equally important: build a feedback loop. When deals close or die, capture the final outcome and compare it to the prediction that was made. This gives you a rolling accuracy metric that you can use to calibrate the system and identify where it's weakest (usually the low-data deals).

The uncomfortable implication

If this framing is correct, then most of the enterprise "AI forecasting" market is building the wrong thing. They're building better models on top of the same impoverished data. Slightly fancier regressions on CRM fields. Marginally better feature engineering on pipeline metadata.

The companies that will win this category are the ones that solve the data access problem, that figure out how to capture, synthesize, and reason over the full unstructured context of a deal. The model is the easy part. The context layer is what matters.

This has implications beyond forecasting. If you have a system that can synthesize everything that's happening in a deal into a rich, structured summary, that same summary powers deal reviews, competitive intelligence, onboarding for new reps, QBRs, and board prep. The forecast becomes a byproduct of a much more valuable underlying asset: a real-time, comprehensive understanding of what's actually happening across your entire pipeline.

The system I'm leading at my company, which we call the deal intelligence layer, is built on exactly this thesis.

The forecast was never the hard problem. The hard problem was always: do you actually know what's going on?

---

If you're building something similar or thinking about this problem, I'd love to compare notes. Find me on LinkedIn or Twitter/X.