The bot that does one thing: why we removed features instead of adding them

A higher-education institution needed to handle students who write in to withdraw. We arrived at the first session with a proposal that usually makes people uncomfortable: that the bot should do less than they were picturing.

The problem: ambition gets paid for in abandonment

The instinct, when buying a bot, is to ask it for everything. Have it greet, profile, understand context, offer alternatives, handle objections, try to retain, and while it is at it, log everything in the system. Each of those features sounds reasonable on its own.

Together they produce a long conversation with a person who does not want to converse. A student writing in to withdraw has already decided, and often carries a problem they are embarrassed to explain. Every extra question is a chance for them to close the window. And an abandoned conversation is not a retained student: it is a student who left without anyone learning why — the worse of the two outcomes, because it does not even leave a lesson behind.

One detail makes this failure especially expensive: it shows up in no report. Nobody measures the conversations that did not happen.

The solution: one job

The bot has one goal and nothing else: find out why the student is withdrawing and hand the conversation, right then, to the team that can solve it.

If the problem is money, it goes to financing. If it is academic, it goes to academic coordination. Two routes, defined with the institution before the first line of code. It does not profile, does not sell, does not handle objections, does not try to persuade.

That last part is the hardest to defend in a meeting and the most important. The bot has no authority to offer a scholarship, a change of format, or an extension; the person in the department does. Expecting the machine to retain is asking it to do a job it cannot finish, and the student notices by the third generic reply.

The awkward cases go first

The happy path — student writes in, states their reason, gets escalated — is the easiest to build and the least likely to appear in pure form. So the design started from the other end, with the three cases that break a support bot:

The student who already paid and whose payment was never recorded, who arrives angry and justified. The one who is not a student, because they misdialed or someone forwarded them the number. And the plain wrong number.

A bot that does not account for these three goes into a loop with exactly the people least willing to tolerate it. Solving them first changes the rest of the design, because it forces the bot to recognize when a conversation is not its own.

Why it matters to leadership

An ambitious bot that gets stuck is not neutral: it destroys conversations a person would have saved. That is a worse outcome than having no bot at all, and it arrives dressed up as modernization.

Every feature you take away from a support bot is one less chance to lose the person. It runs against the instinct to buy the solution that “does everything,” and it is the same reason we start with the process rather than the platform: the useful question is not what the tool can do, but what the one thing is that has to go right.

The figures on this page are design decisions documented in the project scope, not client business results. When measured results exist, they will be added here with their date.

Do you have a process where people arrive upset?

Cancellations, complaints, withdrawals, first-line support. If your current bot loses those conversations — or you are about to buy one that does everything — book a 30-minute session. We will work out what the one thing is that has to go right.