Use cases · TravelIn development
Bookings, date changes and baggage, under the current policy
Ray will answer from the conditions each travel business publishes, report a booking’s status read-only and guide the date change on the site. Changing a booking, charging a difference or refunding will stay with the team.
Early access with close support from the team. Ray is in development.
Illustrative example of a fictional agency: five frequent questions. Ray will resolve four, two with read-only booking data; the request for compensation for a canceled flight will go to a person.
Illustrative example with sample data. Lumora is a fictional brand.
Frequent questionsIn development
Before, during and after the trip, with the policy in force
Conditions change by fare and by season. Ray will reply only with the published policy in force, and with the booking data, read-only.
Date changes
The conditions of each fare, the deadline to request the change and the site’s steps to make it.
Baggage
The allowance of each fare, with published sizes and costs, in a short, clear list.
Booking status
Confirmation, check-in time and trip details, read-only and with the time of the data.
The next step
If something cannot be done online, Ray will point to the published channel or form.
Illustrative example: a traveler asks to change the date of their booking and Ray replies, with read-only booking data, that the fare allows the change free of charge and gives three numbered steps; then they ask about baggage, Ray replies with a two-item list, and the traveler confirms it was solved.
Illustrative example with sample data. Lumora is a fictional brand.
TraceabilityIn development
What the team sees in the console
The customer will get the written answer, with no internal references. In the console, the team will see the cited article and its version, the booking data looked up and the controls the answer passed.
Article and version
Each answer will be tied to the published article that backs it and to the version in force at that moment.
Data looked up
Which booking detail was read, read-only, such as the fare or the departure date, and when it was last updated.
Check before sending
Deadlines, fees and allowances checked against the policy in force. If two articles contradict each other, Ray will not pick one: it will alert a supervisor.
Illustrative example of the record in the console, visible only to the team: the articles Date changes by fare and Baggage by fare, the booking looked up read-only, the check of deadline, fee and allowance, and the non-sensitive topic controls.
Illustrative example with sample data. Lumora is a fictional brand.
Sensitive topicsIn development
What goes to a person in travel
Ray’s base list will always stay on and each company will add its own topics, such as cancellations or lost baggage. On those, the traveler will get a fixed holding message and the team the conversation with the reason and a draft.
Cancellations and compensation
Canceled or delayed flights and compensation requests: a person decides.
Added by the companyLost or damaged baggage
The team will open the claim and follow it up.
Added by the companyHealth or safety during the trip
Any risk to a person will be handed off in full, with a supervisor alert.
DefaultDisputed payments and refunds
Unknown charges or rejected refunds. The draft will not promise amounts or time limits.
DefaultPersonal data and documents
Passport details and requests to correct or delete data.
Default
Illustrative example. The traveler writes that their flight was canceled and wants compensation; they get only the fixed holding message. The team gets the conversation with the reason and a draft from Ray with its sources, which promises no amounts or time limits.
Illustrative example with sample data. Lumora is a fictional brand.
The team will handle these cases in Inbox and copilot; the list will be edited in Ray agent.
Read-onlyIn development
Ray reports the booking; the team changes it
Ray will be able to read the status of a booking, the fare and the baggage allowance. Issuing tickets, charging differences, refunding or approving an exception will stay with the team, in the company’s systems.
Without an identity signed by the company’s server, the traveler will be treated as anonymous and Ray will not look up their bookings.
Ray will be able to look up
- The status of a booking and the time of the data
- The fare, its change conditions and the baggage allowance
- The published steps to change a date on the site
Ray will never
- Change bookings, issue tickets or charge differences
- Refund or grant compensation
- Approve exceptions to the published policy
See Ray with the company’s policies
A short conversation with the team that builds Ray to review the company’s case: frequent questions, existing knowledge, sensitive topics and a migration plan.