How to review why a software purchase failed before buying again

The last system was never adopted. That one sentence hides three stories. The product may have lacked a feature, the scope may have been written around the wrong process, or the rollout may have left staff alone with a login. Think of a stock module that could not hold batch and expiry dates, a scope sheet that omitted returns, or a rollout that skipped the warehouse staff.

A product fault means choosing differently, a scope fault means writing better requirements, and a rollout fault means planning training and ownership, whichever product wins. Draw the three layers on a whiteboard. Leave it up for every interview.

Skip this sorting and the next purchase repeats the mistake under a new logo, with a fresh demo hiding the same missing owner.

Start with documents. Pull the proposal, signed order form, statement of work, change requests, training attendance sheet and user list from the admin screen, then add the last login beside each name. If the vendor portal is still active, export the audit log as a CSV file and sort it by user and by month.

Opinions arrive later, and they arrive loudly. Documents show what was agreed and login dates show who used it, so a tool licensed to thirty people and opened by four is a clear finding. Check the dates against the project plan too, because a go-live that slipped by three months often explains why people had already rebuilt their spreadsheets.

Keep everything in one shared folder, then scan the SSO settings, API key list and licence invoice for seats nobody touched, because dormant accounts show where adoption stalled.

First, ask what was bought, and copy the modules, user counts and integrations from the signed contract, never from memory, because memory remembers the demo and forgets the clauses. Second, what was promised in writing? Mark every sentence about reports, speed or fit, and quote the clause number and page, so the discussion concerns the text and not anyone’s recollection of a sales meeting.

Third, who used it? Count real users by team. Fourth, what did they go back to? Ask staff plainly, and expect a spreadsheet, a chat group or a paper register, because each one names a missing feature or an unloved screen.

Keep interviews short and separate. Group meetings turn into a defence of the original decision, so start each interview by asking what the person did on their last working day, step by step. Mention the old system last.

Tag every finding. A report the vendor never offered is a product fault, one nobody asked for is a scope fault, and one that staff never heard of is a rollout fault. Where a finding fits two layers, record it under both, and let the evidence decide which layer dominates the count, as with barcode scanning, serial tracking or credit-note approval.

Now count the tags by layer. Mostly scope means your requirements were thin, so the next quotation needs a stronger brief written before any vendor is invited. Mostly rollout means switching products will not help until someone owns adoption, a training plan exists and managers use the system in their own weekly meetings.

Be fair to the people involved. Many failures began when a busy manager approved a demo that never touched real data, so blame belongs to the process more than to any person. Call the vendor’s account manager only after the note is written, so the facts are fixed before any negotiation about credits, refunds or contract extensions starts.

Write a one-page note. Say what failed, in which layer, with three pieces of evidence, and add the single change you will make before buying again, such as a requirements document.

Share the note with each vendor you approach next and ask how they would avoid every failure on it, because their answers tell you more than a demo does. Ask for a named person at the vendor who will attend the pilot, and ask what happens if usage stays low after the first fortnight.

Book the pilot and name an owner. Put the owner’s name, the pilot date and the review date at the top of the note, then send it to the partners the same day.