Client Booking App

This page describes a representative booking app for a clinic-style business. The client is not named. We do not publish a no-show rate, before or after. The work was an iOS and Android app for scheduling, reminders, and payments, and it is also a note on when an app is the wrong spend.

The situation

Appointments lived in a book and in WhatsApp messages. Reminders were a person sending texts in the evening. Payment was collected at the desk, and a cancelled slot was visible only to whoever had the book that morning. Clients asked for "an app" because a competitor had one. That is a weak reason to fund two store listings, and we treated it as a question, not as a decision.

The question was whether the client would install something, or whether they only needed a link that opened on the phone they already had. For this business the repeat visit was the product. People booked again, they forgot, and the front desk spent the first hour of the day rebuilding the schedule from chats. A mobile site could show slots. It would not sit on the home screen or send the reminder the business actually needed. An app was the right spend here. It is not the right spend for a shop that sells once.

What we took on

We designed the mobile app around three screens a client will use: book a slot, see what is coming, pay what is due. Staff got a different login: today's list, a cancellation, and a note on the visit. We did not build a social feed, a points club, or a chat that would compete with the WhatsApp thread they were trying to leave behind.

Scheduling rules were written down before any screen. How long a visit is. How late a client may cancel. Which practitioner can cover which service. What happens to a paid booking if the day is closed. Those rules were the product. The stores were the delivery.

Reminders go out from the server, not from someone's phone, at a time the business chose. The message says the time, the place, and how to change the booking. A reminder that only says "see you tomorrow" creates a call.

What shipped

Clients install the app, create an account with the phone number the desk already knows, and book from the slots the diary marks open. Payment uses the gateway the business already had for other work, so finance did not learn a second payout report. Staff see the same booking on a simple day list. A cancellation returns the slot. The paper book stayed for two weeks as a check, then stopped being the diary.

What we refused

We did not promise fewer missed appointments as a number. A reminder can only work if the phone number is right and the client reads it. We did not put clinical notes in the client app. We did not ship Android first and leave iOS as a later surprise when half the clients were on iPhones. Both stores were part of the release plan, including the review time each store takes, which is not something we control.

What a similar project needs from you

Your real services and durations, not a rounded menu. The payment account. One front-desk person in the first workshops. A written rule for cancellation. If you are unsure an app is justified, start with the note on when a mobile app is the wrong spend, then the mobile app page. We would rather build a site than a store listing you will not maintain.