A company decides to put a chatbot on its website to help clients find what they need. The brief is a single line – put a chatbot on the site to help clients find what they need – and it arrives with a budget, an owner, and a launch date. What it does not arrive with is a problem. The line names a solution before anyone has established what their clients are trying to do, where they get stuck, or what the company is for – in serving them. A brief written this way can only produce chatbot-shaped answers, and the question that would have kept the real options open is never asked.

This is among the most expensive errors in change work, and it is invisible precisely because nothing looks wrong. There is a clear deliverable, a plan, momentum, a date in the calendar. The trouble is that the deliverable is a means, and the means has quietly seated itself where the end should be – and once that has happened, every later decision, however competent, serves the wrong master.

Ask the question the brief skipped – not how do we build the chatbot, but what are clients trying to do, what are we for in serving them, and would a bot, or something else, help or hinder that – and a fork appears that the single line had hidden.

A chatbot can serve two opposite purposes. It can build up the people who meet it: help them find, understand, and confidently use what they came for, as independently as they wish. Or it can feed on them: deflect contact, wear the persistent down, and bank the resulting silence as self-service. These are two different products, with different designs and different marks of success, and the brief had committed to neither – which meant it would drift to the cheaper one by default, with no one ever deciding that it should.

The drift has a mechanism, and the mechanism is a number. The natural figure to put on a contact-reduction project is the share of clients who never reach a human. It reads well when the bot truly helps, and it reads exactly as well when the bot frustrates people into giving up – a client who succeeded and a client who surrendered are identical on that line. Put that figure in the lead and the project will optimise, efficiently and measurably, for the outcome no one would have chosen out loud.

So before a single thing is built, two faults are already in place, and both are faults of sight rather than will. The field came in too small: a solution-shaped frame decided in advance what could be seen, so the real problem never had the chance to show itself.

And inside that narrowed field, a means stood where the end belonged – the chatbot, and its tidy number, installed as the thing to pursue. Nobody chose this. It is what a one-line brief does when no one stops it.

Left alone, the fault would not have stayed where it began. Once the bot went live and the number climbed on a wall, the trouble would have dropped out of the framing and into the act itself: every loop that wore a client down would have counted as a success, the dashboard glowing while the service worked quietly against the people it was built to serve. And this stage, unlike the first, leaves a mark you can feel – the wince in the support staff who can see clients struggling while the figures stay green. That wince is the organisation’s own early-warning system, and the surest way to let the harm set is to treat it as noise and route around it.

The correction has to happen before the building, not after, because a fault of sight is not repaired by better project management. It is repaired by restoring what the frame shut out and putting the end back where the means had sat. In practice, three moves.

Reframe the brief from a solution into a purpose, and name, out loud, what the company is for – here, that clients can find and confidently use what they need, as independently as they wish; the instrument gives the structure of that choice, never the value, which is the organisation’s to own.

Put the real options back, including the one the brief had foreclosed – better search and navigation with no bot at all, or a narrow assistant for the hardest cases and better search for the rest; a project that cannot survive the question should we build this at all was a solution hunting for a problem.

And demote the number: the share who never reach a human stops being the headline and becomes, at most, an operational figure, paired with a counter-figure that lights up if efficiency is being bought at the client’s expense – whether the task actually got done, whether they came back, whether they complained. The pairing is the whole discipline; no single figure is safe alone.

What changes need not be the chatbot. It might still be built, much as planned. What changes is what the project is aimed at, and how it will know whether it is working. The slide toward a service that wins by wearing people down loses its engine before it can start. The no-bot option stays live long enough to be fairly compared, which is the only way anyone could know the bot was worth building. And because a change is a two-beat motion – the launch, then the long, unglamorous embedding that makes it hold – finishing is redefined as a state that lasts, the real measures holding and the guards clean, rather than a date on which something shipped.

The case outlasts chatbots, which is why it is worth following the whole way through. A restructuring, a new system, a return-to-office mandate each arrives the same way: a means in the clothes of an end, with a budget and a date and no stated problem. So when the next change arrives already named as its own solution, the useful question is not how to build it well. It is what the thing is for – and whether you are still free to decide not to build it at all.