A booking that follows the data
A Singapore group of beauty, grooming and spa brands, moving onto a new point-of-sale system in 2021 and wanting one portal on top of it.
/work/spa-bookingCame in under strain
- System
- Customer portal for four brands, an installable web app
- Ask
- Book, change and buy across brands with one sign-in
- Region
- Singapore
The piece Four struts through five narrowing rings to a collar of seven teeth: four brands, five steps that narrow the search, a slot held for seven minutes.
- 7minutesslot held while the customer confirms
- 4brandsin one portal
- 2vendorsbuilding to our API design
- 3routesto single sign-on, each timed
The ask
A faster, simpler booking engine and one web app for four brands, with one sign-in shared with the online store.
The real problem
The old booking asked for a date first, searching every outlet and therapist on each tap and too often finding no therapist.
Treatments follow therapists and therapists belong to outlets, so the order of the questions decides how much the system searches.
Date first, then follow the data
- Idle
- Live
- Strain
- Fail
BeforeDate first: every outlet and therapist searched on each tap, and too often no therapist at the end.
AfterEach step narrows the next query, and the slot holds for seven minutes while the customer confirms.
What we built
We designed the APIs and the point-of-sale and data-exchange vendors built their side to that design. The booking runs treatment, outlet, then therapist and time, so each step narrows the next query.
Days with no roster are greyed out, so only real slots appear. An edit re-enters the flow at the step that changed and keeps the rest.
How we made it hold
We cut the scope so the portal could ship alone. The point-of-sale link and regional rollout became separate projects and single sign-on went to the group as three timed routes.
Backstage The decisions behind the build, and the hardest problem
Decisions
Ask in the order the data can answer.
Treatment and outlet first narrow the search before the calendar opens.
We design the APIs, the vendors build to them.
The point-of-sale and data-exchange vendors each built their side to one design.
Hold the slot from the summary page.
Seven minutes covers confirming details, logging in or signing up and a promo code.
Ruled out
Date and time as the first step.
It searches every outlet and every therapist on each tap.
The point-of-sale link and the regional rollout inside this scope.
Both became separate projects, so neither held up the portal.
The hardest problem
One sign-in with the online store needed an identity server that nobody owned. We drew the token flow between the store, an identity provider and the portal, then set out timed routes for the group to choose.
The difference
- One booking path for four brands, each step narrowing the next question to the point-of-sale system.
- The chosen slot is held for seven minutes while the guest confirms.
- Both vendors built against APIs we designed, so each system answers only what the portal asks.
