A website chatbot that only knows your clinic

Most questions that arrive at a clinic through a website are not clinical. They are “do you take my insurance,” “are you open Saturday,” “where do I park,” “do you see children,” “how do I book.” Those answers already exist on your site. The chatbot exists so a visitor can ask in their own words instead of hunting through pages for them.

Every site gets its own knowledge base. It is built automatically when we generate the site: contact details, hours, and the booking link come straight from the structured data we scraped from your existing website, and services, insurers, and question-and-answer pairs are extracted from the page content. Nothing about it is shared with any other clinic.

Before you touch any of it, the bot still works. If the knowledge base has not been edited, it grounds its answers on the text of your published page instead, which already contains your real services, hours, and contact details. The knowledge base is how you make it better, not a prerequisite for it working at all.

A general assistant dropped onto a medical website will answer almost anything, because answering is what it was built to do. Asked whether a clinic accepts a particular insurer, it will produce a confident sentence whether or not that is true. Asked about a symptom, it will describe likely causes. Asked for a price, it will estimate one. None of those outputs are marked as guesses. The visitor cannot tell which sentences came from your site and which came from the model, and neither can you.

The consequences are not evenly distributed. A wrong answer about a shipping deadline costs a refund. A wrong answer about whether you accept a plan sends someone to an appointment they cannot afford. A confident answer about a symptom is unlicensed clinical guidance published under your clinic’s name, on your domain, in your voice.

So this one is scoped narrowly and deliberately. It is given one body of information, and told that anything outside it is a handoff rather than a question to be answered. The handoff is not an error path bolted on at the end. It is the designed response to most of what a chatbot on a clinic website will be asked, and the assistant emits a specific marker to trigger it rather than improvising an apology. The same discipline runs through the site generator, which is instructed to build pages from real scraped facts and omit a section rather than invent one.

The widget is Chatwoot, an open-source customer messaging platform. One installation serves every clinic, with a separate account and website inbox per clinic so contacts and conversations are isolated. When you publish on a qualifying plan, we create that inbox, attach our bot to it, and inject the widget loader into your published HTML. There is no snippet to copy and no account for you to create.

Published ClinicSite pages run under a deliberately strict content security policy: default-src ’none’, no form submissions anywhere, no plugins, no external JavaScript beyond the Tailwind CDN the design needs. A chat widget needs to load a script, open a realtime connection, and render its own interface in a frame, all of which that policy blocks by default.

Rather than loosen the policy, we widen it by exactly one origin. When the chatbot is configured, the Chatwoot host is added to script-src, and connect-src goes from ’none’ to that host over HTTPS and its WebSocket equivalent, and nothing else. frame-src permits that same origin and no other. When the chatbot is not configured, those directives stay closed. The widget is the only third party your published site can reach, and the browser enforces it rather than trusting us to have been careful.