How bookings work

When somebody books time with you, RowFold writes a row in one of your tables. Everything else follows from that: the booking is on your scheduler because it has a date, in your reports because it is a record, and available to automations, views, exports and the API without any of that being built for bookings specifically. This article covers the whole round trip — the public page people book on, where the free slots come from, what happens the moment one lands, and how you change or cancel one afterwards. A booking is a row Everything else here follows from one fact: when somebody books time with you, RowFold writes a row in one of your tables. Not into a separate booking system you later have to reconcile. A row, in a table you can see, with columns you chose. That is why a booking arrives already useful. It is on your scheduler because it has a date. It is in your reports because it is a record. It can trigger an automation, appear in a filtered view, go out in a CSV, or be read through the API — and none of that had to be built for bookings. It works because a booking is not special. Two doors onto the same table There are two surfaces, and they are opposite ends of one thing. The booking page faces outward. It lives at a link you can send anyone, it needs no account, and it writes one booking at a time. Somebody picks a slot and a row appears. The scheduler faces inward. It reads the whole day back and lets you run it: a column per staff member, drag to move an appointment, check somebody in, fit the walk-in standing at the counter. Same table. Same rows. If you already have a booking page, the scheduler reads its settings and arrives configured, because that page has already answered the questions the scheduler needs to ask. What you need before you start One table for the bookings, with a date field that records a time of day. That is the only hard requirement. Beyond that, the more you link, the more you get back. In practice the link to the people who deliver the work is the one that pays off most: it gives you a column each on the scheduler and lets the page offer a choice of who. A link to your services gives you durations and prices. A link to your clients gives you a history you can open from any booking. A status column lets you check people in. None of it is mandatory. Leave the staff link off and the scheduler shows you a day instead of a column per person. Nothing breaks; it just does less. Where the free slots come from Availability is data, not a settings screen. There is an Availability table, and each row is a sentence: this person, this weekday, from this time to this time. So you edit opening hours in a grid, paste a whole season of them in from a spreadsheet, or have an automation close the shop — all the things you can already do to a table. Two kinds of row. A Working hours row adds time. A Time off row takes it away, and it can name a date, or a date range, or nobody at all — leave the person blank and it closes the whole business for a bank holiday. The page then subtracts the practical things, roughly in this order. It refuses slots that overlap a booking you already have. It adds any gap you want before and after an appointment, so a plumber gets travel time. It refuses anything sooner than your minimum notice, and anything further out than your booking window. What is left is what a visitor is offered. If they have not asked for a particular person, the page picks whoever has the lightest recent load rather than always the first name on the list. The moment somebody books A record lands in your table. That is the real event; everything else is a consequence of it. They get a confirmation email carrying a link that is theirs. From it they can move the booking to another free slot, cancel it, or add it to their own calendar. You do not have to do anything for any of that. If you set a reminder, RowFold sends one that many hours before. Your automations fire the same way they would for any new record, so a text message, a Slack post or a row in another table is a rule you write once. When you move or cancel one Drag an appointment to a new time on the scheduler, or use Reschedule to send it to another day. Drop it in another person's column and it is reassigned in the same movement. Two things happen here that are easy to miss. The booking keeps the length it was booked with. If a haircut was 90 minutes when it was booked, it stays 90 minutes when it moves, even if you have since changed that service to two hours. Bookings you have already taken do not shift under you. And 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?” If they gave a phone number they get a text too, naming both times, and it goes straight away even at night: a changed appointment can't wait for morning. A cancellation says who cancelled it. Both report back who was actually told — and where there was nobody to tell, because the booking carries no email, the scheduler says so rather than implying a message went out. Cancel booking sets your own cancelled status, whatever you happen to call it, so the booking stays visible as a cancellation rather than disappearing. If your table has no such status the record goes to Trash, where you can get it back. Nothing here deletes anything for good. Bookings that repeat A repeating booking is stored once, as a rule, and drawn for whatever period you are looking at. “Every Tuesday, forever” is literally true: no hidden end date, no cap on how many it will generate. Move or cancel one and you are asked how far the change should reach — just this one, this and every later one, or the whole repeat. Most of the time you want the middle one. It leaves everything before today exactly as it was. You are only asked when it could matter; a one-off booking just moves. Classes, and anything shared Twenty people at one yoga class is twenty rows at the same time with the same instructor. On an ordinary appointment table that reads as nineteen double-bookings. Give the view a capacity — a number saying how many the session takes — and it counts seats instead. Bookings sharing a slot stop being flagged, and only real problems remain: a class with more people in it than it holds, and one instructor booked into two different things at once. Booked by the night Cottages, rooms, boats and hire cars are booked in days, not hours. Give the view a start date and an end date that carry 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, not the last night. A cottage booked the 1st to the 8th is available on the 8th, and the next guest's bar starts in that same column. That is what every hotel means by check-out, and reading it the other way would report most of a busy month as double-booked. What it does not do yet Deposits, instalment ladders and no-show fees do work now, and the money goes straight to your own Stripe account rather than through RowFold. They need that account connected first, from the page’s Money card — until it is, the controls are not drawn and the page simply takes bookings without payment. Calendars are read, not written. RowFold can subscribe to an iCal feed from Airbnb, Vrbo or Booking.com so nights sold elsewhere stop being offered here, and it publishes a feed of its own. What it still does not do is write back into somebody’s Google or Outlook calendar; a visitor downloads a calendar file for their own diary. Booked by the night A cottage, a room, a boat or a pitch is not booked at a time, it is booked for a run of nights. Set a booking page's mode to Stays and the funnel changes: instead of a list of times, a guest sees two months of nights and drags a range across them. The departure day is free again. Somebody leaving on the 8th and somebody arriving on the 8th is a changeover, not a clash, so the 8th is still on sale — which is the same rule the Scheduler's stays chart draws with, and the same rule Airbnb and every other platform uses. It is worth knowing because it is the difference between selling that night and losing it. The two date fields are an arrival and a departure, and neither may record a time of day. That is not a limitation, it is what makes the booking land on the tape chart: a stay whose arrival carried an hour would drop out of the one view built to show it. Rates, minimum stays and check-in times Price is a number on the unit — the cottage, not a service — because in this mode the unit is the thing being bought. The page quotes rate × nights. Leave it unset and the page quotes nothing at all, which is right for enquire-only and much better than a confident £0 on a holiday let. Only a real number field can hold it. A Lookup would re-read its source every time the page rendered, so raising your rate would silently re-price stays that were already taken and paid for. Minimum stay is the setting most hosts reach for first — it is what stops a single night wrecking a weekend. A night that cannot fit your minimum is not offered as an arrival at all, though it is still sellable as part of a longer stay arriving earlier. Check-in and check-out times are printed on the page, the confirmation and the calendar invite; they change nothing about availability, because the whole arrival day and the whole departure day belong to that booking either way. Tips • Send the booking link to yourself and book something. It is the fastest way to see what a customer sees, and the row that lands is a real one you can then drag around. • Seed your Availability table once and forget it. A Time off row with nobody named closes the whole business, which is how you do bank holidays in one row. • Leave Minutes blank when booking by hand and the scheduler asks the service how long it takes — then keeps that answer, even if you change the service later. • The manage link in a confirmation email is doing real work: every customer who moves their own booking is one who did not phone you. • Guests change their dates themselves from the link in their confirmation — the same calendar, with their own nights given back so they can extend without colliding with themselves. The unit stays the same: different dates is not a different cottage. Good to know • No slots showing on the public page almost always means the Availability table is empty, or the working hours are there but nobody is on the roster. The designer says which of the two it is. • A date field with no time of day cannot host a booking page — a booking has to record an hour. Take bookings turns that on for you; wiring a page by hand, you set “Include time” yourself in the table's fields. • Deleting a booking page stops it taking new bookings immediately. Bookings already made are unaffected, and the links customers hold to change or cancel keep working. • “Nobody to notify” after a change means the booking has no email attached — usually one somebody typed in by hand. It is not a failed send. • A stay whose arrival field records a time of day will not bind. Turn Include time off for both the arrival and the departure — the designer says so, and says which field it means. • Already listed on Airbnb or Vrbo? Add each listing's calendar link under Calendars before you switch the page on, or the two calendars will happily sell the same night twice. Who can do what • Anyone with the public link can book — that is the point of it, and it is why the link is long and unguessable rather than a login. • Creating or changing a booking page is an admin action. It mints a public address, so it is not something a member does by accident. • The scheduler is readable by anyone who can see the table. Dragging, reassigning and setting a status each need write access to that particular field, and the control is simply absent where you do not have it. • A customer holding a manage link can move or cancel their own booking, and nothing else.