From ferry question to ticket with KAI.
One observed customer journey · 9 October 2026
What the traveller experienced
- 1Ask about a crossing
- 2See planned sailings
- 3Choose a specific ticket
- 4Complete hosted checkout
- 5Receive the ticket in KAI
Test flow, not a real travel ticket.
The real journey, in one image
See the route, checkout and returned ticket
The route, departure times and €2.73 offer come from the observed KAI conversation. The ticket image is cropped from the PDF returned after the Sandbox checkout; its QR code and order ID are omitted. This is a visual summary, not a screen recording.
- 1Ask about one adult on foot from Gorinchem to Woudrichem.
- 2KAI shows planned departures and an offer of €2.73.
- 3After a separate choice, Rabobank Smart Pay handles the Sandbox checkout.
- 4The test ticket returns to KAI after the Sandbox success result.
The returned test ticket
Open the full customer journey image
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 we can verify
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. 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