Question handling
Answering is it down when the assistant cannot see the incident
During an incident, question volume spikes at exactly the moment your team has least capacity to answer it, which makes this the intent with the highest theoretical value in the whole set. It is also the one where an assistant is most likely to do harm, because it has no view of any live system and will answer from material written when everything was working.
What they are really asking
They want to know whether to keep trying or to go and do something else, and whether anybody at your company already knows.
- is the site down
- is it down for everyone or just me
- why is everything so slow
- when will it be back up
- are you having problems today
- i can't log in, is there an outage
- do you have a status page
- will we get a refund for the downtime
- how do i get updates during an incident
- was any of our data affected
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:
| A status page at a stable address, hosted away from what fails | The single source of truth for this intent, and the only material that can be current during an incident. Hosting it separately from the product is the whole point: a status page that goes down with the service is decoration. |
|---|---|
| Incident history | What happened, when, how long it lasted, and what was done about it. Useful during an incident because it shows a company that publishes, and useful in procurement for exactly the same reason. |
| How to subscribe to updates | The thing an assistant can most usefully offer somebody mid incident. It converts a person who will ask every ten minutes into a person who will be told, which is a real reduction in load at the worst possible moment. |
| Your service commitment and any credit process | What you commit to, how a credit is claimed, and by when. Publish it if you have one. If you do not, the honest position is that there is no automatic credit, which is better said in advance than during an argument. |
| A short list of things that are usually local | Stale sign in state, an extension interfering, a corporate network blocking something, an old app version. Framed as checks rather than as an explanation, because leading with have you tried clearing your cache during a real outage is its own kind of insult. |
How to handle it
Point at the status page first, every time
The assistant cannot know whether there is an incident. The status page can. The correct first move in every reply in this intent is naming that page and linking to it, before any troubleshooting and before any characterisation of the situation.
If the page is indexed and updated during incidents, the assistant will read the current entry and answer with it, which is the only mechanism by which this intent works at all.
Never assert that the service is up
There are no reported issues is a claim about a live system, and an assistant answering from a page written last month has no basis for it. During an actual outage it is the most damaging sentence available, because the customer knows it is false and now doubts everything else the widget has told them.
Write the fallback for this intent so the assistant says it cannot see live status, and names where live status lives.
Separate a local problem from an incident, carefully
The checks are worth offering, and the order matters: status page first, then the local checks, framed as things worth ruling out. Doing it the other way round tells somebody in the middle of a genuine outage that the problem is probably them.
Take the report if it might be new
The first person to notice an incident is a customer, and they usually reach the widget before the monitoring alerts anybody. A report that arrives with the time, what they were doing, the error, and their region is genuinely useful to whoever is on call.
Prompt for those details and hand over. This is one of the few intents where the enquiry is worth more to you than the answer was to them.
When it stops being an answer
Anything that could be an unreported incident
Several people describing the same symptom, or one person describing something the status page does not mention. The assistant cannot correlate reports, so the safe behaviour is to route rather than to reassure, and to do it quickly.
Data loss, wrong data, or a security symptom
Missing records, somebody else's information appearing, an unexpected sign in, an unexplained change. These are not outage questions even when they arrive during one, and they need a person immediately rather than a link to a status page.
Anything with a contractual consequence
Credit claims, service level breaches, a customer whose own commitments have been broken by yours. These are commercial conversations and the assistant should not characterise the incident, its cause or its duration in a way somebody will later quote back.
How this one goes wrong
The reassurance delivered mid outage
The service is down. A customer asks. The assistant, reading a page that says the platform is available around the clock, tells them everything is operating normally and suggests they clear their cache. The customer is now being told by the company that the problem they can see does not exist.
The cost is trust in the channel rather than in the service. Outages are forgiven routinely; being told an outage is not happening is not. Index a status page hosted away from your product, keep it current during incidents, and configure this intent so the assistant refers to it rather than to anything else it might find.
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 marketing agencyThis is a handover rather than an answer. A broken site or a missing tag during a live campaign costs money by the minute.
- For a online courseThe page that sells and the platform that serves fail separately. What may be said when a session starts in an hour.
- For a SaaS companyAn assistant reads documents, not systems, so it cannot know the service is degraded. Point at the status page and say nothing about now.
- For a developer tools companyIt reads indexed pages, so it knows what the status page said last time. Wording that points at live status instead of reporting it.
- For a fintech appWhen payments fail everywhere at once the cause may sit upstream. What to say when the app cannot see the rail or name whose it is.
- For a healthtech appAn outage with a booked slot behind it. Why the assistant cannot see the service, and the route that must never run through the thing that broke.
Questions
- Can it tell somebody whether the service is currently down?
- Only by reading a status page you index and keep current. It has no view of any live system unless you separately connect a data source, so without that page it should say it cannot see live status and point at where live status is published.
- Is it worth having the widget on during an incident at all?
- Yes, if it is configured for it. Pointing at the status page, offering the subscribe route and collecting reports takes real load off the team at the worst moment, provided it never claims things are fine.
- What is the single change that makes this intent work?
- A status page hosted away from the thing that fails, updated by whoever is running the incident, and included in what the assistant reads. Everything else in this page depends on that one piece of infrastructure existing.
Keep reading
- Handling complaintsThe job is to route, not to resolve. Acknowledge without conceding, name the escalation route, and get it to a person fast.
- Handling asking for a personThe design question at the centre of a support assistant. Offer early, offer once, collect what a reply needs, promise a time you can keep.
- Handling age and eligibilityState the rule, never apply it to the person typing. Age limits, membership, residency and licence conditions, and where the handover sits.
- 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.