The software was fine. Receiving was the problem.

A shop decides to track stock by size and colour. The counter is fitted out, staff are trained, barcodes go on. Within two months the stock record is unreliable and everyone concludes the software does not work.

The counter was never the problem. Billing at variant level is barely slower than billing at style level. The problem was that a delivery still arrives as forty pieces of one style and somebody in the back room now has to break it into sizes and colours before it can be booked.

That job takes longer than what they did before, it is nobody's favourite task, and it was not discussed when the decision was made.

Every software demonstration concentrates on the visible, pleasant parts: the sale, the report, the dashboard. Those are also the parts that are genuinely easy.

The hard parts are upstream and unglamorous. Who books goods in. Who reconciles the day. Who chases the supplier when an invoice does not match. Those steps determine whether everything downstream is real, and they are done by people whose workload is about to increase for the benefit of someone else's report.

Before recommending anything, the questions worth asking are about the least interesting parts of the operation. Who receives goods, and in what unit. Who is there when a delivery arrives at four in the afternoon. What happens to a return. Who closes the day when the owner is away.

The answers determine whether an implementation is a change to a system or a change to somebody's job. The second is entirely possible and often worth doing. It just needs to be a decision rather than a discovery.