Coper Lab

SmileGrid — multi-branch dental booking

A working booking demo where booking rules shape the options shown — including available times, alternatives when a day is full, and self-service booking lookup.

Project type
Coper Lab
Capabilities
Create · Automate
Built with
Next.js · TypeScript · Tailwind CSS

Coper Lab

A working demonstration built by Coper. It runs on demonstration data, it was not commissioned by anyone, and the organisation it describes does not exist.

Why this project exists

Most appointment businesses take bookings through a form that is really a request: someone names a time, someone else checks the diary, and a call goes back and forth. The calendar is not the hard part. The rules around it are.

  • A customer who is ready to book cannot see what is actually available
  • What is bookable depends on the service, the location, the length and who is free
  • Anything the form cannot answer becomes a phone call for staff to sort out

Walkthrough

How the flow works

  1. The SmileGrid landing screen, headed "One system, three clear jobs", offering Book appointment, Manage booking and Admin dashboard.

    Three jobs, one system

    Patients book, patients manage their own booking, and staff run the clinic network.
  2. Step one of the booking flow, "Choose a clinic", listing branches with their next available time and booking rules beside a five-step progress panel.

    Start with the right clinic

    Each branch shows its next available time and its own booking rules before anything is asked for.
  3. Step three of the booking flow, showing generated appointment times with the dentist for each, and a separate panel of alternative times at other branches.

    Real times, and a way round a full one

    Times come from the branch and dentist rules. Where the clinic is tight, other branches are offered separately.
  4. The SmileGrid self-service screen, "Find your booking", with a booking-reference field and a panel listing what a patient can do next.

    Find a booking without calling

    A booking reference opens the booking so it can be moved or cancelled.

Rules first, then the calendar

The clinic's own rules — opening hours, treatment length, who is free, how far ahead — decide which times a patient is offered. Everything else is built on that.

  • A guided flow that asks for personal details only after a time is chosen
  • Times generated from branch hours, dentist availability, treatment length, blocked periods and lead times
  • Alternatives at other branches when the chosen clinic or date is too tight
  • Self-service lookup, reschedule and cancel from a booking reference
  • A staff console for the day's appointments, schedules, slot controls, branches and dentists

Software around the workflow, not the other way round

Generic tools make a business fit its process to the software. Build around the workflow instead and customers get a simpler journey.

  • What a customer is offered comes from the business's own rules, not a generic calendar
  • A full day offers somewhere else rather than a dead end
  • Simple booking tasks stop depending on somebody picking up the phone
  • No integration is built here — the workflow is structured so a later one can build on the same foundation

Not just for bookings

The same approach can work for quotes, applications, reservations, service requests and other processes your team still handles by hand.

Build the workflow properly first, and future automation has something solid to build on.

Capabilities

What this project covers

  1. CreateBuild what your business needs
  2. AutomateSave time and run your business better

Evidence

What this shows

Directly observable

  • The patient flow was driven end to end through branch, treatment, generated availability and patient details, and captured
  • Slot availability shown in the capture is generated from the demonstration branch and dentist rules, not a fixed list
  • Every staff console screen renders against the same demonstration data

What we are measuring next

There is nothing to measure. SmileGrid is a Coper Lab rather than a clinic deployment, so no booking volume, no-show rate, staff time or revenue figure has been observed, and none is claimed.

Under the hoodThe full list of what was built, and what we are not claiming

Everything this included

  • A guided booking flow that asks for one thing at a stage, and for personal details only after a time is chosen
  • Slot generation from branch opening hours, dentist availability, treatment duration, blocked periods, emergency reserves and lead-time rules
  • Alternative suggestions at other branches when the selected clinic or date is too constrained
  • Self-service lookup, reschedule and cancel from a booking reference, with the released slot returned to availability
  • A staff console for appointments, the branch schedule, slot controls, branches, dentists and reporting
  • A guided presentation mode for walking somebody through the system

What is not claimed

  • SmileGrid is not a real business. The name, the branches, the dentists and the bookings are invented, and no clinic has used it
  • It runs on demonstration data held in the browser — no database, no payment step, no notifications, and no integration with any practice-management or clinical system
  • Nothing here measures a business result. No booking volume, conversion, no-show rate, staff time or revenue figure has been observed, and none is claimed
  • The staff console is not pictured. Its screens carry invented figures against invented patient names, and publishing them would put meaningless numbers on the page
  • Delivering this for a real practice would start from that practice's own rules, systems and obligations

Related

The services behind this work

  • Service

    Custom Software & Digital Platforms

    Web applications, internal platforms, portals and dashboards — built when the process is genuinely yours, and deliberately not built when an existing tool would do.

  • Service

    AI & Business Automation

    Enquiry handling, lead qualification, follow-up, scheduling and reporting — wired across the systems you already run, with AI used only where language or judgement genuinely helps.

If you are working out whether something along these lines is worth building, we are happy to talk it through — including the parts that would not be worth doing.

Discuss a project