The case for turning it off

Things that get switched on rarely get switched off. Not because anybody has evaluated them and concluded they are working, but because removal requires somebody to make a decision and take responsibility for it, while leaving something in place requires nobody to do anything. The default is inertia, and inertia looks identical to success from a distance.

So it is worth saying explicitly: taking it down is an available answer, and choosing it is not an admission that the idea was stupid. A tool that does not fit a particular site is a fact about the fit, and the useful move is to notice it early rather than to spend a year improving something that was never going to work here.

The alternative to noticing is worse than doing nothing, because a neglected assistant is not neutral. It sits in the corner of every page answering questions with material nobody has checked for months, and it does that in your name, to your customers, with your logo on it.

Most conversations end in a handover you could have got from a plain contact link. If the honest summary of a week's traffic is that people said hello, asked something it could not do, and were passed to a form, then the widget is an expensive way of showing a contact form, and a contact form is a cheap way of showing a contact form.

The refusal rate has not moved after two genuine rounds of work on the material. One round tells you nothing, because the first round is always the obvious gaps. Two rounds that both produced real edits and neither of which changed the outcome is evidence that the questions being asked are not answerable from documents at all, which is a property of the questions rather than a fault in the assistant.

Nobody has read the logs in a month. This is the most reliable signal in the list and the one people most want to explain away. An assistant that nobody reviews is an assistant that is silently degrading, and the fact that the review stopped is usually not laziness. It is a rational response to sessions that were not producing anything worth the hour.

And the one that is hardest to admit: it is being used as a reason not to fix the pages. If the answer to every reported gap has become a promise to add it to the assistant's material rather than to the site, the widget has stopped being a support tool and started being a place to put things so they can stop being discussed.

Before removing anything, work out which of the two you have, because they look the same from the outside and lead to opposite decisions. The diagnostic is to take the ten questions it most recently failed and try to answer them yourself using only what you have published, with nothing from your own head.

If you can answer eight of them from your own pages, the material is fine and something between the material and the answer is broken: what got indexed, how it is chunked, where the threshold sits, whether the pages are reachable at all. That is a fixable configuration problem and removal would be the wrong response to it.

If you cannot answer them either, the assistant has been behaving correctly the whole time. It refused because there was nothing there. No amount of tuning creates material, and the honest next step is either to write the material or to accept that this site's questions are not the kind that documents answer. Both of those are conclusions about your documentation, and the assistant just gave you an unusually direct audit of it.

There is a category of business where nearly every inbound question is about a particular person's particular situation. Where is my specific order, what is the balance on my specific account, can you move my specific appointment, why was my specific application refused. None of those are answerable from published material, because the answer is not published anywhere and could not be.

An assistant reading only your documents will handle these correctly by declining them, and correct handling of nearly all your traffic still leaves you with a widget whose main function is to say it cannot help. That is not a failure of the software and it is not fixable by writing better documentation, because there is no document that contains a specific customer's order status.

The decision then is genuinely binary. Either the general questions underneath are worth serving on their own, in which case keep it and be honest about its scope in the opening message, or they are not, in which case the site needs an account area or a queue rather than an assistant. Recognising this in month one rather than month nine is worth a lot, and the way to recognise it is to look at what proportion of your inbox is about individuals rather than about the business.

The reason these decisions drag on for a year is that nobody set a limit at the beginning, so every month there is a plausible next thing to try and no point at which trying stops being reasonable. Set the limit before you need it, when nobody is invested in the answer.

A workable form: two named rounds of material work, four weeks apart, each with a written list of what changed, and a decision point after the second. Not a target number, because targets in this area are guesses, but a decision point with a named person who makes the call and a written note of what they will be looking at.

The value of writing it down in advance is that it protects the decision from whoever is most invested by then. It is much easier to switch something off against a criterion agreed in January than against nothing, especially when the person who introduced it is in the room.

The technical removal is the trivial part. Askably is embedded with one script tag, so deleting it from the template is a one line change, and every difficulty in this section is somewhere else. Do not hide it with styling instead of removing it: a hidden widget still loads, still costs the visitor something, and still appears for anybody whose browser ignores the rule you used to hide it.

Then go and find everything that referred to it, which is always more than you remember. Links and buttons across the site saying to ask the assistant. A line in the contact page describing chat as an option. Onboarding emails, order confirmations, printed material, an entry in your help centre, and the sentence in your privacy notice describing what the chat collects. Every one of those is now wrong, and the ones in email templates will keep arriving for months after the widget is gone.

Leave something in the space. A visitor who had learned there was a way to ask a question needs to find the replacement without hunting, so put the contact route where the launcher was, in the page, and make it obvious. Check the layout without the widget, because pages are sometimes built with a gap reserved for it. And if there was a dedicated help or chat page, redirect it rather than deleting it, so the links pointing at it from elsewhere still land somewhere useful.

Finally, deal with the data and the people. Export the conversation history before you lose access to it, delete what your own privacy notice said you would delete, tell whoever was receiving handover emails that the source is going away so they do not spend three months wondering why the enquiries stopped, and confirm the launcher is actually gone on the live site rather than only in the template you edited.

The conversations are the asset and they are worth more than the widget was. You now have a list of the questions your visitors actually ask, in their own words, gathered over months, with the ones your material could not answer already marked as such. Almost nobody has this, and people pay for far worse versions of it.

Turn the refusals into a content backlog before you archive anything. Each one names a question your published material does not answer, which is exactly the input for deciding what to write next, whether or not anything automated ever reads it. That backlog outlives the tool completely.

Keep the vocabulary too. The way visitors phrased things, especially where it differs from how your pages phrase them, is directly useful for headings, page titles and the opening sentences of anything you write from here. Whatever the widget cost you, this part of the return is real and it does not switch off when the script tag comes out.

The uncomfortable part of switching one off is that the reason usually is not the software. An assistant that answers only from what you gave it is a fairly direct instrument for measuring what you gave it, and a decision to remove one because it kept refusing is a finding about your documentation, delivered in an unusually specific form.

That finding is worth keeping even when the tool goes. If two rounds of material work did not move the refusal rate, you have learned that the questions your visitors bring are not currently answered anywhere you publish, which is true whether or not anything automated is reading those pages. Your visitors were already failing to find those answers. The widget only made the failure visible.

So write the conclusion down as a conclusion about the content rather than about the vendor. Then, if you ever consider trying again, you will know what has to be true first: a body of material that answers the questions people actually ask, in the words they ask them, findable without a widget. If that exists, an assistant is a convenience on top of it. If it does not, no assistant was ever going to substitute for it, and switching this one off was the right call.