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.