WordPress and dental clinic
A dental site on WordPress, and the frame in the middle of it
The book online button on a dental practice site almost never leads anywhere on the practice site. It opens a panel served by the practice management supplier from their own address, embedded in the page. Everything a patient agrees to at that moment, the deposit, the notice period, the charge for a missed appointment, lives inside that panel. It is on the page and it is not part of the page, and that distinction decides most of what an assistant here can and cannot say.
Why this pairing is its own job
The WordPress install guide covers the tag, and the dental clinic guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The booking panel is served from the supplier's address rather than yours. A crawl of your site reads the page around it and nothing inside it, so the deposit and cancellation terms a patient accepts at the point of booking are invisible to the assistant even though every patient sees them.
- The launcher cannot appear inside that panel either, and should not. The frame is somebody else's document. What matters is that a patient who is halfway through booking and has a question is looking at two things at once, and only one of them can answer.
- Practices that bought a website package often got a set of treatment pages written by the supplier and used unchanged by every other practice on the same package. As material they are generic, which produces answers that are true of dentistry and not of your practice.
- The traffic that justifies this arrives when the practice is shut. A chipped tooth on a Friday evening is the question the site gets most and the one the assistant must refuse hardest, which makes the out of hours wording part of the install rather than an afterthought.
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 WordPress guide. Everything below is about where it goes on a dental clinic site specifically.
Copy the terms out of the booking panel before you index anything
Open your own booking flow as a patient would and read what it says at the point of confirmation. The deposit, the notice period, the missed appointment charge and any card details requirement are usually stated there and nowhere else on the site.
Whatever it says, write it out as a page or a document on your own site and index that. The assistant then answers the question in the same words the patient will meet a moment later, which is the whole point. Where the supplier's wording and your website's wording disagree, fix the website rather than the answer, because the panel is what the patient actually agreed to.
The frame is a different address, and that is fine
There is nothing to configure for the booking panel. It runs on the supplier's address, your allowlist has no bearing on it, and the launcher renders in the page around it as normal. People occasionally try to allowlist the supplier's address on the assumption that it will make the widget appear inside the panel. It will not, and it should not.
The one practical consequence is layout. A booking panel that expands to fill the screen on a phone can sit under the launcher, so open your own booking flow on a phone once and check that the two are not fighting.
Write the out of hours refusal before the tag goes live
This is the install step people skip and then regret. The largest single category of evening traffic on a dental site is somebody in pain, and the assistant has to produce the practice number and the out of hours route in the first line of the first reply, not after a paragraph about opening times.
Set the refusal wording and the caution level in the same sitting as the install. A practice that goes live on a Thursday and writes the refusal the following week has had a weekend of symptom messages answered by a general purpose apology.
Where the answerable material lives
| The booking terms, transcribed out of the panel | Deposit, notice period, missed appointment charge, and whether card details are held. These exist inside the supplier's frame, so they have to be written out on your own site before anything can answer from them. |
|---|---|
| Your own price list rather than the supplier's | If the treatment pages came with the website package, the prices in them may be examples. The list the practice actually charges from is usually a separate document held at reception, and that is the one worth uploading. |
| New patient information as a patient reads it | How long the first appointment runs, what the examination covers, whether an x ray is usual, and what to bring. This is anxiety material and it converts, which is why it is worth writing rather than inheriting. |
| The out of hours route, stated as a route | Which number, at which hours, and what to do when the practice is closed. It belongs in the refusal wording itself as well as in the material, because a patient in pain reads the first line and stops. |
The first thing to get right
Read your own booking panel to the end, write the terms it shows into a page on your site, and index that page first.
It is the only material in this trade that a patient agrees to and the site never states. Until it exists as text you own, every question about deposits and missed appointments either gets refused or gets answered from a page that may not match what the panel says.
The failure that belongs to this combination
Confidently answering a deposit question from a page nobody updated
The failure specific to this pair is not silence, it is a stale answer with a good citation. The practice changed its notice period in the booking supplier's settings, because that is where the change actually takes effect. The website page describing the policy was written when the site was built and nobody thought of it, because it is not the thing patients agree to.
The assistant reads the website page, answers with the old notice period, and cites it correctly. The patient quotes it back when they are charged. The citation makes it worse rather than better, because it looks like the practice published one thing and did another.
The rule that prevents it: when the booking supplier's settings change, the page changes in the same job. Treat the transcription as a copy that has to be kept in step, not as a one off, and put the responsibility on whoever administers the booking system rather than on whoever administers the website.
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 dental clinic 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
- Can the assistant see whether we have an appointment free on Tuesday?
- No. It reads pages and documents, and the diary is not one. The useful version is that it answers the questions that come before a booking, states your deposit and cancellation terms accurately, and points at the booking button, which is a click away on the same page.
- Will the launcher appear inside the online booking panel?
- No. That panel is served from your booking supplier's address, so it is a separate document that your tag has no part in. The launcher sits in the page around it. That is the right outcome, because a booking flow is not a place to interrupt somebody.
- Our treatment pages came with the website package. Are they worth indexing?
- They are worth reading first. Supplier written pages describe dentistry accurately and your practice not at all, so answers built from them are generic and occasionally wrong about your prices or your equipment. Index them if they are true of you, and put your own price list in ahead of them either way.
Keep reading
- Installing on WordPressHook the tag into wp_footer with a snippet plugin, keep it out of the theme, and stop optimisation plugins from deferring it away.
- Everything for a dental clinicThe questions a dental practice actually gets, the ones that must reach a clinician, and the documents worth indexing first.
- Writing that is correct for a fortnight and published for yearsDeadline and threshold posts stay live at permanent addresses. In this trade an old figure quoted with a citation reads as advice, not as a stale tip.
- One launcher across a property that books in three different placesRooms, the restaurant and the spa each book somewhere else with their own notice period. One footer hook covers all three and the terms are on none.
- A dental practice on Wix, where consent decides who gets the assistantOn Wix the snippet loads only after a visitor accepts the consent banner, and the patient with a broken tooth at midnight is the one who dismisses it.
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.