A reader opens a clinical document and asks "what dose should I give?"

The assistant has no idea whether the patient is four or forty. So it answers for everybody, at length, and helps nobody. The reader could have said. They almost never do, because from inside their own head the context was obvious.

Helpers fix this by asking first. They are a few short questions attached to a document's chat, and the answers travel with the reader's next message so the reply fits their actual situation. Patient age and weight on a clinical document. Device model on a support manual. Job role on an onboarding guide.

The point is not to collect data. That is what forms are for. The point is that the assistant knows who it is talking to before it opens its mouth.

What a reader actually experiences

With helpers enabled, a button appears among the chat tools carrying whatever section title you chose, with a small count of how many questions there are. Open it and the questions are there, with a note at the top explaining why: what you enter is sent with your messages so answers can be more relevant, and you can skip anything that does not apply.

You can also present the same questions as a wizard that opens by itself the first time someone clicks into the message box, titled Before you chat unless you name it something better. Questions come in panels with a progress bar and a step counter, and the last button reads Continue to chat.

The dismissal logic is more considerate than most onboarding flows manage. If every question is optional, dismissing is final and the reader is never nagged again. If something is required and they have answered nothing, it reopens next time they click into the box. Once they have sent a message, it stays out of the way permanently.

Nothing is hidden from the reader

This is the part that makes helpers worth using on sensitive material.

Once anything is filled in, a compact summary appears near the message box listing every answer. Readers can remove one, clear the lot, or reopen the form to add more. A line underneath says plainly that this information will be included with their question.

And when the message goes, the answers go with it as a labeled list at the top of their own message bubble, rendered readably: choices show their display label, checkboxes show Yes or No, numbers carry their unit ("72 kg"), dates look like dates.

So the reader can see exactly what the assistant was told about them. No invisible context, no hidden profile, nothing being quietly attached to their questions that they cannot inspect. For a clinician entering patient details, or anyone entering anything they would not want silently retained, that visibility is the whole basis of trust.

Which leads to the other half of the design. Helper answers attach to the next message and then clear. The summary strip disappears. The assistant still remembers the context from that earlier message for the rest of the conversation, but the form itself is empty again. Answers also clear on a new conversation, on switching documents, and on reloading the page. If the situation changes mid-conversation, the reader enters fresh values before the next question.

Building one

Helpers are configured per document, on the editor's Helpers tab, and everything saves itself as you go.

Four settings sit above the questions. Enable Helpers is the master switch, off by default. Wizard on first message turns the step-by-step version on. Section Title is the heading readers see everywhere, defaulting to "Patient Information". Description is optional text below it, doubling as the wizard's introduction.

Then the fields. Eight types cover most situations: number (with a unit shown inside the box and optional minimum and maximum), text, dropdown, checkbox, radio buttons, date, range slider, and section break.

Section breaks are worth more attention than they look. With the wizard on, each break starts a new panel and its label becomes that panel's heading. That is how a form of twelve questions becomes three screens of four instead of a wall people abandon.

Dropdown and radio options store a value separately from the label readers see, so you can rewrite the wording later without breaking anything that depends on the value underneath.

Conditional questions

Any field can appear only when conditions on other fields are met. Turn on conditional display and build rules from a field, an operator (equals, does not equal, contains, greater than, less than, is checked, is not checked) and a value. Show "Trimester" only when "Pregnant" is Yes. Show "Pediatric Dose" when "Age" is under 12. Several rules can combine with AND or OR.

Two details save you from yourself here. When the referenced field is a dropdown or radio, the editor offers its actual options in a picker rather than a free-text box, so you cannot mistype a value and quietly build a rule that never fires. And a field cannot reference itself.

The important behavior is what happens to hidden fields. They are not shown, they are not required even if marked required, and their values are left out of what gets sent. So an answer given early, in a field that a later choice made irrelevant, never leaks into the assistant's context and skews the reply.

Testing on the real thing

Each field has its own publish state, and an unpublished one carries a DRAFT badge and is visible only to admins in the live chat.

That is the practical way to try a new question: put it on the real document, in the real conversation flow, where you can see whether it reads clearly, without any reader ever meeting it. A preview panel below the list shows a simplified rendering while you build, but the draft badge is the one that tells you the truth.

One piece of advice worth taking. Keep the form short. A handful of well-chosen questions gets far better completion than a thorough questionnaire, and every question you add is a chance for someone to close the tab. If you genuinely need length, use section breaks and turn the wizard on, so readers meet four questions at a time instead of fourteen.