What Dentally gives a website
Dentally is cloud practice management software used widely in dental practices, and from a website's point of view the piece that matters is patient-facing online booking and the patient forms that go with it.
What is available to you depends on your plan, your region and which modules you have, and the details change between releases. So confirm with Dentally what your account supports before anyone designs a page around it. Ask three specific questions: can patients self-book online, can a link preselect an appointment type, and can the booking page be embedded as well as linked.
Everything else Dentally does happens inside the practice and never touches your pages.
The rule: nothing third-party loads until the patient taps Book
The common mistake is dropping a booking widget into the footer of every page. A hygiene site is mostly read rather than booked: the price list, the what-happens page, the photographs of the room, the reviews. Loading a third-party booking script on all of them slows the pages that do the persuading, for the benefit of the one page that does the booking.
So one booking page carries the embed, and every other page links to it. On a site where most rebooking happens from a phone, that decision is worth more than any other performance work you could do.
The booking page
Give it a clean URL such as /book, with nothing on it but the booking flow, one reassuring line, the phone number and your opening hours.
Reserve the height before the widget arrives so the page does not jump while it loads, and preconnect to the booking host in the head:
<link rel="preconnect" href="https://your-dentally-booking-host">
<div class="booking-embed" style="min-height: 720px"><!-- Dentally booking embed --></div>Use whatever host your own Dentally booking link points at in place of the placeholder above. Above the embed, three short lines that stop the calls you get most: whether a referral is needed, what the visit costs, and what your cancellation window is. Below it, the phone number again.
Link from every page that sells
Each page gets its own Book button, pointed at the right appointment type where the link format allows it. The price list gets a button per line. The what-happens page gets one at the end. The header carries one on every page.
If an appointment type cannot be preselected by link, the button still goes to /book and the line above the widget names which option to pick. That single sentence prevents most wrong bookings.
Hosted page or embed
A hosted booking page on the vendor's own domain is usually more reliable on phones than an embedded widget, especially inside in-app browsers. An embed keeps the patient on your domain and looks tidier.
Test both before deciding. If the embedded version misbehaves on a real phone, send the buttons to the hosted page instead. Reliability beats tidiness on the one page that has to work.
Configure Dentally before the site points at it
- Appointment types and durations for new patient, returning patient and any extended visit, matching the price list on the site exactly.
- Availability rules so online booking only offers the slots you are happy to give away, and so a new patient cannot take a returning patient's shorter slot.
- Medical history and consent forms sent through the practice software rather than collected as free text on a website form. Health information belongs in the tool built for it.
- Reminders before the appointment, in your voice, with your address and parking note.
- Recalls after the visit, set at the interval you use, with a rebooking link. This is the setting that pays for the site.
- Notifications to a device somebody actually watches between patients.
Then book a test patient from your own phone, end to end, and cancel it.
Testing, and then testing again
Run the whole route on Safari and Chrome on both iOS and Android, and inside the Instagram and Facebook in-app browsers, because a good share of local clinic traffic arrives from a link in a bio. Check that the appointment type was preselected, the form submitted, and the confirmation arrived.
Repeat monthly. Platforms update their booking pages and integrations expire quietly, and you would rather find a broken step than hear about it from a patient who gave up.
Tracking
Add a booking_click event on every Book tap, with the page and appointment type as parameters, and a call_click on every tap-to-call. Once a month, compare taps by page against appointments in Dentally. That tells you which page fills the diary, and which one is read and abandoned.
Where this sits
Dentally is one of the platforms we wire into a hygiene clinic website, alongside Software of Excellence, Cliniko, Jane, Acuity and Square Appointments, and the pattern is the one we use across dental practice websites: one booking page, links from everywhere else, the phone always visible, tracking on every tap. Packages are on pricing. The software holds the diary. The site keeps the pages fast enough that people reach it.