AI forecasting for B2B sales: evidence, review and backtesting

1. Define the forecast and its inputs

Choose the outcome first: for example, signed new-business bookings in a calendar quarter. Do not mix bookings, ARR and recognised revenue. Define the forecast horizon, currency treatment, inclusion rules and snapshot timestamp so comparisons remain meaningful.

For each opportunity include a stable ID, amount, stage history, forecast category, expected close date, date changes and buyer-confirmed next steps. Add links to supporting records with their dates and permissions. Avoid exporting personal or confidential information beyond what the approved workflow needs.

2. Ask for an evidence review, not an invented probability

Use this prompt with approved, access-controlled records. Keep extracted facts, interpretations and questions separate. If the input does not contain a buyer commitment, the output should say unknown. A missing field is not evidence that the deal will be lost.

Prompt: Review this frozen opportunity snapshot using only the supplied records. For each deal return: opportunity ID; claim being tested; source ID and date; supporting evidence; contradictory evidence; missing information; question for the owner; and proposed review priority. Mark unsupported claims as unknown. Do not invent probabilities, alter amounts or move forecast categories. Finish with a list of records a manager should inspect.

Check a sample against the originals before reviewing the full pipeline. Common errors include treating seller notes as buyer commitments, using an outdated meeting as current evidence and merging information from similar account names. Reject outputs without traceable sources.

3. Turn an AI flag into an accountable decision

Illustrative example: a €50,000 deal appears in commit for this month, but the snapshot contains no confirmed procurement completion date. The assistant should flag the missing evidence and ask who owns procurement. It should not assign a probability based on the absence alone.

The seller checks the source, contacts the buyer where appropriate and records the answer. The manager decides whether to retain or change the forecast category, with a reason. Keep both the original recommendation and the final decision so later evaluation includes overrides.

Set boundaries before the pilot: no automatic customer contact, no silent CRM changes and no autonomous pricing or contractual commitments. Use the approved data environment and the smallest necessary input. These controls make the workflow inspectable without requiring a new prediction system.

4. Compare with a baseline at the same horizon

Synthetic example in thousands of euros. The baseline is the existing manager forecast; the assisted forecast includes the evidence review. Both are frozen at the same point before each period ends. The figures illustrate arithmetic, not a measured improvement from an actual client.

5. Calculate error and bias transparently

Weighted absolute percentage error (WAPE) = sum of absolute forecast errors divided by sum of actuals. Here baseline absolute errors total 70 and assisted errors total 20. Actuals total 400. Baseline WAPE is 17.5%; assisted WAPE is 5%. The difference is 12.5 percentage points. This tiny constructed example is not evidence of expected performance.

Signed bias = sum of forecast minus actual divided by sum of actuals. Baseline bias is +7.5%; assisted bias is 0%. Zero bias alone does not mean accuracy: overestimates and underestimates can cancel. If total actuals are zero, these percentage metrics are undefined; report absolute errors instead.

Use historical snapshots without information learned after the forecast date. Assess multiple periods and relevant segments, and report sample sizes. Compare time spent reviewing as well as accuracy. An assisted process should earn adoption through observed performance, not by beating a deliberately weak baseline.

6. What a public customer story can and cannot establish

Gong reports that LearnUpon reduced forecast error margins to 5-10% after adopting its platform. This is a vendor-published customer story, not independent evidence that all teams will achieve that result. Adrien was not involved in this example. The story supports investigating evidence visibility and workflow changes; it does not isolate the effect of AI or validate the synthetic backtest above.

Source: Gong: LearnUpon customer story (vendor-reported results)

7. Decide whether the pilot deserves wider use

Start with a limited pipeline review owned by revenue operations and a sales manager. Freeze the baseline, record review time and audit unsupported claims. Define acceptance criteria from your current performance and risk tolerance rather than using a vendor’s headline result.

Expand only when reviewers can trace outputs, correct errors and demonstrate that the process improves a relevant decision or reduces work without lowering quality. Keep a manual fallback. Use the downloadable backtest worksheet to make the comparison repeatable.

Reproduce the backtest with your own snapshots

Download the Python evaluator below and run it on a CSV containing period, actual, baseline and assisted columns. It uses only Python’s standard library, rejects duplicate periods and invalid values, and reports WAPE, signed bias and mean absolute error. All values must use the same currency and revenue definition.

Keep the prediction files frozen before outcomes are known. Record horizon, forecast owner and how AI assistance changed the process. Compare the same deals and periods across methods. The bundled three-period dataset is synthetic and checks the arithmetic only; it does not demonstrate real AI uplift. No confidential deal data is sent to this website.

Protocol for a publishable real-data evaluation

No real-data AI uplift study is published here. The evaluator and synthetic example are tools for running one, not evidence that a model improves forecasting.

Before outcomes are known, freeze baseline and assisted forecasts at the same horizon, record the snapshot time and lock the evaluation periods. Keep a private audit record of model version, prompt, available inputs and human overrides. Do not use close dates or stage changes learned after the snapshot.

Publish aggregate results only with permission and after checking confidentiality. Report the number of periods, revenue definition, WAPE, bias, MAE and errors by period, including worse results. A small observational backtest cannot isolate AI as the cause of an improvement.

The downloadable protocol gives the collection and publication checklist. Real historical snapshots or a prospective test are still required.

Reproduce the analysis

• Download the local forecast evaluator (Python)
• Download the synthetic input CSV
• Real-data collection and publication protocol

Related