Aadhib

Case study · Active

Connecting online and in-person consultations in one booking system

An online appointment and a physical one look like different products. Treating delivery mode as a property of the appointment keeps them one.

Role
Architecture and delivery
Published
Reading time
1 min
Google MeetScheduling
01

Context

The practice runs both in-person and online consultations against the same finite availability. One person's time is the constrained resource, however the consultation is delivered.

02

Problem

The tempting implementation is two flows — book online, book in person — which immediately produces two availability calculations that can disagree, two reschedule paths, and staff having to check both to know what the day looks like.

03

Constraints

01
One calendar, two modes
Availability is a property of the practitioner's time, not of the delivery method.
02
Different day-of behaviour
An online appointment needs a link. An in-person one needs a queue position. The divergence is real but late.
03
Staff need one view
Whoever is running the day should not have to reconcile two systems to know who is next.
04

Approach

I made delivery mode a property of the appointment rather than a fork in the product. Booking is identical up to the point where the mode is chosen; after that, an online appointment attaches a Google Meet link and an in-person one enters the physical queue. Everything before that divergence is shared.

05

Architecture

Shared availabilityOne calculation over the practitioner's time, regardless of mode.
Appointment with delivery modeThe single point of divergence. Everything upstream is shared.
Online pathGoogle Meet link generation and delivery.
In-person pathCheck-in, queue position, waiting display.
06

Solution

A single booking flow where mode is a choice within the appointment rather than a separate product, giving staff one view of the day and visitors one consistent experience regardless of how they attend.

Why two flows is the expensive option

It looks cheaper. Each flow is simpler on its own. But availability now has two implementations, rescheduling has two paths, and staff have two places to look. Every subsequent change has to be made twice, and eventually is not.

07

Lessons

  1. 01Find the real point of divergence and share everything before it. Two flows that are 80% identical will drift apart, and the drift is where the bugs live.
  2. 02Availability belongs to the resource being booked. Attaching it to the delivery method guarantees two sources of truth.
  3. 03The staff view is the test. If running the day requires checking two places, the model is wrong regardless of how clean the visitor flow looks.

Stack

What it runs on

Google MeetScheduling

The project

01Consultation booking platform
SYSTEM NOTEBuilding software for receptionists, guards, hosts and admins at the same time
All case studies