FIELD NOTES / ORIGINAL RESEARCH

We Tested What an AI Agent Could Actually Do on a Tourism Website

We gave an AI agent three practical tourism tasks. It reached a dated tour quote, read a lodge availability grid and carried a selected safari into an enquiry route. Here is what worked, what needed care and where the test stopped.

NU SIGNATURE · 19 OCTOBER 2026 · 10 MIN READ

At 10:40 UTC on 5 October 2026, an AI agent was looking at a booking summary for the Sani Pass Tour into Lesotho from Underberg.

The date was 15 October. The departure time was 09:00. The party had been changed from one adult to two. The page displayed ZAR 1,065 per adult and a total of ZAR 2,130.

Then the test stopped. The Checkout button remained untouched. No traveller details were entered, no inventory was held and no payment was attempted. That boundary is the point of this article: an agent can make meaningful progress through a tourism website without that progress being confused with a completed booking.

ABOUT THE TEST

Three websites. Three real guest tasks. One attempt per journey.

The test used an OpenAI assistant working through a supported Chrome cloud-browser computer-use interface. It navigated with accessibility snapshots, screenshots, clicks, scrolling and, where needed, a currency selector. We did not record an independent model identifier or Chrome build number, so the observations should not be attributed to every ChatGPT configuration or a particular model version.

The sample was deliberately small: an activity operator with an embedded booking engine, a safari accommodation business and an enquiry-led safari designer. It was a demonstration, not a random benchmark, vendor comparison or reliability study. Each journey received one task attempt with normal page-load verification. No success percentage is defensible.

Relationship disclosure: Roof of Africa Tours is a Nu Signature client. We included it because it offered an accessible, real booking integration to test, not as independent evidence that Nu Signature websites outperform other tourism sites. Tanda Tula and Spirit of Kenya were public third-party examples.

Trial one: could the agent move from a tour page to a useful quote?

The task was deliberately ordinary: find the Sani Pass day tour from Underberg, check the practical details and obtain the displayed quote for two adults on 15 October 2026. Stop before checkout.

The agent followed the tour journey from the Roof of Africa Tours homepage and could read useful information before touching the booking calendar: the tour was presented as seven hours, a passport was required and lunch was excluded. Those are the operator's published statements; this test did not independently verify travel-document or operational requirements.

OBSERVED RESULT / 5 OCTOBER 2026

09:00 · 2 adults · ZAR 1,065 each · ZAR 2,130 total

The agent increased the adult count from one to two, selected 15 October and reached the pre-checkout booking summary. It did not press Checkout. The displayed price and availability were a dated observation, not a reservation confirmation or promise about future inventory.

That result matters because the task crossed several layers of the website. The agent had to understand the product, identify the booking route, interact with an embedded Bókun calendar, change party size and date, and read the resulting summary.

None of those steps required a purpose-built AI tool. This was normal browser interaction with the booking interface.

The most useful moment was when the page looked broken

The first accessibility snapshot showed a loading message. A later snapshot briefly showed disabled dates. If we had recorded the first visible state as the result, the conclusion could easily have been “the agent cannot use the booking widget”.

Instead, the test waited for the rendered interface. A subsequent screenshot showed enabled dates and prices. The lesson is not merely technical. Agent testing needs the same patience good human QA needs: loading state, disabled state and final interactive state are not interchangeable. A slow widget can create a false failure if the test does not verify what eventually rendered.

Trial two: could it read rates without confusing the units?

The Tanda Tula task looked simpler: find Safari Suite rates in ZAR, identify important extra charges and inspect the public availability view without reserving a room.

The agent followed Rates & seasons, changed the currency from USD to ZAR and opened Availability. The published 2026 table showed a Safari Suite sharing rate of ZAR 31,500 per person per night. It separately listed a ZAR 1,815 adult nightly sustainability levy and a minimum two-night stay.

OBSERVED RESULT / 5 OCTOBER 2026

The page gave enough information to compare, but not enough to invent a final quote.

The embedded availability grid covered dates from 5 to 18 October and showed a mixture of Sold Out and numeric availability indicators. Safari Suite cells included “From 47,250.00”. We did not treat that number as a two-person nightly quote because the occupancy and rate basis were not established in the grid. No room was selected or held.

This is where agent behaviour becomes more interesting than simple navigation. A system can successfully read the table and the availability interface yet still reach the wrong commercial conclusion if it collapses per-person rates, room pricing, levies, minimum stays and “from” values into one number.

The website was usable. The correct answer still required restraint.

Trial three: could a bespoke safari end in the right enquiry, not a dead-end contact form?

The Spirit of Kenya task tested a different kind of sale. We asked the agent to find a Kenya journey of five to eight days and reach the enquiry route with the chosen itinerary retained. It was not asked to submit a request.

Using the homepage safari finder with Kenya and 5–8 days produced 12 journeys. Some of those results crossed into Tanzania, so the filter should not be described as guaranteeing a Kenya-only itinerary. The agent then selected the six-day Amboseli and Mara journey and followed its enquiry link.

OBSERVED RESULT / 5 OCTOBER 2026

The enquiry page retained the selected journey context.

The destination page visibly carried “JOURNEY: AMBOSELI AND MARA”. The agent did not arrive at an empty generic form and have to reconstruct what the traveller had been viewing.

For a bespoke safari business, that can be a perfectly successful digital next step. Not every high-value trip should end in an instant checkout. Sometimes the useful job of the website is to carry enough context into a human planning conversation.

The page also advertised a typical reply of approximately two hours. We treated that as a published expectation, not a measured response time. The multi-step form was not completed, so validation, inbox delivery, quotation quality and the actual reply remain untested.

Browser interaction and structured agent tools are different routes

It is important not to rewrite these trials as a WebMCP success story. The browser exposed no supported WebMCP tool-discovery or execution interface during this run. The agent worked through the visible websites using ordinary computer-use interaction.

That does not mean any of the three websites lack WebMCP, nor does it test whether a structured tool would have completed the task more reliably. It simply means these observed results came from interacting with the interface much as a person would: reading, clicking, waiting, selecting and checking the result.

Structured tools may eventually expose certain tasks more explicitly to agents: searching inventory, retrieving a product, preparing an enquiry or calling a read-only service tool. Chrome currently describes WebMCP as a proposed standard and a progressive enhancement rather than a replacement for accurate content, good interfaces or transaction safeguards. That is a different layer from what we tested here.

Read our WebMCP Field Note

What made these journeys agent-friendly?

Three trials are far too few to tell us which tourism websites are “agent ready”. They are enough to expose some practical design qualities worth testing.

1. Useful product information was available before the transaction. Duration, passport requirements, exclusions and rate conditions were readable without forcing the agent to begin checkout.

2. Controls were labelled well enough to operate. Dates, party size, currency and enquiry actions could be identified through the rendered interface.

3. Price units were visible. “Per person per night”, separate levies and minimum stays gave the agent a chance to preserve the commercial meaning of the numbers rather than simply repeat the largest or smallest figure it saw.

4. Context survived the handover. Spirit of Kenya's selected journey remained visible when the traveller moved into the enquiry route.

5. The integrations themselves had to work. A beautiful product page would not have rescued a booking widget that never finished loading or a link that dropped the traveller into the wrong place.

None of these improvements requires a business to build an AI agent first. They are good website and booking-journey practices in their own right.

What this test does not prove

No personal traveller details were entered. No account was created. No enquiry, checkout, payment, inventory hold or delivery confirmation was submitted. A displayed quote is not a booking and a published reply promise is not a response-time measurement.

The three websites were deliberately selected examples, not a representative sample of the tourism industry. Each journey received one task attempt. We cannot turn three observations into a success rate, a vendor comparison or a claim that tourism websites as a category are ready for autonomous agents.

We also did not audit analytics or server-side inventory behaviour. Ordinary page analytics may have recorded visits or selector interactions, but that was outside the scope of this field test. The results do not establish conversion uplift, SEO benefit or a business case for installing new agent technology on every site.

Before adding agent tools, test one real guest task

The most useful next step for an operator may be much less dramatic than installing an AI plugin. Pick one real task a guest should be able to complete and follow it all the way through.

1. Start from the page a guest would genuinely land on, not the admin screen or a perfect internal link.

2. State the task precisely: find a specific tour, compare a room rate, choose a date, or begin an enquiry for one named itinerary.

3. Record every piece of information the traveller needs to proceed: rate basis, inclusions, dates, party rules, practical requirements and the next action.

4. Wait for dynamic interfaces to finish rendering. Do not label a loading state as a failure until the page has had a fair chance to become usable.

5. Stop before a consequential action unless the test is explicitly authorised. Reaching checkout or a populated enquiry page can tell you a great deal without creating a booking or sending a lead.

Only after that journey is clear does it make sense to ask whether a structured agent tool would make the task more reliable, safer or easier to automate.

The agent did useful work. The website still carried the responsibility.

Across the three journeys, the agent could navigate, interpret, compare and prepare. It could reach a real quote, inspect availability and preserve a safari choice into the enquiry stage. That is already more practical than the idea of an AI merely summarising a homepage.

But the websites had to provide the facts, labels, rate boundaries, working integrations and sensible next steps. The agent did not remove the need for a good tourism website. It exposed why the details of that website matter.

TEST THE JOURNEY

What could an agent actually do on your tourism website today?

Nu Signature can test a bounded guest journey across your website, content and booking or enquiry flow, then show where the path is clear, where assumptions creep in and where the experience needs attention. We would rather start with the real task than recommend new agent technology before we know what problem it needs to solve.

Explore the Customer Journey Review

Test sources and technical context

The website observations were recorded on 5 October 2026 and are presented as a dated field test. Rates, inventory and public interfaces can change. The article does not reproduce third-party marketing images or imply endorsement.

Roof of Africa Tours: Sani Pass Tour into Lesotho from Underberg

Tanda Tula: Rates & seasons

Tanda Tula: Availability

Spirit of Kenya: safari starting point

Chrome for Developers: WebMCP

OpenAI Help: Using cloud browser in ChatGPT

NU SIGNATURE / MENU

SOUTH AFRICAN. WORKING GLOBALLY.