Let people confirm the meeting point and the cancellation rule before they book
Tour pages are read by people who are almost ready and still uneasy. They need the start time, where to stand, what happens if it rains, what a child costs, and which bag is too big. Those facts are often split across an itinerary, a FAQ, and a booking footnote.
WebsiteChat answers from the public pages you connect, in the visitor’s language when that support is enabled, and from text-selectable PDFs on eligible plans. It does not see a live seat map or a reservation system.
The detail that decides a booking is rarely on the first screen
Travel questions pile up before checkout because the product is a set of conditions, not a single price. Guests also arrive in more than one language.
Itinerary, meeting point, and “not included” live on different URLs
A guest can like the photos and still not know where to be at 8:15, or that lunch is extra.
Weather and cancellation are the questions that block payment
“Does it run in the rain?” and “when does the fee start?” decide the booking. If they are buried, the tab closes.
Child prices and luggage rules are easy to misread
Age bands and bag limits are precise. A helpful paraphrase that rounds them is worse than quoting the page.
International guests are reading a site that was written for locals
They still need the same operational facts. Translation of the site is a separate project; answering from the pages you published is the job here.
Questions people ask before they reserve a seat
These show up in the hour before someone commits. None of them require a live inventory feed if the page already states the rule.
- Does the tour still run if it rains?
- How much is a child’s ticket?
- Where is the meeting point?
- When does the cancellation fee start?
- Can I bring a large suitcase?
- What time does the tour depart?
- Is lunch included?
- Are there seats left this Saturday?
Pull itinerary, meeting point, and cancellation into one reply
Guests should be able to ask across the pages you already wrote, then go to your booking page to confirm a seat.
Crawl every page that changes a yes
Itineraries, meeting maps, price tables, packing notes, and cancellation terms all matter. A photo gallery alone will not answer them.
Add the PDF guests already receive
A text-selectable terms sheet or departure brief can be included on eligible plans. The assistant should not invent a weather call that the document does not make.
Answer in the visitor’s language from your sources
Multilingual replies still have to come from the pages and documents you connected. They are not a promise that every page has an official translation.
Send availability to the booking step you published
If the site does not show live seats, the chat must not invent them. Point to the booking page or the contact path so the guest can confirm.
Live seats and weather calls stay with the operator
Published rules can be repeated. Real-time operations cannot be guessed.
- Do not claim a departure has seats left unless that status is on the page you connected
- Do not decide on the morning of the tour that it is cancelled or still running if the site only gives a general rain policy
- Do not change child age bands, luggage limits, or what is included
- Do not promise a refund amount beyond the cancellation table
The checks that happen between “looks good” and “book”
The booking itself stays on your reservation page. The chat is the pre-check.
A family pricing the day before they pay
Two adults and a child. The reply uses the published age band and price, then links to the booking page for the date.
Rain in the forecast
If the page says the tour runs in light rain and stops for storms, that is the answer. The chat does not look at tomorrow’s radar.
A guest with a suitcase and a train to catch
Luggage limits and the meeting point come from the departure notes, including the “not included” line if it changes the plan.
A cancellation the week before
The fee table is quoted by the dates you published. The chat does not process the cancellation.
Crawl the tour pages, then ask the questions guests actually send
One pretty landing page is not enough if the rules live in a PDF or a second URL.
- 01
Create the tour site
Use the operator name guests will recognize on the widget.
- 02
Crawl itineraries and terms
Include meeting points, prices, inclusion lists, and cancellation pages, not only the photo story.
- 03
Upload the departure PDF if guests rely on it
Text must be selectable. Keep the file that matches the tours currently on sale.
- 04
Set a greeting about practical details
Invite questions on weather, children, luggage, and where to meet.
- 05
Install it on the tour and booking pages
That is where the last doubts show up.
- 06
Test a Saturday seat question
The reply should send people to your booking page instead of inventing availability.
Confirming a rainy-day plan from the page, not a live board
The sample quotes a policy and refuses a live seat count.
If it rains, do you still go? And is there space on Saturday?
The tour page says departures run in light rain and stop only for a storm warning. Saturday availability is not listed here — check the booking page for that date.
Booking page
Travel sites need more than a translated FAQ
Guests asking in another language still need the operational answer. That is multilingual support, grounded in your pages.
Cancellation tables and packing rules are FAQ content that people will not scroll to find.
A ready guest who still needs the booking link is a lead generation moment, not a finished reservation.
See the website chatbot overview for what gets crawled, and the guide for install.