Playbook, SaaS company
The one question where the correct reply is somewhere else
Something has stopped working, the customer types is it just us, and the assistant has no idea. It reads material you wrote and holds no live signal about anything, and the marketing site it sits on is usually still up while the application is not. That combination makes an outage the most dangerous question in this trade, because a fluent answer read from a document is indistinguishable from a denial.
Why this is not the general answer
The handling pattern for service outages holds across every trade. What follows is the part that does not.
- Everything else the assistant answers is stable across weeks. The state of the service is not, and nothing in its material changes at the moment an incident begins.
- The widget sits on the marketing site, which normally survives an application outage, so the assistant is answering confidently from a site that works about a product that does not.
- The correct destination already exists and is maintained by people watching the systems: the status page, with its subscription option and its incident history, and the entire job here is getting somebody there in one reply.
- Only some of these messages are outages. The rest are one workspace, one browser or one network, and since the assistant cannot tell those apart it must not characterise anything as normal.
How it arrives
- is the app down or is it just us
- everything is really slow this morning
- are you having an outage right now
- where is your status page
- how do we get told when there is an incident
- do we get a credit for the downtime
What has to be indexed for this to work
| The status page, named as the place to go and not summarised | The address, what it covers, and which components are listed separately on it. The assistant should hand somebody the page rather than describe what it says, because anything it describes was read on a schedule and the reader needs the state now. |
|---|---|
| How to subscribe to incident updates | The route a customer follows to be told next time without asking. This is the answer that stops the same question arriving from six people in the same company during the same incident. |
| The published service commitment and how a credit is claimed | What is promised, which plans it applies to, what counts against it, and the process for claiming. Publish only what you would honour, because this material gets quoted back on the worst possible day. |
| Planned maintenance, and where it is announced | Your maintenance windows, how much notice goes out and through which channel. A scheduled window read as an incident produces a complaint that was entirely avoidable. |
The reply
I have no live view of the service, so I cannot tell you whether anything is degraded at the moment. Our status page shows the current state of each component and the history of past incidents, and you can subscribe there so the next one reaches you without having to ask [1]. If the status page is clear and it is still not working for you, that points at something specific to your workspace, browser or network, and the team will want the workspace name, the time it started and what you were doing when it did [2].
The limitation comes first because every sentence after it would otherwise read as reassurance. The subscription line is offered unprompted, since it is the thing that reduces the volume of this question permanently. And the last sentence turns a dead end into a useful report by naming the three things somebody needs to investigate a single workspace.
Where it stops
The trigger. The visitor asks whether the service is down right now, when it will be fixed, what caused it, or asks for a credit.
I cannot see the state of the service or tell you when something will be resolved. Please check the status page for the current position, and if you need this looked at for your workspace, leave your name, the account email, the workspace name and the time it started.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never say the service is up, running normally or unaffected, because nothing here observes it.
- Never estimate when an incident will be resolved, or say what caused one.
- Never promise a credit or a refund for downtime, since that is claimed under the published commitment and decided by the team.
- Never describe a problem as isolated, or as affecting only some customers, when there is no way to know either.
Questions
- Could we index our status page so it can answer this properly?
- You could, and you should not rely on it. Indexed material is read on a schedule, so during an incident the assistant would be quoting a page that changed several minutes ago, with a citation making it look authoritative. Pointing at the page is both safer and faster for the reader.
- Will it keep answering while our product is down?
- Yes, because it runs on your marketing site and answers from documents rather than from the application. That is genuinely useful, as long as it is configured to say clearly that it cannot see the service, which is the wording this cell exists to get right.
- What is the most valuable thing to publish for this?
- The subscribe route on the status page, mentioned in the fallback message. During an incident your volume is dozens of people asking one question, and every one of them who subscribes instead is a message you do not receive next time.
Keep reading
- Everything for a SaaS companyOne widget serves prospects, trialists and paying customers. What it can answer about plans and limits, and what has to reach a person.
- Handling service outages in generalThe assistant knows nothing about an incident unless your material says so. A status page it can read is the fix, and reassurance is the trap.
- The account is open and nothing has been set up yetImport limits, what an admin configures first and what trial work does at conversion. Onboarding answers that stop a week one stall.
- The steps do not match what the customer is looking atSupport questions on a subscription product where the documentation lags the interface, and the fault may be the plan rather than a bug.
- Will it work with what we already haveWill it work with our sign in, our browsers and the tools we already pay for. Three questions, and one is answered by the pricing page.
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.