Written, 21 May 2026

Writing the sentence that gets read the most

Every configuration screen has a field for the fallback message, and it is almost always filled in with whatever the default was. That is a strange allocation of effort, because in most deployments the refusal is among the most frequently returned pieces of text in the entire system, and it is the one that arrives at the exact moment a visitor is deciding whether this channel is worth their time.

Why this sentence matters more than the others

Successful answers vary. Each one is different, each is read by whoever asked that particular question, and no single one is seen by many people. The refusal is one fixed string returned to everybody whose question falls outside your material, which in a new deployment is a substantial share of everybody.

It also lands at a decision point. A visitor who gets a good answer carries on. A visitor who gets a refusal decides, right there, whether to try a different phrasing, take the route you offered, or close the panel and go away. The wording determines which.

Askably makes you write this string yourself rather than generating it, and the reason is exactly this: it is the one piece of text where the tone and the routing have to be yours, because the routes are yours.

What a bad refusal does

The default form is an apology followed by nothing. Sorry, I do not have information about that. Grammatically fine, operationally useless: it tells the visitor that they have failed, without telling them what to do instead.

The second common failure is vagueness about scope. I can only answer questions about our services sounds like an explanation and is not one, because the visitor thought they were asking about your services. If the boundary is not stated in concrete terms, the visitor cannot use it to decide whether rephrasing would help.

The third is a redirect to somewhere that does not solve anything. Please see our help centre, when the whole reason they are typing is that they already tried the help centre. Pointing back at the thing that failed reads as a brush off, because it is one.

The three parts of a good one

First, what it cannot do, stated concretely enough to be useful. Not that was outside my knowledge but I do not have anything about individual orders, or I cannot answer questions about medical symptoms. The specific version teaches the visitor the shape of the boundary, which lets them judge whether their next question will work.

Second, the route that can. A phone number, an email address, a department, a named page, the opening hours of the phone line. This is the part most refusals omit and it is the part that does the work. A refusal without a route leaves somebody exactly where they started.

Third, an offer to take it further right here. If your setup can collect a name and a message, say so and say what happens next. Somebody who has just been told no is more likely to leave their details than to open their email client, and a captured message is a lead or a support ticket rather than a silent exit.

Write it in your voice, not in support voice

Read the draft out loud. If it sounds like a form letter, it will be read as one, and a form letter at the moment of failure confirms the visitor's suspicion that they are talking to a wall.

Short sentences. The same register as the rest of your site. No corporate hedging, no we apologise for any inconvenience, no unfortunately at the start. Unfortunately adds nothing and delays the useful part of the sentence by a word.

Also mind the length. A refusal that runs to a paragraph will not be read to the end, and the route you carefully included is at the end. Two or three short sentences is the working range.

Different dead ends may need different refusals

One string for everything is the simple case and often the right one. But there are usually two or three distinct dead ends that deserve their own wording, and if your tooling allows more than one fallback, this is where the effort goes.

The common split is between not covered and not permitted. A question about something you simply have not documented deserves a helpful, apologetic, come back later tone. A question that touches something the assistant must never answer, medical advice, legal advice, anything about an individual's account, deserves a firm, unambiguous refusal that names the urgent route first.

The third case, if you can detect it, is somebody explicitly asking for a person. That is not a failure at all and should not sound like one. It should sound like a handover.

Review it like a page, not like a setting

The fallback message goes stale in the same ways your pages do. The phone number changes. The department is renamed. The email address you routed people to belongs to somebody who left. Because it lives in a settings screen rather than in your help centre, it is never included in a content review.

Put it in the content inventory with an owner and a review date, alongside your actual pages. It is a published piece of customer facing writing that happens to be stored somewhere unusual.

And read a sample of the conversations where it was returned, every month or so. If people are rephrasing and getting it twice, the wording is not conveying the boundary. If they are leaving immediately, the route is not attractive enough. Both are fixable in the string itself.

If you take one thing away

The one thing
Rewrite your fallback message so it names concretely what it cannot do, gives one specific route that can, and offers to take a message, in under three sentences.

Everything above is the reasoning. This is the part that changes what you do on Monday.

Questions

Should the refusal apologise at all?
A brief apology is fine as long as it is not the whole message and does not come first. The failure mode is an apology that substitutes for a route. If cutting the apology leaves the message still complete and useful, cut it.
How do we word it when we genuinely cannot help at all?
Say that plainly and give the best external route you have, even if it is a competitor or a public body. A visitor who is told honestly that they are in the wrong place remembers it better than one who is sent in a circle.
Does a good refusal reduce our deflection number?
It usually does, because it converts silent exits into visible handovers. That is a real improvement being recorded as a regression, which is worth explaining to whoever reads the report before they see the change.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.