Customer journey · Riveer KAI

    From ferry question to ticket with KAI.

    A traveller asks about a crossing, chooses a ticket, completes checkout and receives it back in KAI. We followed this journey on Riveer's public site on 9 October 2026: one adult on foot from Gorinchem to Woudrichem. The visual below uses the actual conversation and an excerpt from the returned ticket. The payment was in the Rabobank Smart Pay Sandbox.

    One observed customer journey · 9 October 2026

    What the traveller experienced

    1. 1Ask about a crossing
    2. 2See planned sailings
    3. 3Choose a specific ticket
    4. 4Complete hosted checkout
    5. 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.

    1. 1Ask about one adult on foot from Gorinchem to Woudrichem.
    2. 2KAI shows planned departures and an offer of €2.73.
    3. 3After a separate choice, Rabobank Smart Pay handles the Sandbox checkout.
    4. 4The test ticket returns to KAI after the Sandbox success result.

    The returned test ticket

    Excerpt from the actual Riveer test ticket showing Gorinchem to Woudrichem and TEST statusOpen the full customer journey image
    Captured on 9 October 2026; text from the actual conversation and an excerpt from the returned Riveer PDF. Payment in Sandbox.

    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