To manage WhatsApp bookings alongside your website, use one availability record for each departure and a clear rule for when places become reserved. A chat message expressing interest should not be treated as a confirmed booking. Every team member must check and update the same record before promising space.
The problem usually appears when one person answers messages while another handles online sales. Both can give a correct answer based on an outdated view of the last available places.
Separate an enquiry, a temporary hold and a confirmation
- Enquiry: the guest has asked about a date. No capacity has been allocated.
- Temporary hold: places have been set aside until a stated deadline, if your process supports holds.
- Confirmed booking: the agreed confirmation conditions have been met and the capacity record reflects it.
These are operational definitions to agree with your team. Match them to the states your booking tool actually supports. Do not use an informal hold in WhatsApp unless someone also records it in the availability source and knows when to release it.
Choose one of two routes for WhatsApp enquiries
Route A: direct the guest to the booking page. Answer their question, then send the link for the correct activity. Ask them to check the date, departure time and participant count. Confirmation should come from the completed booking process, not from an earlier chat promising space. Once the booking is recorded, prepare the booking confirmation using the same details.
Route B: enter the booking for the guest. If your tool supports staff-created bookings, check availability and record the booking before confirming in WhatsApp. If it does not, define a controlled alternative with the person managing availability. Do not assume that reading or replying to a message updates online capacity automatically.
A practical example with the final places
Illustrative example: a departure has two places left and a WhatsApp guest asks for two tickets. While the conversation continues, someone else may book online. Under Route A, send the booking link and explain that availability is confirmed through that process. Under Route B, allocate the places in the shared system before telling the guest they are secured.
If you offer a temporary hold, give a specific expiry time and time zone. On expiry, check whether the booking or payment was completed before releasing the places. Do not leave that decision to memory.
What the team needs to record
Keep the booking reference, activity, local date and time, number of participants, status and person responsible. Record the payment status separately: a confirmed place and a fully paid booking are not always the same thing. Link the conversation to that reference rather than creating a second booking to track a new message. A confirmed place may still have an unpaid balance; define how to record the deposit and outstanding balance.
At handover, review unresolved holds, date changes and cancellations. Apply each change once to the shared availability record and then communicate the result to the guest.
Test your booking workflow before relying on it
Use a test environment or a test departure that cannot be bought by real guests. Check what happens to capacity when a booking is pending, confirmed, cancelled or moved to another time. Ask your provider to demonstrate the exact cases you need; do not assume all systems treat pending bookings equally.
Our guide to choosing a booking system helps prepare that review. Explore TurIA — Booking System for tours and excursions and discuss your existing WhatsApp and website workflow before changing how your team confirms places.