We followed KAI from a ferry question to a test ticket.
Public KAI chat checked 9 October 2026
One journey, several boundaries
- 1Journey and planned sailings
- 2Explicit test-ticket choice
- 3€2.73 test offer
- 4Rabobank Sandbox result
- 5Invalid test ticket returned to KAI
Test flow, not a real travel ticket.
The visitor journey
The five steps we actually observed
The timeline advances automatically or can be paused. It reports the screens and responses from one completed Sandbox test, rather than inventing a sample conversation. Times and the test price belong to that check.
Actually completed · 9 Oct 2026
Test environment onlyGorinchem Woudrichem · 1 foot passenger
Riveer · KAI
The journey question
On 9 October 2026 we asked for one adult on foot from Gorinchem to Woudrichem.
- KAI showed planned departures at 15:15, 15:45 and 16:15.
- The timetable card said these were planned times, not confirmation of a current sailing.
A timetable response is not a ticket or a live sailing guarantee.
The service problem
A simple ticket question crosses several sources
A traveller wants to know where and when to sail, which ticket applies and whether the next step is safe to take. A useful assistant must keep planned timetable information separate from current sailing status, and a proposed ticket separate from a confirmed purchase.
Who owns each part?
KAI conversation
Collect the route, passenger count and travel mode; explain the next permitted step.
Riveer travel and ticket systems
Own the applicable sailing, product and ticket state. A timetable display is not a sailing guarantee.
Payment provider
Process the test checkout in the Rabobank Sandbox; a chat answer alone cannot establish payment success.
Potential business value
Make the next step easier without hiding uncertainty
For a service team, one guided conversation could reduce repeated route explanations and manual handoffs. A pilot should measure completed test journeys, handoffs, corrections, abandoned checkout and how often timetable uncertainty is explained correctly. These are hypotheses, not measured Riveer results.
What this example does and does not establish
We saw KAI show planned sailings, ask for a separate test-ticket choice, display an offer of €2.73, open Rabobank Smart Pay's hosted Sandbox checkout and receive a success result. On return, KAI showed a test ticket with a QR code and PDF option. The card itself said it was paid and checked in, but invalid as a travel document.
The €2.73 price and sailing time are a dated test observation, not a current public fare or live sailing promise. No real payment or valid passenger ticket was issued. Riveer's published normal purchase route remains its website or app. This public test does not establish which DataInbox SDK or backend powers KAI, or prove a production paid-ticket flow through chat.
Which customer step should your agent help complete?
Start with one journey, the authoritative systems behind it and the exact point where a proposal becomes a confirmed action.
Explore governed web agents