Six weeks of pipeline work. Eight hours a week saved. A short field note.
Every Friday afternoon, two analysts at a Berlin SaaS exported five CSVs from Salesforce, joined them in Excel, and emailed a PDF to leadership. The whole ritual ate eight hours a week and broke roughly once a month. When it broke, the PDF went out on Monday. When the PDF went out on Monday, nobody opened it.
What we found in week one
We did not start by building. We sat with the analysts for three days and asked one question, repeatedly: what does this column actually mean?
- Two of the five reports used different definitions of "active customer"
- One pipeline stage was renamed in 2024 but the export still used the old label
- A revenue column quietly excluded one product line because of a join error nobody had noticed
- The "churn" tab summed cancellations from two systems that double-counted
Half the work that followed was not engineering. It was writing down what every number was supposed to mean, then getting leadership to agree.
What we built
A small dbt project on top of their existing warehouse, a scheduled refresh, and a single dashboard. Six weeks of work, end to end.
- Source-of-truth models for customers, pipeline, and revenue
- Tests on every join and every metric, so the dashboard breaks loudly instead of silently
- One executive view, refreshed at 6 a.m., linked from a Friday 7 a.m. email
The result, six months in
The Friday email still goes out, automatically. The analysts got eight hours of their week back and spent it on actual analysis instead of plumbing. The leadership team stopped asking "is this number right?" in every meeting, which turned out to be the real win.
The boring lesson: most data projects do not fail because the tools are wrong. They fail because nobody wrote down what the numbers mean. Write it down first. Build second.
Want this kind of clarity on your own reports?
We rebuild executive packs and dashboards for a living. Send us what you've got. We'll tell you, honestly, what we'd change.