Zendesk Guide and healthtech app
Where the message goes once somebody has described their symptoms
A help centre is the calmest surface a health product owns. There is no account on it, no clinical data, nothing signed in, and the articles are all about the software. That makes the usual placement question disappear, and it lets a different one through. People explain problems by describing what they were doing when it went wrong, and on a health product what they were doing is managing a condition. The material is safe. The messages that come back are not, and where those messages end up is decided by a field somebody fills in during the install.
Why this pairing is its own job
The Zendesk Guide install guide covers the tag, and the healthtech app guide covers what the assistant has to know. What follows is the part that belongs to neither.
- When a visitor wants a person, the assistant collects a name, an email address and a free text message and emails that to an address the owner nominated. On a health product a meaningful share of those messages will contain health information about the person writing them, which makes the choice of mailbox a governance decision made at install time by whoever happened to be doing the install.
- The ordinary advice for a help centre with restricted articles is to export them and upload them as sources, so the assistant knows what the agents know. On a health product the restriction is often a clinical or governance decision rather than an oversight, and following that advice widens who can be answered from material somebody deliberately narrowed.
- Every article on the site is about the software, so a question about a body has no good match anywhere in the corpus. What it does have is a near match: an article explaining how a reading is recorded, or how a chart is drawn, which shares most of its vocabulary with the question and answers a completely different one.
- The help centre sits entirely outside the product, so there is no authenticated area for the launcher to drift into and nothing to keep it off. The whole of the risk is in what people type and what the assistant says back, which is unusual on this axis and worth saying plainly rather than leaving somebody to assume the usual boundary work applies.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Zendesk Guide guide. Everything below is about where it goes on a healthtech app site specifically.
Choose the handover mailbox the way you would choose one for clinical correspondence
The address that receives handovers is going to receive descriptions of symptoms, medication and treatment, written by people who are trying to explain why the app did something odd. Pick it accordingly: a monitored shared mailbox inside whatever boundary your other health correspondence sits in, not somebody's individual work address and not a general web enquiries alias.
Then work out what happens to those messages afterwards. How long they are retained, who else can read that mailbox, whether they are in scope of the records you would produce if somebody asked for their data. Nobody asks these questions about a chat widget until the first message arrives, and by then the answer is whatever the default was.
The ticket form on the same page already went through this. It has fields somebody chose, a privacy notice somebody wrote, and a route somebody signed off. The assistant's handover is a second intake route with none of that attached to it, and the fact that it is easier to use than the form is exactly why it will be used.
Decide about the restricted articles with whoever restricted them
Read the visibility settings before you index anything, and separate the articles that are restricted because somebody was tidying from the ones that are restricted because a clinician or a governance lead decided they should be. They look identical in the admin and they are completely different decisions.
The first group can be published or uploaded and the assistant becomes more useful. The second group must stay out, and the assistant will look weaker to your own agents as a result, because they can see material it cannot use. Say that out loud during setup, otherwise it gets reported later as a fault and fixed by somebody uploading the articles.
Write the crisis wording into the refusal before the theme is published
A reader who reaches a chat panel in a help centre is already several steps into trying to sort something out on their own. If what they type suggests they are in danger, the reply has to break that loop immediately: the emergency number and the crisis line relevant to where they are, in the first line, ahead of anything about the product.
That belongs in the refusal message itself rather than in an article, because it has to appear when the message is ambiguous and badly typed, which is precisely when matching against your material is least reliable. Set the caution high enough that an unclear message gets the serious reading.
Get the wording from whoever owns your clinical safety position and publish the theme afterwards. This is the one part of the install that should not be tuned live.
Where the answerable material lives
| The account, device and export articles, which are the safe volume | Signing in, pairing or syncing a device, fixing a connection that has dropped, exporting data, deleting an account and everything on it. Purely about the software, asked constantly, and the entire reason a help centre earns its place. This is what the assistant should be excellent at. |
|---|---|
| The data questions, written as articles rather than left to the privacy notice | Who can see a reading, whether an employer or an insurer receives anything, where processing happens, what deleting an account actually removes. People ask these in the words of somebody worried rather than in the words of a policy document, and the article has to be written the way the question arrives. |
| Clinician facing articles, kept in their own section | Onboarding a practitioner, how a referral works, what appears in a clinical record, what a professional can and cannot see. Precise questions from readers who will not tolerate a vague answer, and material that is usually trapped in a sales deck. Keep it distinct from the patient facing set so an answer for one audience is not assembled from the other. |
| An escalation article that names the real route | What somebody should do when the product is not the right place: their own clinician, the service that gave them access, the crisis line. Published as an article so the assistant cites something written and reviewed rather than composing a route out of fragments. |
The first thing to get right
Send yourself a handover from the live help centre, describing a problem the way a patient would, and follow the email to wherever it actually lands.
Every other decision on this pairing can be revised after launch by reindexing or rewording. Where a message containing somebody's health information comes to rest cannot be revised retrospectively, and the field that decided it was filled in during an install by somebody who was thinking about widgets. Doing it once, before launch, is the only way to find out what you actually configured.
The failure that belongs to this combination
A support article answers a question about a body
Somebody asks whether a reading is normal, or whether they should be worried about what the app has shown them. There is no clinical material in the help centre, so nothing matches well. What matches best is the article explaining how that figure is calculated and how the chart is drawn, because it uses every word in the question.
The answer that comes back reads as clinical even though every sentence in it is about software. It explains what the number represents and how it is derived, in the confident register of documentation, with a citation to your own help centre. A worried person reads that as reassurance, and it was not written to be reassuring about anything.
The defence is the threshold and the refusal rather than better articles, because better articles are still articles about software. Set the match level so a question that is really about a person refuses rather than reaching for the nearest documentation, and write the refusal so it names their clinician or the service they came through in the same reply. An assistant that declines this cleanly is doing its job. One that explains the chart is doing something else.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a healthtech app visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Our best articles are restricted to signed in users. Should we upload them?
- Find out why they are restricted first. On most products that advice is right and the restriction was housekeeping. On a health product the restriction is frequently a decision somebody made about who should read the material, and uploading it hands the same content to anybody who opens the launcher.
- Can it tell somebody whether their reading is normal?
- No, and this is the line to hold hardest here, because the question arrives disguised as a product question. It can describe what the product measures and how. Relating that to a person is clinical, whoever or whatever produces it, and the reply should name a real route rather than hedge.
- Will it clash with the ticket form already on the page?
- Not technically, and you should not want it to win. The form is a designed intake route with fields and a privacy notice attached. The assistant should answer what is documented and hand over quickly to that form or to the mailbox you nominated, rather than keeping somebody in a chat panel who needed a person two replies ago.
Keep reading
- Installing on Zendesk GuideEdit the help centre theme, add the tag to the footer template, publish the theme, and check what a signed out visitor can actually read.
- Everything for a healthtech appHealth data is a special category and clinical claims carry device rules. What a healthtech assistant answers for patients, and for buyers.
- A help centre on one domain and the commercial material on anotherThe help centre holds how-to articles. Plans, limits and trust pages live on your marketing site, a separate origin and a separate crawl.
- A help centre anybody can read and a request form only account holders can useShoppers can read the delivery article and cannot open a ticket without an account. That makes the handover email the only route to a person.
- A Bubble health app has no page the widget can be kept offOne app wide script field, no route to keep it off the signed in screens, and a crawl that receives a shell instead of your copy.
- Where the widget has to stop on a Django health productThe base template is shared with the signed in area, and the content security policy decides whether any third party script runs.
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.