Pipeline reporting built on daily CRM snapshots

Your CRM cannot tell you what the pipeline looked like six weeks ago. Opportunity records are overwritten in place, so pipeline created in March recalculates every time a representative edits a close date, and the trend line in last quarter's board pack no longer matches the one you would produce today. This build opens with daily snapshots, dbt snapshot models over opportunity, stage history and forecast category, because without them every historical number stays quietly editable. The four numbers: Pipeline created, pipeline converted, slippage, and coverage against target, each cohorted by creation week and each traceable to the records underneath it. That is the reporting layer. Not forty tiles. A pack with forty tiles is a pack nobody reads, and four numbers that survive a hostile question from a CFO are worth more than a wall of charts that survives nothing. What the history exposes: Snapshots make the awkward things visible: how often close dates move, which stage deals die in, how much of this quarter's pipeline already existed on day one of the quarter. Insurance and banking teams tend to find that a long cycle has been hiding stage stagnation inside an average. Publishing teams tend to find their advertising pipeline is mostly renewals being counted as new business. Neither of those is a dashboard feature; both come from finally having a history that cannot be rewritten. Stack: Fivetran or Airbyte into Snowflake, BigQuery or Postgres, whichever you run, with no migration proposed as part of this. dbt for models and snapshots, with tests on the joins that break first. Serving in Looker, Metabase, Lightdash or Omni, again whatever you already own. Refresh once a day, on a schedule your team knows, with the completion time printed on the report. Real-time pipeline reporting is a request I decline: no decision in a business with a forty-day sales cycle improves for being fifteen minutes fresher, and the cost of an hourly refresh is paid every day by whoever maintains it. Definitions live in the repository: Every metric ships with a one-line definition beside the model, including the unflattering ones. What counts as slippage. Whether a reopened deal rejoins its original cohort. How a partial-quarter target prorates. When two people read a number differently, the definition file settles it and the meeting carries on instead of adjourning. Excluded: Forecast modelling and quota setting. Commission calculation, which is payroll-grade, needs an audit trail and an owner in finance, and should not live in a reporting model. CRM administration, workflow or field changes, where I list what needs to change and your administrator makes the change. Anything that writes back into the CRM. A poor fit when: Nobody has agreed which stage means what, so the report would describe a convention rather than a business. When the request is a dashboard to support a number already decided in a leadership meeting. Or when CRM hygiene is bad enough that the honest first deliverable is a hygiene report, in which case buy that instead and come back once someone has acted on it. Retainer or handover: The build stands alone and your analytics team can own it, because the models are plain dbt rather than a proprietary layer. Where a client keeps me on monthly it is for the things that erode: new products and stages entering the CRM, targets changing shape at the start of a financial year, and a quarterly session where we remove the metrics that stopped being used. Reporting rots faster than pipelines do, and the maintenance work is mostly deleting rather than adding.