A clinic site that takes the booking, not just the call.
A busy dental practice needed the enquiry captured before the visitor left the page — tagged with the treatment the patient chose, and routed somewhere the practice actually reads. The build pairs a validated intake form with a WhatsApp hand-off that arrives already knowing what the patient asked for, and a dashboard that lays out the follow-up pipeline from first enquiry to treated.
Healthcare · dental practice · India
Healthcare & Clinical Operations Engine, captured from the production build. Identifying details are redacted and the deployment is not linked.
System pipeline
CaptureAppointment form
QualifyMobile-number pattern
RouteWhatsApp hand-off
TrackSummary tiles
Be foundDentist
section handoff
The problem
What the build had to solve.
01
Enquiries arrived by phone during treatment hours, when nobody could answer.
02
A dental audience searches by treatment — implants, root canal, orthodontics — not by clinic name.
03
The practice serves a bilingual catchment, so the page had to set Devanagari as competently as Latin.
section handoff
Architecture
How an enquiry moves through it.
Capture
Qualify
Route
Track
Be found
1
Capture
A structured, treatment-led intake sits in the page rather than behind a mailto link, so the enquiry is typed — and tagged with the treatment the patient chose — while intent is highest.
Appointment form
Treatment selector
Preferred date
2
Qualify
The form validates an Indian mobile number and requires an explicit consent tick before it will submit, so what leaves the page is reachable and permissioned.
Mobile-number pattern
Consent checkbox
Honeypot spam trap
3
Route
Click-to-chat links carry an intent-specific pre-filled message, so the thread opens with the reason for contact already written.
WhatsApp hand-off
Direct dial
Maps directions
4
Track
A separate dashboard turns captured enquiries into a worked pipeline — four summary tiles, two charts, and a kanban running the six statuses from new enquiry through treated and follow-up to closed.
Summary tiles
Pipeline by status
Leads by source
Kanban board
5
Be found
A Dentist entity graph publishes the practice, its hours, its coordinates and its treatment questions in a form search engines and assistants read directly.
Dentist
FAQPage
OpeningHoursSpecification
GeoCoordinates
section handoff
The build
What it is made of.
Every row was read off the deployed build at inspection, not from a project brief; the decisions below give the date each was checked. The deployment is not linked, because the business is not named.
Delivery
Static HTML, single document
Hosting
Vercel edge CDN
Motion
GSAP with ScrollTrigger
Typefaces
Serif display faces, a sans body face, and a Devanagari face
In-page form, WhatsApp click-to-chat, direct dial, Maps directions
CRM dashboard
Chart.js charts, six-column kanban, appointment list — seeded data
section handoff
Engineering decisions
The choices, and why they went that way.
The phone field validates the format the practice can actually ring
A booking with an unreachable number is not a booking. The field constrains input to a valid Indian mobile — ten digits opening 6–9, with an optional country code — and explains the rule in place instead of failing silently after submission.
Verify: Read from the production booking form on 2026-08-07: the phone input carries a pattern attribute, a numeric inputmode, and its own error message element.
A honeypot, not a CAPTCHA
A public clinic form attracts bot submissions, and a CAPTCHA taxes every real patient to stop them. An off-screen field that humans never see and scripts routinely fill costs the patient nothing and drops the automated traffic.
Verify: Read from the production booking form on 2026-08-07: a visually hidden, aria-hidden field with tabindex -1 and autocomplete off, labelled to be ignored.
Consent is a gate, not a footnote
The practice contacts patients on WhatsApp afterwards. Making the tick a submission requirement means every record it holds was volunteered on the record, rather than assumed from a pre-checked box.
Verify: Read from the production booking form on 2026-08-07: the consent checkbox is required, and the form will not submit without it.
The CRM dashboard ships with invented patients, on purpose
The dashboard is reachable at a public URL with no login. Seeding it with real enquiry records would have made a demonstration surface into a data-protection exposure — names, phone numbers and treatments for identifiable people, served to anyone who guessed the path. Fictional records make the surface reviewable without putting a single real patient on the open web. The constraint the page is actually under is privacy, not fidelity.
Verify: Read from the production dashboard on 2026-08-07: invented patient names, placeholder numbers and sequential record IDs throughout.
The dashboard is not linked from the public site
It is an internal surface for the practice, not a page for patients, so it earns no navigation entry and no sitemap presence. Reachable by URL for whoever is given it; absent from the path a visitor takes.
Verify: Searched in the production site’s source on 2026-08-07: the public pages contain no reference to the dashboard’s path — zero matches.
Devanagari is loaded as a first-class face
Serving Hindi through a fallback renders it visibly worse than the English beside it. Noto Sans Devanagari ships alongside the Latin faces so both scripts are set deliberately.
Verify: Read from the production document on 2026-08-07: the Google Fonts request includes Noto Sans Devanagari with the Latin families.
section handoff
Business outcome
What we can prove, and what we cannot.
Not publicly disclosed.
No business outcome has been measured against a stated method and confirmed with this client, so no figure is published. We would rather show you the system and let you judge it than print a number nobody verified.
section handoff
Questions
About this project.
What did SheetFlow build for this dental practice?
A treatment-led clinic website with an in-page appointment intake, WhatsApp click-to-chat hand-off carrying a pre-filled message, direct dial and map directions, and a structured-data entity graph describing the practice, its opening hours and its treatment questions — plus a CRM dashboard that tracks every enquiry from first contact to treated. The practice is not named and the deployment is not linked, at SheetFlow’s decision.
How does the appointment booking work?
A visitor selects a treatment, gives a name and mobile number, optionally picks a preferred date, and ticks a consent box. The number is validated against Indian mobile format before submission, and a hidden honeypot field drops automated submissions. Visitors who prefer to message instead get a WhatsApp link that opens with the reason for contact already written.
What does the clinical operations CRM dashboard do?
It turns captured enquiries into a worked pipeline: four summary tiles covering total leads, this month, converted and pending follow-up; a bar chart of the pipeline by status and a pie chart of leads by source; a kanban running the six statuses from new enquiry through treated and follow-up to closed; and an upcoming-appointments list. Every record on it is seeded demonstration data, not a real patient — the page is publicly reachable with no login, so fictional records are what keeps a demonstration surface from becoming a privacy exposure.
What business results did this project produce?
Not publicly disclosed. SheetFlow publishes outcome figures only once they have been measured against a stated method and confirmed with the client in writing. No such measurement has been published for this project, so no figure is claimed.