Moving one appointment used to move six other things by hand. — A case study
The ask becomes a record.
Before
A change request arrived as a message and sat there until somebody read it. Whoever picked it up retyped the details into Airtable and worked out, from memory, whether this client was allowed to make this change at all.
Now
The client has a portal. It only offers the changes their booking tier, the appointment's status and the days remaining actually permit, so a request that arrives is already a request that can be considered — and it arrives as a structured record rather than a sentence someone has to interpret.
- Client opens their appointment in the portal
- Policy decides what may be changed, and what needs approval
- The request is written against the existing appointment record
The record becomes a decision.
Before
Someone weighed the booking tier against the appointment's status and how many days were left, decided whether the change was allowed outright, needed approval, or had to be refused — and then recalculated the start time and any early-start fee by hand, against pricing rules held in their head.
Now
The same policy runs every time, in the same order, with the same answer. Start times and early-start fees are recalculated using the booking logic that already existed, and the appointment, its services, its pricing and its job records are updated together rather than one at a time.
- Tier, status, days remaining and artist assignment evaluated
- Allowed, needs approval, or restricted — decided by rule
- Start time and early-start fee recalculated from existing logic
- Appointment, services, pricing and jobs updated as one
The decision becomes everyone's Tuesday.
Before
The hard part was never the record. It was the people. A coordinator messaged every artist the change affected, waited for replies, chased the ones who did not answer, and could not move the booking forward until the last of them had. If an artist could not make the new time, the whole reassignment started again by hand.
Now
Every assigned artist is asked, and the workflow waits. It knows who has answered and who has not, and it only proceeds once all the required responses are in. If an artist cannot take the new time, their job is reassigned automatically so the appointment still goes ahead. Then the calendars move and everyone is told.
- Every affected artist is asked to approve the new time
- Responses are gathered; the workflow holds until all are in
- A job is reassigned automatically when an artist cannot make it
- Google Calendar updated for client and artists alike
- Email, SMS and Slack notifications go out
Makeup by Nida runs bridal, non-bridal, Halloween, hair and beauty services with a roster of artists. Changing a single booking's date touched artist schedules, calendars, pricing, job assignments and four different systems. We automated the whole appointment lifecycle so that the rules run instead of the staff.
The business books appointments that are then staffed by assigned artists. A booking is not one record: it is an appointment, the services on it, the pricing those services imply, and the jobs that put artists on the calendar. Change the date and every one of those has to change with it.
Before the automation, that change was coordinated by people. Someone read the request, worked out whether the client was even allowed to make it, recalculated what it cost, messaged each affected artist, waited, chased, updated the records, updated the calendars, and told the client. Every step was a place to be slow or to be wrong.
The system we built runs the appointment lifecycle end to end — booking, job creation, changes, cancellations, refunds, credits and vouchers — as workflows that execute the company's own policies automatically.
Built on
- Make
- The workflow engine. Every policy and every branch runs here.
- Airtable
- Appointments, services, pricing, jobs and artist records.
- Fillout
- The forms that capture requests and artist responses.
- Softr
- The client-facing portal built on top of the Airtable data.
Talks to
- Google Calendar
- Slack
- SMS
What changed
- Booking staff and artists no longer coordinate changes by hand
- Scheduling conflicts and transcription errors are designed out rather than caught
- A change request is resolved in the time the artists take to answer, not the time the office takes to notice
- The company's policies are applied the same way to every booking
- Airtable, Google Calendar and the notification channels stay in agreement
- Staff can see pending requests, approvals, denials and artist responses in one place
Something in your business runs on people remembering to do it.
That is the shape of every engagement like this one. Describe what currently takes a person and a spreadsheet, and you leave the first conversation with a scope, a budget and a ship date.