How to build a forecast snapshot sync

What matters here

• Take the snapshot at the same time every week, after the forecast call is due and before the review. A snapshot taken on a different day each week can't be compared.
• Capture the call as well as the pipeline: each rep's commit and best case, and each manager's adjustment. The pipeline alone can't measure forecast accuracy.
• Never edit a snapshot. Corrections go in the next one.
• Compare the call with the outcome at the end of the period. Accuracy by rep and by manager is the number the forecast review needs.
• Report what moved between two weeks deal by deal: pushed, pulled in, shrunk, grown, lost. That is the conversation the review should be having.

Who this is for

You run revenue operations or sales finance. The weekly forecast lives in spreadsheets copied from the CRM, nobody can rebuild last month's number, and every board meeting starts with how the forecast changed.

How it works in practice

What happens every week between the forecast call closing and the forecast review starting.

1. 1

   The forecast call closes

   Reps and managers have submitted commit and best case in the CRM or the forecasting tool.

2. 2

   The snapshot is taken

   Every open opportunity with amount, stage, close date, owner and forecast category, plus every submitted call, stamped with the week.

3. 3

   It is written once to the warehouse

   Added alongside every earlier snapshot. Nothing already stored is changed.

4. 4

   The week is compared with the last

   Each deal is matched to its previous snapshot: close date pushed or pulled in, amount up or down, stage moved, lost.

5. 5

   Slipped deals are flagged to the owner

   A deal that has pushed its close date twice in a quarter goes to the rep and the manager before the review.

6. 6

   Calls are scored at period end

   Each rep's and manager's commit is compared with what closed, so accuracy is measured rather than remembered.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then find where the call lives

   A snapshot of the pipeline without the call can't measure forecast accuracy.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Salesforce for the pipeline
   and the forecast call, Snowflake for the snapshots and Looker for the
   review, or whatever we run in those seats.
   
   I need Opportunity with amount, stage, close date, owner and forecast
   category, and wherever submitted forecasts live: Salesforce forecasts,
   a custom object, or a forecasting tool.
   
   Tell me when the weekly call is due, so the snapshot runs after it
   closes and before the review.

2. 2

   Take the snapshot and write it once

   The rule the whole history depends on.

   Headless skills build-workflow tray-gotchas

   Copy

   Use build-workflow, then tray-gotchas.
   
   Every Monday at 18:00, read every open opportunity and every submitted
   forecast call. Write them to Snowflake with the snapshot date on every
   row.
   
   Only ever add rows. Never update or delete a row from an earlier week.
   If the run fails halfway, delete only this week's partial rows and run
   it again, so a snapshot is either complete or absent.
   
   Count the rows against the open opportunities in Salesforce at the time,
   and alert in Slack if they don't match.

3. 3

   Compare each deal with last week

   The view the forecast review is missing.

   Copy

   For each opportunity, compare this week's snapshot with last week's and
   label the change:
   
     pushed       close date moved out of the period
     pulled in    close date moved into the period
     grown        amount up
     shrunk       amount down
     lost         closed lost since last week
     new          not in last week's snapshot
   
   Total each label by team, and list the five largest changes by value
   with the owner.

   Keep the labels plain. The review should be able to read the change list out loud.

4. 4

   Flag slips before the review

   A slipped deal is a question for the rep, not a surprise for the board.

   Copy

   Any deal that has pushed its close date twice in the same quarter, or
   lost more than 20% of its amount since the start of the quarter, goes
   to the owner and their manager in Slack before the forecast review.
   
   One message per person, their deals only, with the change history.
   Never change the deal in Salesforce. The snapshot reports, the rep
   decides.

5. 5

   Score the call at period end

   Forecast accuracy measured, by person, every period.

   Copy

   At the end of each period, compare each rep's and each manager's commit
   from every weekly snapshot with what actually closed.
   
   Report accuracy by person and by week of the quarter, so we can see when
   the call becomes reliable, and publish it to Looker beside the current
   forecast.

6. 6

   Prove it works, then hand it to RevOps

   Because the review changes shape more often than the data does.

   Copy

   Run the per-step checks and the whole-workflow audit, and run the
   snapshot twice in a test schema to confirm a rerun never changes an
   earlier week.
   
   Then open the workflow in Tray Build so revenue operations can change
   the snapshot time, the slip thresholds and the change labels in the
   visual canvas.

What it connects to

The sync reads the pipeline and the call, keeps the history and puts the change where the review looks.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides