Why tools bought on their own die in month three
The pattern repeats with unsettling regularity. Enthusiasm in month one, indifference in month two, abandonment in month three. The cause is almost never the tool.
The pattern repeats with unsettling regularity. Enthusiasm in month one, indifference in month two, abandonment in month three. The cause is almost never the tool.
Most agencies we meet have already tried something. A writing tool, an assistant, a module bought alongside the agency software. And most describe the same trajectory: three people open it in month one, one in month two, nobody in month three.
The manager usually concludes the tool was not good enough, or that the team resists change. Both conclusions are wrong, and the second is expensive because it discourages trying again.
One more screen. A negotiator already has their transaction software, their mailbox, two portals, a spreadsheet, often WhatsApp. A tool living in an extra tab competes with the permanent urgency of the job. It loses that competition, not through bad will, but because opening one more tab while a vendor waits on the phone is a trade-off nobody makes twice.
The cost of input. An unconnected tool demands that you bring it material: copy the property details, paste the result back. That round trip eats a large share of the time saved. In month one, novelty covers it. By month three the sum has been done and it does not add up.
Nobody there during handover. This is the most frequent and the most underestimated cause. A tool delivered and invoiced, with nobody watching how the team actually uses it, dies at the first grain of sand. One slightly wrong output, one unforeseen edge case, one misunderstood step, and the negotiator goes back to their old method. They tell nobody, because reporting it is not their job.
That last point is worth dwelling on, because it explains why branch managers find out late.
A team abandoning a tool does not announce it. Nobody calls a meeting to say they have stopped. They quietly work around it, and the old reflex returns without anyone taking a decision. The manager notices a month later, on realising nothing has changed in the turnaround times and listings are still written by hand.
An adoption phase exists for exactly this: to make abandonment visible while it is starting, when it still costs a correction rather than an entire project.
Three practical consequences, which shape how we work.
We install inside tools that are already open, wherever possible. A smaller gain in an existing tool beats a larger gain in an extra screen, because the first survives and the second does not.
We install few things at a time. One piece adopted before the next. A complete setup delivered in one go cannot be corrected, it can only be endured, and a team that endures works around.
We stay. The adoption phase is part of the work and part of the price. It is not a commercial gesture, it is the only moment when you learn what actually does not work, as opposed to what did not work in the demo.
We count an automation as delivered when it is used, not when it functions. The distinction sounds rhetorical and it is not at all. It changes who carries the adoption risk, and there is no reason for that to be the agency.