I’m trying to build an automation for a private airport transfer business, that can handle new booking enquiries and route the information to the right place automatically.
What is the problem & what have you tried?
The idea is to capture customer details such as pickup location, destination, travel date, passenger count, and contact information, then send the booking data to a spreadsheet or CRM and notify the relevant team.
I’ve been looking at using webhooks and Make modules for this, but I’m unsure about the best way to structure the scenario, particularly when some booking fields are missing or need validation before the data is passed to the next step.
Has anyone built a similar workflow for a booking or transportation business? I’d appreciate suggestions on the best scenario structure.
Error messages or input/output bundles
No specific error at the moment. I’m mainly looking for advice on designing the workflow correctly before putting it into production.
Hi, I’ve done something similar for a client. What worked for me: webhook first, then a router right after it. One route checks that the key fields (pickup, destination, date, passengers, a phone or email) aren’t empty and that the date isn’t in the past. Everything that passes goes on to your sheet or CRM and the team notification. Everything that fails goes to a separate “to review” tab and sends you or the customer a message asking for the missing info.
I’d also clean the data before saving it (trim the text, fix the date format with parseDate), otherwise the sheet gets messy fast. And a quick search on email + date to catch double submissions, people love clicking submit twice.
Last thing, put an error handler on the CRM/sheet module so a temporary API hiccup doesn’t lose a booking, and finish with a Respond to webhook so your form gets a clear answer.
For testing, send a deliberately incomplete payload through the webhook, that’s the quickest way to check the fallback route works.
Hi, you need a Make automation that captures airport-transfer bookings and routes only valid enquiries to your spreadsheet or CRM and the right team.
I will start with a webhook that receives pickup, destination, travel date, passenger count, and contact details. A validation step will hold incomplete or invalid bookings for follow-up before any data is written. Complete bookings will be saved to your spreadsheet or CRM, and the relevant team will be notified. I will lock the scenario structure with you before anything goes live.
One transport-specific detail I’d add to Lionel’s structure: email + date can accidentally merge two legitimate journeys, such as an outbound and return trip on the same day. Give each enquiry its own submission_id, retained when the form retries.
Keep that enquiry saved, but don’t dispatch it or send a booking-confirmed message. An acknowledgement could say: ‘We received your enquiry; availability is not yet confirmed.’ Move it to ready_for_review when the missing contact arrives, and only to confirmed after availability is checked.
Four useful tests before launch:
• Same submission_id twice → one enquiry.
• Same email/date, different submission_ids for two journeys → preserve both; flag suspected duplicates for review.
• Blank contact or passengers=0 → needs_review, no dispatch.
• CRM save succeeds but team notification fails → retry the notification against the saved enquiry ID, not the entire create-booking step.
For a small single-scenario prototype, a Make Data Store can hold the submission ID and status. Instant webhooks run in parallel by default, so a search-then-create duplicate check can race; consider ‘Process data in order’ for that prototype. Other writers still need their own duplicate protection. Official references: Data stores - Help Center and Webhooks - Help Center .
Also keep pickup time separate from flight arrival time; a midnight arrival is an easy way to get the booking date wrong.
Lionel’s outline is a good starting point. One thing I’d settle before building the routes is what counts as a booking versus an enquiry. If a valid form submission is saved but the team notification fails, should the customer see “booking confirmed,” or only “request received”?
I’d give each submission an ID, check for duplicates before creating another record, and keep a clear status such as needs details, received, or confirmed. Then test three cases: missing details, a double-click submission, and a failed CRM/sheet write. That should reveal whether the fallback and response messages match what actually happened.
Is the form meant to confirm transfers automatically, or does someone on your team approve availability and price first?
I think the rest of the comments hit the nail on the head here. From a UX point of view, I’d also try to show an approximate price to the person who submits the request. If necessary, use Google Maps API to get the distance between the pickup and the destinatino to get the distance, or show a price based on areas.
Also, try adding critical validations to the form UI. If a submission doesn’t have a required field to process the enquiry, it might be better to show an error message and let teh perosn add the data, rather than keep an incomplete entry in CRM/sheet
I’d structure this as a validation-first workflow rather than sending the booking data directly to the CRM or spreadsheet.
For example, the webhook can receive the enquiry, then use a validation step to check the required fields such as pickup, destination, travel date, passenger count, and contact details. From there, you can use a Router in Make to separate complete bookings from incomplete ones.
Complete bookings can continue to the CRM/spreadsheet and trigger a notification to the relevant team. If anything is missing or invalid, route it to a separate path that can request the missing information instead of creating an incomplete booking.
I’d also recommend adding some basic checks for things like valid dates, passenger count, and duplicate enquiries before the data reaches the CRM. This keeps the main workflow cleaner and makes it easier to troubleshoot later.