Booking automation
If reservations reach you from several portals at once and somebody retypes them into a calendar by hand, this page is about your problem.
Where the trouble is
Booking portals do not talk to each other. Each one sends its own email, in its own layout, with the date written its own way. On top of that come the form on your website and the phone.
Somebody has to open all of it, read it and move it into one place. A dozen times a day, more in season.
The problem is not that it takes time. The problem is that now and then something slips through. And one lost booking is a customer standing in front of a closed gate, plus a Google review that stays there for years.
How I solve it
The system checks the inbox every few minutes, recognises the messages from each portal separately, pulls the data out of them and writes it into a spreadsheet and into the calendar at the same time. The website form travels the same route.
Four things decide whether a system like this deserves any trust:
A separate parser for each source. You cannot write one that understands both a table and a paragraph of prose. Adding another portal later means adding one entry to the configuration.
Duplicate detection by registration number and time. Portals sometimes send the same confirmation twice. A system that counts emails instead of bookings turns that into two entries.
Processed messages get their own label, not the "read" status. If somebody opened the email on their phone, the booking would drop out of the loop.
A notification instead of a silent failure. When a portal changes its email layout, and sooner or later it will, the system says it does not understand something. It does not guess and it does not pretend everything is fine.
What that means in practice
Bookings from several sources land in one calendar without retyping. Nothing goes missing on the way, because the system raises its hand whenever it is unsure.
This is running today at a car park by Katowice Airport: three sources, one calendar, no manual work.
What you do not see until it is running
Two portals count the same day differently. One gives the arrival time, the other the flight time. The difference is sometimes three hours and one free space that does not exist.
Cancellations come in by a different route than bookings. A booking is an email with a table; a cancellation can be a single sentence in a reply to the same thread. A system that only reads new messages will not see the cancellation.
A surname is not an identifier. Two Nowaks on the same weekend is normal, not an exception. Bookings have to be told apart by registration number and time.
I described this in more detail using the airport car park: the booking automation case study.
What it costs
Setup from 1 500 PLN. Ongoing care, under which I fix the system when a portal changes format, from 200 PLN a month.
I usually build this on Google Workspace, on tools you already pay for, so there is no extra subscription. Where a project calls for it, I build locally on your own machine instead.
How long it takes
The first working version usually stands after about two days, and then we refine it together until it fits the way you actually work. For the first stretch it runs alongside what you do now, so you can compare results instead of taking my word for it.