How do I write a guide that tells readers where to get help when it cannot answer their question?

Give readers three things, in this order: the boundary of the guide, a suitable next step, and any important expectation about that step. Be specific about the boundary: for example, “This guide explains how to prepare your request; it cannot confirm whether a particular request is eligible.” That is more useful than “This guide may not answer everything.”

Then point to a resource only if you have checked that it exists and handles that kind of question. Use a visible placeholder while drafting, such as [verified support page] or [team responsible for this topic]. Don’t fill it with a guessed email address, phone number, opening hours, or response promise. A link is not helpful merely because it is available; it should lead to the people or material relevant to the question.

For websites, help mechanisms can include contact details, forms, self-help pages, and chatbots. WCAG’s guidance on consistent help concerns where such mechanisms appear across a set of pages; it does not require a site to provide help or ensure that a person is always available. It also recommends making clear when human support is unavailable and directing contact to a team that can help with the relevant content. [S1]

Describe the guide’s scope, not its shortcomings. A simple pattern is: “This guide covers [what it explains]. It does not determine [specific decision or situation]. For questions about [that issue], use [verified relevant resource].”

Keep the limit narrow. “This guide does not assess individual cases” tells readers more than “This is not advice,” which may be vague. Pair the limit with a genuinely useful action: what information to look for, which established process to follow, or where the responsible team’s verified guidance is located. If there is no verified next step yet, keep a placeholder in the draft; don’t invent a route to make the section look complete.

For example, suppose a guide explains how to submit a general request. A usable draft might say: “This guide explains the information to include in a request. It cannot confirm the outcome of an individual request. For questions about a specific case, see [verified page for case questions].” Replace that bracketed text only after confirming the page is current and relevant.

Use this as a template, not as finished factual content:

“What this guide can help with: [specific task or topic].

What it can’t answer: [specific decision, exception, or individual circumstance].

Where to go next: For [type of question], use [verified resource or contact route]. [If known and confirmed: State when this route is available, or explain that human support is not always available.] This guide does not promise a response time or outcome.”

Before publishing, confirm that the named resource exists, is appropriate for the intended reader, and is handled by a team or service equipped for that topic. If the route is a chatbot or self-help page rather than a person, label it accurately. If human help is unavailable at certain times, say so rather than letting a contact option imply continuous availability. WCAG’s explanatory guidance supports making that unavailability clear; it does not establish that any particular contact route has been verified or guarantees a reply. [S1]

Check the wording and the placement separately. The wording should fit each guide’s actual scope and direct readers to the right resource; don’t copy a generic contact route onto a topic it cannot handle. The placement should be easy to find. For website help mechanisms that recur across a set of pages, WCAG 2.2’s consistent-help criterion addresses keeping their location consistent. [S1] That does not mean every guide must offer the same kind of help, or that a help option must exist.

A practical example: if three guides each include a “Where to get help” section, place that section in a predictable location, but tailor its limits and verified destination to each guide. Before release, replace every placeholder, confirm each destination is the one intended, and remove any availability or response-time statement that has not been confirmed. If no suitable resource is confirmed, don’t invent one; have the content owner establish the correct next step before presenting it as a real contact option.