Bookings & scheduling

Take the booking.
Then actually run the day.

Most booking tools give you a page that collects appointments and a calendar that shows them. RowFold gives you those, and then keeps the booking as an ordinary row in your own table — so it is in your reports, your filters, your automations and your exports without anyone building that part.

Watch it instead · 2 min A page they book on. A day you can run. The page · What they see · It's a record · Run the day · When it moves

01A booking is a row

When somebody books time with you, RowFold writes a row in one of your tables. Not into a separate booking product you later reconcile against your real data. A row, in a table you can see, with columns you chose.

Everything else follows from that. The booking is on your scheduler because it has a date. It is in your reports because it is a record. It can fire an automation, sit in a filtered view, go out in a CSV or come back through the API. None of that had to be built for bookings. It works because a booking is not special.

Plain English: the thing you book is the same thing you report on. Nothing to export, nothing to keep in step by hand.
A Bookings table in RowFold. Each appointment is a row, with the client, service, staff member and location as linked chips and the start as an ordinary date column.
A booking is a row on a table you chose. The client, the service and the stylist are links to other tables — which is what puts the booking in every report and filter you already have.

02Two doors, one table

There are two surfaces, and they are opposite ends of one thing.

SurfaceWho it is forWhat it does
Booking pageAnyone with the link. No account.Shows the free slots and writes one booking.
SchedulerYou and your teamReads the whole day back: a column per person, drag to move, check people in.

Same table, same rows. If you already have a booking page, the scheduler usually arrives configured — it reads that page's settings — it does not ask you a second time which link is the staff member and which is the client, because the page already answered that.

A public booking page: the service and staff already chosen on the left, the soonest appointment offered at the top, a week of days with how many slots each has free, and a grid of times.
Door one, as a customer sees it. One question per screen, the soonest free time offered outright, and a line at the bottom saying whose clock the times are on.

03Availability is data, not a settings screen

Your opening hours live in a table. Each row is roughly a sentence: this person, this weekday, from this time to this time. Which means you can edit them in a grid, paste a season of them in from a spreadsheet, or have an automation close the shop, using the things you already know how to do.

Two kinds of row. A Working hours row adds time. A Time off row takes it away, and can name a single date, a range, or nobody at all — leave the person blank and it closes the whole business for a bank holiday, in one row.

From there the page subtracts the practical things: slots that overlap a booking you already have, the gap you want either side of an appointment, anything sooner than your minimum notice, anything further out than your booking window. What is left is what a visitor sees. If they have not asked for a particular person, it offers whoever has the lightest recent load rather than always the first name on the list.

The availability table as a grid: one row per person per weekday, with From and To times, a Kind column reading Working hours, and a Time off row covering a whole day.
The opening hours, as rows. Each is a sentence — this person, this weekday, these hours — and the first one here is a day off, which is the same table saying the opposite thing.

04Running the day

Taking the booking is the easy half. The scheduler is the other one: a day laid out as a column per staff member, room or chair, including the people with nothing booked, because an empty column is usually the one you want to fill.

Click an empty slot to book it. Drag an appointment to move it, or into someone else's column to reassign it in the same movement. Drag its bottom edge to change how long it runs. Down the side, a short list of the things that actually need a decision: bookings with nobody assigned, and anyone double-booked. Both are worked out from the data rather than from a status somebody has to remember to set, so the number is always real.

One day on the scheduler: a column per stylist, appointments as coloured bars at their real times, each showing the client and the service.
Door two, the same rows read as a day. A column per person, including anyone with nothing booked — an empty column is usually the one you are trying to fill.

05Moving one, and who gets told

Two things happen when you move a booking, and both are easy to take for granted until they go wrong somewhere else.

It keeps the length it was booked with. A haircut booked when that service was 90 minutes stays 90 minutes when you move it, even if you have since changed the service to two hours. Bookings you have already taken never shift under you, which is what makes last quarter's schedule still true.

The customer is told. A moved booking sends an email showing the old time struck through above the new one, because the first thing most people think is “was that always when it was?” A cancellation says who cancelled it. And both report back who was actually told — if the booking has no email on it, you are told nobody to notify rather than being left to assume a message went out.

Cancelling sets your own cancelled status, whatever you happen to call it, so the booking stays visible as a cancellation instead of vanishing from the day it was on.

06Repeats, classes, and things booked by the night

A repeat is stored as a rule, not as a thousand rows. “Every Tuesday, forever” is literally true: no hidden end date, no cap. Change one and you are asked how far it should reach — just this one, this and every later one, or the whole repeat — and the middle answer leaves everything before today exactly as it was.

A class is not a double-booking. Twenty people at one yoga session is twenty rows at the same time with the same instructor. Tell the view how many the session holds and it counts seats instead, so only the real problems are left: a full class, and an instructor booked into two different rooms.

Some things are booked by the night. Cottages, rooms, boats, hire cars. Give the view a start date and an end date with no time of day and it becomes a chart with a row per unit and a column per day. The end date is the day the unit comes free again, so a guest leaving on the 8th and one arriving on the 8th sit side by side rather than reading as a clash.

07What it does not do

One real gap, and one thing worth being precise about. Finding either later is probably worse than reading it now.

  • Bookings go onto a Google calendar, and not yet onto an Outlook one. A connected staff calendar, Google or Outlook, blocks the slots that are already busy, and an iCal feed from Airbnb, Vrbo or Booking.com stops nights sold elsewhere being sold again here. With a Google account connected, a page can also put each booking it takes on that calendar as an event: it moves when the booking moves, goes when the booking is cancelled, and invites the person the booking is with. RowFold cannot write to an Outlook calendar yet, and a visitor still downloads a calendar file for their own diary.
  • Deposits go to your Stripe account, which means you need one. A deposit, an instalment ladder or a no-show fee can be attached to a page, and the money never passes through RowFold — so refunds and disputes stay in your own dashboard. Until that account is connected the page simply takes bookings without payment.

Next: a workspace already shaped for this, the helpdesk (same scheduling engines, a support face), or what it costs. Bookings are part of RowFold, not an add-on with its own price. There is a longer walkthrough — Take bookings — in the help centre once you are signed in.