You've bought software your staff work around rather than with.

Software gets chosen for a reason that made sense on the day: a compliance deadline, a funder's requirement, a demo that seemed to have all the features that everyone thought they needed. The people who will use it every day are rarely the decision makers so they are not even in that room.

So it arrives slightly wrong. It asks for fields nobody holds, in an order nobody works in, and it has no obvious place for the one case that comes up every week. Staff are practical, so they build the missing piece themselves: a spreadsheet, a group chat, a form that gets built alongside the system they have bought.

Nobody reports this, because from the inside it isn't a problem. The work is getting done. But what has actually happened is that you are paying for one system and running a second, invisible one next to it, and eventually only the invisible one holds the full picture.

Ask the person who does the data entry what they keep outside the system, and make it clear it isn't a telling off. There is almost always something: a spreadsheet, a notebook, a folder of emails.

Two other signals. If training a new starter includes a sentence that begins "ignore that bit", the workaround has become the process. And if the reports you actually take into meetings are built somewhere other than the system, the system is storage rather than software.

Then look at what the licence costs you a year. That is the price of the part people use, not the part you bought.

You are paying twice. Once for the licence, and again in the hours your staff spend maintaining the thing beside it that does the actual job.

The more serious cost is that the official system is no longer a reliable record. When something is queried, an inspection, a complaint, an insurance claim, the evidence you produce comes out of the system, and the system does not hold the full story. The full story is in a spreadsheet on somebody's drive.

It also makes the next purchase harder. Staff who have worked around one piece of software will work around the next one, and any business case that assumes they will adopt it is already wrong.