The spreadsheet is the system of record, and pretending otherwise is why BI projects fail

Walk into any operations team and you will find it: a workbook that somebody opens every Monday, that has grown four tabs of lookups, and that nobody dares refactor. It is not a staging area. It is the system — the place where the EDI export, the receipts dump and somebody's judgement about which SKUs to exclude finally meet.

The standard advice is to get rid of it. Model the data properly, land it in a warehouse, build the semantic layer, then hand people a dashboard. That advice is not wrong, exactly. It is just an eighteen-month answer to a question somebody has on a Tuesday.

What the workbook is actually doing

Three things, usually:

1. Joining things nobody joined upstream. Store codes in one system, store numbers in another, and a mapping that exists only because a person built it.
2. Encoding judgement. The returns that do not count. The test orders. The month where the warehouse moved and the numbers are not comparable.
3. Producing an answer on a deadline. Which is why it survives every attempt to kill it.

A tool that wants to replace the workbook has to do all three, and most only do the first.

Where Dashful sits

We took the position that the file is the input, not the embarrassment. You upload the export you already have. An agent profiles it, works out how it relates to the other files you uploaded, and proposes a dataset — grain, columns, measures, and the assumptions it made along the way.

Then it stops, and waits for you.

That pause is the whole design. The judgement in step two above is yours, and it does not survive being guessed at. What the agent is good at is the tedious part: reading a million rows, noticing that store_code and store_number share values, spotting the merged title row sitting above your real headings. What it is not good at is knowing which returns do not count.

So it asks.