Dental practice · Agra

A clinic site that takes the booking, not just the call.

Saraswati Dental needed the enquiry captured before the visitor left the page — and routed somewhere a busy practice actually reads. The build pairs a validated intake form with a WhatsApp hand-off that arrives already knowing what the patient asked for.

Visit the live siteDental practice · Etmadpur, Agra
Saraswati Dental Clinic homepage — an editorial hero reading “Your Smile, Our Masterpiece.” above a Hindi subhead, with the clinician’s name and registration number.
Saraswati Dental Clinic, captured from the live deployment at saraswati-dental-clinic.vercel.app.
Saraswati Dental Clinic CRM dashboard — four summary tiles for total leads, this month, converted and pending follow-up, above a bar chart of pipeline by status, a pie chart of leads by source, and a kanban pipeline.

CRM dashboard, captured from saraswati-dental-clinic.vercel.app/dashboard.html.

Every lead, name and number on this dashboard is seeded demonstration data — “Priya Sharma”, sequential placeholder phone numbers, IDs running SDC-001 onward. That is deliberate and it is the right call: the page is publicly reachable with no authentication, so real patient records here would be a data-protection exposure rather than a better demo. Read it as a working surface, not as a real pipeline.

The problem

What the build had to solve.

  • Enquiries arrived by phone during treatment hours, when nobody could answer.

  • A dental audience searches by treatment — implants, root canal, orthodontics — not by clinic name.

  • The practice serves a bilingual catchment, so the page had to set Devanagari as competently as Latin.

Architecture

How an enquiry moves through it.

  1. Capture

    A structured intake sits in the page rather than behind a mailto link, so the enquiry is typed 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 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
The build

What it is made of.

Every row was read off the running deployment, not from a project brief. Open the site and view source to check any of it.

Delivery
Static HTML, single document
Hosting
Vercel edge CDN
Motion
GSAP 3.12.5 + ScrollTrigger
Typefaces
Playfair Display, Cormorant Garamond, Inter, Noto Sans Devanagari
Structured data
Dentist, FAQPage, AggregateRating, OpeningHoursSpecification, GeoCoordinates, PostalAddress
Contact channels
In-page form, WhatsApp click-to-chat, direct dial, Maps directions
CRM dashboard
Chart.js 4.4.1, six-column kanban, appointment list — seeded data
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: View source on the booking form: 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: The form contains 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: The consent checkbox is required; 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: Open the dashboard and read the records: “Priya Sharma”, sequential placeholder numbers, IDs running SDC-001 onward.

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: The public site contains no reference to dashboard.html — search the source and there are 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: The Google Fonts request includes Noto Sans Devanagari with the Latin families.

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.

Questions

About this project.

What did SheetFlow build for Saraswati Dental Clinic?
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. The site is live at saraswati-dental-clinic.vercel.app.
How does the appointment booking work on the Saraswati Dental site?
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 Saraswati Dental 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 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 the Saraswati Dental 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.