An operations team, a tangled data mess, and what the cleanup looked like.
The ops team at a mid-size logistics company was running the whole business on 27 interlinked Google Sheets. Route planning, driver payroll, fuel reconciliation, customer SLAs, invoicing prep. All of it. One person, a senior operations manager named as the sheet owner on 24 of the 27 tabs, was the only human who understood how it fit together. He was six months from retirement.
That is the point where they called us.
Week one: do not build anything
The instinct on a project like this is to open a warehouse, load the sheets, and start modeling. We did not. We spent the first two weeks mapping.
- Every formula, on every tab, written down in plain English
- Every named range and every cross-sheet reference, drawn on a whiteboard
- Every weird conditional ("if column F is blank AND the driver code starts with N, then...") captured with the business reason next to it
- Every place the same concept was defined differently in two tabs, flagged in red
The red list was the real deliverable. Twenty-one concepts. "Active route." "On-time delivery." "Billable kilometer." All defined differently in different sheets, all reported to leadership as if they were the same thing.
Week three: get everyone to agree
We sat the operations manager, the finance controller, and the CEO in one room for a morning. We walked through the red list. For each item, one definition, written down, signed off.
Half the items were easy. The other half turned into real arguments, which was the point. A "billable kilometer" turned out to mean three different things depending on which contract type the customer was on. Nobody had ever written that down. The invoicing team had been quietly guessing for years.
By lunch we had a data dictionary. Twelve pages. Boring. Load-bearing.
Weeks four through eight: build
Only then did we open a database.
- Postgres as the warehouse, because they already ran it for another app
- A dbt project with source tables mapped one-to-one from the sheets, then transformed into the agreed definitions
- Tests on every join, every metric, every business rule from the dictionary
- A single reporting layer in Metabase, three dashboards: ops, finance, executive
The sheets kept running in parallel for six weeks. Every morning we reconciled the new numbers against the old. Every discrepancy was either a bug in the new model or a hidden bug in the old sheet. Both got fixed. By week ten there were no discrepancies left.
What actually changed
The 27 sheets are still there. Nobody opens them anymore. The senior operations manager retired on schedule and the business kept running, which was the entire reason the project existed.
A few things we did not expect:
- Finance closed the month two days faster, because the invoicing dispute cycle mostly disappeared
- Two full-time analyst hires got postponed indefinitely, because the reports maintained themselves
- The CEO started running the Monday ops meeting off one dashboard instead of a printed PDF someone had rebuilt at 6 a.m.
The lesson
Most data cleanup projects do not fail because the tools were wrong. They fail because nobody wrote down what the numbers were supposed to mean before the rebuild started. Write the dictionary. Get sign-off. Then build. In that order, every time.
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.