Playbook, SaaS company

The steps do not match what the customer is looking at

The characteristic support failure on a subscription product is not a missing document, it is a document that was true last quarter. Somebody follows the article, the menu is somewhere else, and they conclude either that they are stupid or that the product is broken. An assistant reading that same article repeats the wrong instruction fluently, with a citation attached to make it convincing.

Why this is not the general answer

The handling pattern for technical troubleshooting holds across every trade. What follows is the part that does not.

  • The material ages against a moving interface, so the risk is not an unanswered question but a precise, cited instruction to click something that no longer exists.
  • A missing capability is more often a plan boundary or a role than a defect, which means the same complaint has three ordinary explanations before anybody needs to look for a fourth.
  • The assistant cannot tell a broken workspace from a degraded service, so anything that might be an incident belongs at the status page rather than inside a troubleshooting answer.
  • The person typing is usually not technical and cannot volunteer what an engineer needs, so most of the value in this pair is in what the message collects before it is sent.

How it arrives

  • the export just gives me an empty file
  • the button in your help article is not there
  • our sync has not run since friday
  • why can i not see the reports tab
  • it works for my colleague but not for me
  • i changed a setting and now nothing saves

What has to be indexed for this to work

Material behind this answer
The help centre, with a reviewed date on every articleThe date is what makes an article usable here. Without one there is no way for anybody, reader or assistant, to weigh an instruction against the screen in front of them, and the confident wrong answer is the default outcome.
The plan and role matrixWhich capabilities appear on which tier, and which roles can see each one. It works for my colleague but not for me is almost always answered here, and answering it here is instant while answering it as a fault takes a week.
A known issues list, kept short and datedWhat is currently misbehaving, with a workaround where one exists. Publishing it stops people reporting the same thing twenty times, and it gives the assistant something true to say instead of improvising a cause.
What the team needs in order to reproduce somethingWorkspace name, the email of the member affected, the time it happened, the browser, and what was on screen. Put this list into the wording the assistant uses when it takes details, because the alternative is a first reply that only asks for it.

The reply

A reply worth copying
Two ordinary explanations before we call it a fault. A capability can be limited to certain plans, and it can be limited to certain roles, so if a colleague can see something you cannot, the plan and permissions page is the fastest place to check [1]. If the steps in an article do not match your screen, note the article and what you are actually seeing, because our pages carry a reviewed date and some are behind the product [2]. I cannot see your workspace or reproduce anything. If you leave your name, the account email, the workspace name, the time it happened and what was on screen, that is everything the team needs to start.

It offers the two boring explanations first, because they are the answer most of the time and they cost the reader nothing to check. Admitting that some articles lag the product is uncomfortable and it is also the honest reason their instructions failed. The final list is deliberately specific, since a message saying it is broken costs a full round trip.

Where it stops

The trigger. The visitor reports something that plan and role do not explain, or describes behaviour that may be affecting other members of their workspace.

The handover, worded
This needs somebody who can open the workspace, which I cannot do. Leave your name, the account email, the workspace name, the time it happened and what you were doing, and I will pass all of it on so nobody has to ask you again.

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 call something a bug, a known issue or a regression unless your own published list says so.
  • Never say a capability is available on the customer's plan, since the plan is not visible from here.
  • Never talk somebody through changing a workspace setting that affects other members.
  • Never present an article as current, because some of them describe screens that have since moved.

Questions

Our documentation is behind the product. Should we index it anyway?
Yes, with reviewed dates, and fix the articles with the most traffic first. The questions it gets wrong become a ranked list of which pages are stale, which is a more honest audit of the help centre than anybody has time to do manually.
Can it tell whether a problem is a fault or an outage?
No. It has no signal from the running service at all. The correct behaviour is to point at the status page for anything that might be widespread and to collect reproduction details for anything that looks like one workspace.
Does answering these actually reduce support volume?
The plan and role questions disappear almost entirely, and they are a large share of what arrives worded as a fault. What is left is genuine, and it arrives with the workspace name and a timestamp instead of the word broken.

Keep reading

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.