The duplicate stack: an audit that finds what you are paying for twice

The invoice list had forty-one tools on it. The capability map had nineteen jobs. Eleven of those jobs were being done by two or more tools at the same time, and six tools had not been logged into in ninety days. Two of the six were still billing annually, and one of them was the tool the group had replaced eighteen months earlier with the tool next to it on the register.

Nobody was incompetent. This is what a stack looks like when eight stakeholders each buy against their own problem and nobody owns the sum.

Why it accumulates

Four mechanisms, and all four are rational at the moment they happen.

A tool arrives attached to a problem and a champion. The champion leaves; the tool does not. An OEM program mandates a platform, correctly, for its own reporting needs, and the dealer keeps their existing tool because the mandated one does not do the local thing. Acquisitions and new rooftops arrive with their own stack, which nobody decommissions because decommissioning is somebody's extra week. And pilots are sold with an end date that only one person remembers.

The result is not waste in the ordinary sense. Each purchase was justified. The waste is in the multiplication, and multiplication has no owner.

Step one: inventory from the money

Start with accounts payable, not with a workshop. Export 24 months, filter for software and subscription vendors, strip duplicates by vendor rather than by invoice description, and you will have a list that is more accurate than anything a memory-based inventory produces. Contract records will name the entity, the term and the renewal date.

Then open the tag manager and audit the containers on every template. This is the half most audits skip, and it is the half that costs the shopper. A tag with no invoice still ships JavaScript to every page view, still competes with the interaction handler, and still needs a consent classification. The container is the honest list of what is running on the site; accounts payable is the honest list of what is being paid for. Reconcile them.

Step two: map capability, not brand

A brand name tells you nothing about overlap. A capability map does.

Nineteen jobs, and the same pattern in most of them: the mandated tool and the discretionary tool, running in parallel because neither was ever given the whole job.

Step three: the register

One row per tool, and the columns are the argument.

The blank outcome column is the most useful part of the document. A tool that cannot name the number it moves has been surviving on being unexamined, and the register examines it without anyone having to make an accusation.

Step four: the overlap test

Three questions, in this order.

Does it do the same job? Not a similar job, the same one, defined by the capability row. Does it produce the same output? A dashboard, a list, a report the business already reads. And does one feed the other?

That third question is the one that saves projects. If the call tracking platform supplies the conversions that the bid management tool spends against, they are a pipeline, not a duplicate. Consolidating a pipeline looks like a saving on a spreadsheet and breaks the measurement in the room. Duplicates are only the tools that answer the same question to the same audience with independent data.

Step five: kill criteria

Any one of these is enough to put a tool on the shortlist for removal, provided nothing depends on it that the register has not noticed.

No login in ninety days, from anyone with admin. No named owner. Its output was not used in a single decision last quarter, which is a judgment the department head can make in thirty seconds. Annual cost exceeds the outcome it claims. It duplicates a mandated tool. Its tags cost more main-thread time than the capability is worth.

The last one deserves its own line because it is invisible on a P&L. Three tags across a template, each 60 milliseconds of main-thread work, is a fifth of a second added to an interaction budget that was already failing at the 75th percentile. Removing them is a performance project disguised as procurement.

Step six: the order of removal

1. Dealer-side duplicates of a mandated tool. You cannot remove the OEM-mandated platform, so remove the one you bought to work around it, or at least agree which one owns which part of the job.
2. The highest annual cost duplicates, because they pay for the audit twice over.
3. The heaviest tags, because they compound on every page view and every template.
4. The unowned, and the unlogged.
5. Everything else, into the annual review with a named owner and a revisit date.

A composite example, from a group of nine rooftops, presented as a composite rather than a client:

What consolidation actually buys

Money is the smallest part of the return in most groups, which is why the audit is usually framed wrongly. The larger returns are attention and milliseconds.

Attention: a weekly review with five dashboards does not happen. A weekly review with one register and three numbers does. Every tool removed is a login someone no longer has to remember, a report nobody has to reconcile, and one fewer place a definition of a lead can drift.

Milliseconds: the tag column is a performance budget in disguise. Most dealer pages that fail Interaction to Next Paint are not failing because of the platform. They are failing because of what four overlapping tools each loaded to justify their renewal.

And the accountability: a stack of nineteen capabilities with nineteen named owners can be governed. A stack of forty-one tools with eight champions cannot, and the audit is the only mechanism that converts one into the other. That is why the register belongs next to the KPI definition document, not in a procurement folder.