Every marketing team runs on spreadsheets that a purchased platform was supposed to eliminate. This is treated as a discipline problem and it is a structural one, with a consistent explanation.

The pattern is close to universal

A platform is bought, configured and launched. Within a few months, a spreadsheet appears that pulls exports from it and rearranges them.

The spreadsheet becomes the version people actually look at. The platform becomes the place the data is stored before being exported.

This happens across categories, in organisations of every size, with expensive tools and cheap ones alike.

A pattern that consistent is not caused by individual habits. It is caused by something the two forms do differently.

The difference is what each one does with an exception.

A spreadsheet accepts anything

A cell can contain a number, a note, a formula, or a question mark. Nothing enforces consistency and nothing rejects an entry.

That permissiveness is the whole advantage. Real marketing data is full of cases that do not fit the model.

A campaign that ran for eleven days across two months, a cost that includes a rebate agreed later, a channel that was renamed halfway through the year.

Structured software either rejects these or requires a configuration change to accept them. A spreadsheet takes the entry and a footnote.

For a report due tomorrow, that difference decides which tool gets used.

Software encodes assumptions

Any platform embodies a model of the work, and the model was designed before your particular situation existed.

Where the model matches, the software is faster and more reliable than a spreadsheet by a wide margin.

Where it does not, the software becomes an obstacle, and the effort to make it fit exceeds the effort of doing the task by hand.

Vendors respond by adding configurability, which pushes the mismatch further out without removing it.

Every business has at least a few genuinely idiosyncratic processes, and those are where the spreadsheets cluster.

The last mile of any report

Most reporting is not a data problem, it is a communication problem. The audience needs a specific comparison in a specific order with a caveat attached.

Platform dashboards are built to be general, so they present the data neutrally and leave interpretation to the viewer.

A report to a senior audience is not neutral. It selects, orders and annotates, because the point is to support a decision.

That selection changes every month according to what is being decided, which is exactly the kind of variation a dashboard handles badly.

The spreadsheet exists to do the last mile, and the last mile is where the report acquires its value.

Shadow spreadsheets are a signal

When a spreadsheet appears alongside a tool, it is worth reading rather than eliminating. It is a precise statement of what the tool does not do.

Often the gap is small, a single calculation or a grouping that does not exist in the platform.

Sometimes it reveals that the team's actual process differs from the process the platform was configured for, which is more useful to know.

Teams that treat shadow spreadsheets as evidence get better configuration decisions than teams that treat them as non-compliance.

Banning them simply moves them somewhere less visible, usually onto a personal drive where nobody can review the formulas.

The risks are real

None of this means spreadsheets are harmless. Errors in them are common, hard to spot, and propagate silently through every downstream use.

A mistyped range or a formula that stops one row short produces a plausible number that nobody questions.

They also have no version control worth the name, so several slightly different copies circulate and the differences are discovered during a meeting.

And they concentrate knowledge in one person. When that person leaves, the file remains and the reasoning does not.

These risks scale with how important the output is, which is unfortunate because the most important reports attract the most manual handling.

What good tools learn from them

The platforms that displace spreadsheets successfully tend to share a few properties, and none of them are about feature count.

They export cleanly, so the escape hatch is always available and the tool is never the only path to the data.

They allow custom calculated fields, so the one missing metric can be added without a vendor request.

They let a view be saved, ordered and annotated, which covers a large part of the last mile.

And they are fast enough to use interactively during a meeting, because a report that takes thirty seconds to load will be replaced by a static copy.

Where the line should sit

The defensible split puts calculation in the platform and presentation in whatever tool suits the audience.

Anything that defines a number should live in one place with one definition, because that is where errors are expensive and drift is dangerous.

Anything that arranges numbers for a particular conversation can live anywhere, because it is disposable by design.

Problems arise when spreadsheets start defining metrics rather than displaying them, which is when two sources of truth appear.

The test is straightforward. If deleting the spreadsheet would lose a definition rather than a layout, it has crossed the line and the definition belongs upstream.