Weekly Sales Forecast - Agent Prompt

Who this is for

Founders who are also head of sales, first sales hires, and anyone who currently builds the weekly number by exporting deals to a spreadsheet and eyeballing it. If your forecast today is "whatever the pipeline view says times a feeling," this prompt replaces it with three defensible numbers and a list of exactly which deals moved them. It assumes nothing exotic: deals with a stage, a value and a close date. That is the entire data contract.

Run it once a week, same day, same time - the delta logic depends on a steady cadence. It complements a daily pipeline review: the daily pass keeps records clean, the weekly pass answers "what number do we say out loud."

Three numbers, computed - never asked

The commit / best case / pipeline taxonomy comes from Salesforce-style forecast categories, standard across B2B sales for two decades. What most teams get wrong is letting reps assign the category by hand. The moment a category is an opinion, the forecast inherits every incentive problem in the room: sandbagging from whoever is ahead, happy ears from whoever is behind. So this playbook makes the category a function of facts the CRM already holds:

Category	Rule (computed)	Reads as
Commit	Deal sits in the final stage(s) before won, close date inside the period, value set	"I would bet the quarter on this"
Best case	Commit + every deal past early discovery with a close date inside the period	"If the good calls go our way"
Pipeline	Every open deal with a close date inside the period	"The raw material"

Three rules keep the numbers honest. First, the tiers are cumulative: commit is a subset of best case is a subset of pipeline, so the smallest number is always the safest one. Second, a deal with no value or no close date is not forecastable - it goes to a named bucket with a count, never silently into (or out of) a total. Third, stage semantics are declared, not guessed: the agent shows you its stage-to-category mapping once, you approve it, and the same mapping runs every week. If a late-stage deal keeps failing qualification, that is a stage problem, not a forecast problem - pair this with a MEDDPICC audit so "commit" also means "qualified."

The delta is the forecast

A single week's totals are trivia. The information is in the movement: which deals entered commit, which left it and where they went, what slipped and by how many days. Spreadsheet forecasts lose this because every export is an orphan - comparing two CSVs named final_v2 is nobody's Monday habit.

The prompt solves it with a snapshot trick: after you confirm each report, the agent writes stage, value and close date into three forecast_last_* custom fields on every open deal. Next week's run diffs live data against those fields and classifies each deal as new, upgraded, downgraded, slipped, or unchanged. The CRM carries its own history; no warehouse, no exports, no BI seat. Slippage gets special treatment because it is the highest-signal event in any pipeline: a close date that moved later - or quietly sailed past - almost always means the buyer's process changed and yours did not. The report lists every slipped deal with the days slipped, the last activity date, and one concrete question to ask the buyer.

This is why agent-computed beats the export workflow outright: the data is read live at run time, the rules are deterministic and reviewable, the history rides on the records themselves, and the output ends in writes - snapshot fields updated, a note logged on every slipped deal - instead of a file that goes stale by Tuesday.

The prompt

Paste this into any MCP-connected agent. It is written against Relm's API surface (deals carry value_cents, stage, close_date; custom fields register via POST /v1/fields) but the logic ports anywhere:

You are my weekly sales forecast analyst. My CRM is Relm
(MCP: https://api.relmcrm.com/mcp - use the relm_* tools).

DEFINITIONS
- Period: the current calendar quarter (I may override).
- Open deal: any deal not in a won- or lost-type terminal stage.
- Categories are cumulative and COMPUTED, never asked:
  commit    = deals in the final stage(s) before won, close_date
              inside the period, value_cents set
  best_case = commit + every deal past early discovery with a
              close_date inside the period
  pipeline  = every open deal with a close_date inside the period
- Deals missing value_cents or close_date go to a separate
  "not forecastable" bucket: count them, never sum them silently.

RUN
1. Read the schema. List every pipeline and its ordered stages.
   Show me your stage -> category mapping and wait for my OK the
   first time; reuse it without asking on later runs.
2. Page through all open deals (follow next_cursor to the end).
3. Compute commit / best_case / pipeline: value sum + deal count.
4. Delta: for each open deal, compare stage, value_cents and
   close_date against its forecast_last_stage,
   forecast_last_value_cents and forecast_last_close_date custom
   fields (last week's snapshot). Classify each deal:
   new | upgraded | downgraded | slipped | unchanged.
5. Slippage list: every open deal whose close_date is in the past
   OR moved later since the snapshot. Include title, value,
   old -> new close_date, days slipped, and the date of the last
   activity on the deal.
6. Narrative: max 6 sentences on WHY the number moved. Name deals,
   not aggregates. If commit fell, say which deals left it and
   where they went.
7. Print the report in the exact format I provided.
8. Only after I confirm: write this week's snapshot back to each
   open deal's forecast_last_* fields, sent under custom_fields
   (register any missing field via POST /v1/fields, object "deal",
   data types text / number / date), then log one activity
   (type "note", deal_id set) on every slipped deal containing
   the single question to ask the buyer this week.

And the output format to hand it - terse enough to paste into Slack unedited:

WEEKLY FORECAST - Q3 2026 - week of Jul 6

            this week         last week    delta
commit      $229,000  (7)     $210,000     +$19,000
best_case   $312,500  (13)    $298,000     +$14,500
pipeline    $475,700  (22)    $461,200     +$14,500
not forecastable: 5 deals (3 missing value, 2 missing close date)

MOVERS
+ Acme rollout      $45,000   proposal -> contract     now commit
- Globex renewal    $26,000   contract -> negotiation  left commit
+ Initech pilot     $14,500   new this week            best_case

SLIPPAGE
1. Globex renewal   $26,000  pushed 43 days (07-03 -> 08-15),
   last touch Jun 24
   Ask: "Is Aug 15 procurement's date or ours?"
2. Umbrella upsell  $18,000  pushed 31 days (07-20 -> 08-20),
   last touch Jun 12, second slip in a row
   Ask: "What changed on your side since our last call?"

NARRATIVE
Commit rose $19k net: Acme entered on a signed contract, but
Globex left commit after legal went quiet and the close pushed
to Aug 15 - second consecutive slip, treat as at-risk. ...

The snapshot fields the prompt relies on - each object below is a valid POST /v1/fields body, and the agent can register them itself on the first run:

[
  {"object":"deal","key":"forecast_last_stage","label":"Forecast snapshot: stage","data_type":"text"},
  {"object":"deal","key":"forecast_last_value_cents","label":"Forecast snapshot: value (cents)","data_type":"number"},
  {"object":"deal","key":"forecast_last_close_date","label":"Forecast snapshot: close date","data_type":"date"}
]

Apply it with your agent

Point an MCP client (Claude, or anything that speaks MCP) at Relm once:

{
  "mcpServers": {
    "relm": {
      "type": "http",
      "url": "https://api.relmcrm.com/mcp",
      "headers": { "Authorization": "Bearer relm_live_..." }
    }
  }
}

Then paste the prompt. Prefer REST? The deal list the agent reads is one paginated call, and a relm_test_ key lets you rehearse the whole ritual against an isolated free dataset first:

curl "https://api.relmcrm.com/v1/deals?limit=100" \
  -H "Authorization: Bearer relm_live_..."

Once the weekly report is boring - which is the goal - automate the reactions to it: wire stage-change playbooks so the moves the forecast surfaces trigger follow-ups on their own.

FAQ

What do commit, best case, and pipeline mean in a sales forecast?

They are cumulative confidence tiers. Commit is what you would bet the quarter on: late-stage deals with a close date inside the period and a real value. Best case adds the deals that close if the good calls go your way. Pipeline is every open deal with a close date in the period. Each tier contains the previous one, so commit is always the smallest number. The taxonomy comes from Salesforce-style forecast categories and is standard across B2B sales.

Why compute the forecast from stages instead of asking reps for a number?

Self-reported numbers encode mood: sandbagging when a rep is ahead, happy ears when they are behind. Stage plus close date plus value are observable facts already in the CRM, so two people running the same rules get the same forecast. Reps still add judgment - but as visible overrides you can question, not as the starting point.

How does the agent compute week-over-week deltas without a data warehouse?

The snapshot lives on the deal itself. After each run the agent writes stage, value and close date into three forecast_last_ custom fields. Next week it compares live values against that snapshot and classifies every deal as new, upgraded, downgraded, slipped, or unchanged. No warehouse, no exports - the CRM carries its own history.

Do I need Relm to use this prompt?

No. The category rules, the snapshot trick and the output format work with any CRM your agent can read - the prompt only assumes stages, values, close dates, and somewhere to store three snapshot fields. It is written against Relm's MCP server because that makes setup one config block, but you can port it to any API-first CRM.

What about deals with no value or no close date?

Never let them silently vanish from the total - that is how forecasts get quietly optimistic. The prompt lists them in a separate not-forecastable bucket with a count, and the weekly fix is mechanical: a deal that cannot state a value and a close date is not forecastable, so either fill the fields or move it out of late stages.