Question handling
Stepping somebody through a fault without answering from the wrong version
Support documentation accumulates. Old release notes, superseded guides, a community thread from three versions ago, all of it still published and all of it still retrievable. An assistant reading that set does not know which of them describes the software in front of the person asking, and a fluent answer built from the wrong one is worse than no answer, because it is followed.
What they are really asking
They want somebody to tell them which of the four possible causes this is, so they can stop guessing.
- it's not working
- i'm getting an error message
- why does it say connection refused
- it was working yesterday
- the page just keeps loading
- how do i fix error 403
- it crashes when i open it
- nothing happens when i click save
- is it broken for everyone or just me
- where do i find the logs
The material that answers it
An assistant is only as good as the document behind it, and for this question the document usually exists but is written in the wrong shape. What each one has to contain to be answerable:
| Documentation with the version stated on every page | Not in a sidebar selector, in the text. If the version is only in the URL or in a control the crawler never operates, every page in your documentation looks equally current to a retrieval system, and the oldest ones answer just as loudly as the newest. |
|---|---|
| A troubleshooting page organised by error message | Indexed under the exact string the software prints, including the code. People paste error text verbatim, so material that contains that text matches strongly, and material that describes the same problem in your own words does not. |
| A known issues list with dates and the version each was fixed in | This is what turns is it just me into a real answer. It also has a shelf life, which is why each entry needs a date and a resolution rather than sitting there as a permanent warning about something fixed last year. |
| Which versions are supported, and until when | So the assistant can say that a release is out of support rather than trying to troubleshoot it. That is a legitimate and useful answer, and without the published dates it cannot give it. |
| What you need in a report | Version, platform, browser or device, the exact error text, what they were doing, and whether it is reproducible. Publishing the list lets the assistant collect it during the conversation, which is where the value of this intent mostly sits. |
How to handle it
Treat the error message as the query
When somebody pastes an error, that string is the most specific thing they will give you, and it should match against material containing the same string. This is the argument for a troubleshooting page written around the literal messages your software produces, rather than around the concepts behind them.
Where the person has not given the error text, the first useful move is asking for it. It converts a vague report into a searchable one in a single exchange.
Pin the version before giving any step
Which version are you on is not bureaucratic, it is the question that decides whether the rest of the reply is true. An assistant that asks it first, and says clearly that the steps that follow are for that release, cannot mislead somebody into changing a setting that no longer exists.
If you cannot maintain versioned material, the honest configuration is to answer only what is version independent and refuse the rest.
Give a short ordered sequence, not the manual
Three steps, in order, with what to look for after each. Somebody troubleshooting is holding a broken thing and their patience is finite. A wall of text gets skimmed, the wrong step gets performed, and the conversation is now debugging two problems.
A shorter reply length is worth setting on this intent specifically.
Stop after two failures and collect
If the documented fix has not worked, the assistant has left the territory the material covers and further suggestions are improvisation. That is the moment to gather the version, the platform, the error text and the steps already tried, and hand over.
This is also the moment most likely to produce a genuinely useful bug report, because the customer has just done the reproduction work. Ask while they still have it in front of them.
When it stops being an answer
Anything that might be a fault on your side
A customer cannot distinguish their own misconfiguration from your outage, and neither can the assistant, which has no view of any live system unless you separately connect one. Once a report smells like a fault rather than a misunderstanding, it should reach somebody who can look.
Data loss, billing impact, or anything security shaped
Missing records, wrong data shown to the wrong person, a charge that looks wrong, an unexpected sign in. These stop being troubleshooting the moment they are described, and no step list should be offered before a person has seen them.
The documented fix has already been tried
Somebody who opens with I have already cleared the cache and reinstalled has read the documentation. Repeating it back is the fastest way to lose them. Recognise the phrasing, skip to collection, and hand over.
How this one goes wrong
The confident answer from a release nobody is running
The assistant finds a guide, follows it accurately, and describes a settings screen that was redesigned two releases ago. The customer looks for a menu that is not there, concludes they are doing something stupid, and either keeps hunting or gives up. Nothing in the reply was invented. It was simply true of different software.
The cost is a support contact that would not otherwise have happened, plus the customer's confidence that your documentation matches your product. Version stamp your pages in the text, remove the guides for releases you no longer support, and let the assistant refuse a version question rather than answer it from whatever it found.
The same question, trade by trade
The pattern above holds everywhere. The wording, the escalation line and the material behind it do not, so there is a page per trade.
- For a electronics retailerMenus move with every firmware release. Confident instructions for a screen that no longer exists read as a faulty product.
- For a bike shopA frame carries sound, so the reported location is unreliable. Two lists: what may be described, and what is never answered in text.
- For a universitySome campus IT questions are ordinary and one is not. What to say when a fault has an assessment clock running behind it.
- For a online courseMost playback failures come from the network, the browser or a work firewall. Here is the order to check them in.
- For a plumbing and heating firmThe same three digits mean different things on two appliances, and everything behind the case is work for a registered engineer.
- For a electrical contractorFault finding means isolating circuits and testing them. A guess from a description is worse than nothing, because somebody acts on it.
- For a car dealershipSome lamps mean book it in and some mean stop as soon as it is safe. The only useful answer here is about what not to drive.
- For a SaaS companySupport questions on a subscription product where the documentation lags the interface, and the fault may be the plan rather than a bug.
- For a developer tools companyDevelopers paste the error, not the concept. What an assistant can say about a failure it cannot reproduce, and where the guessing has to stop.
- For a fintech appCrashes, camera steps and reinstalls are answerable. The moment a payment is involved it stops being a troubleshooting question.
- For a healthtech appTwo ordinary faults on a health product, and the line where a message stops being technical the moment a symptom turns up in it.
Questions
- Can it check whether our service is currently up?
- Not on its own. It has no view of any live system unless you separately connect a data source. What it can do is point at a status page if you index one, which is why keeping that page current is worth more than any amount of troubleshooting content.
- How do we stop it answering from old documentation?
- Remove the old documentation from what you index, or put the version in the body text of every page so a version specific question matches the right one. Retrieval cannot infer recency from a page that never states it.
- Is a chat assistant any use for real technical support?
- For the first tier, yes: known errors, documented fixes and gathering a clean report. Its most valuable output is often the handover itself, because a report containing the version, the platform and the exact error saves the engineer the round trip.
Keep reading
- Handling setup and onboardingMost product material is written for somebody who already understands it. A first run guide has to be ordered, not merely complete.
- Handling compatibility questionsAnswerable only if you publish a list. Inferring compatibility is the failure, and the price of a wrong yes is a return and a refund.
- Handling warranty and repairsCustomers conflate a manufacturer warranty, an extended plan and their legal rights. Keep the three apart and never close the third.
- Every question typeHandling patterns for the questions every support inbox gets.
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.