Industry
Travel & hospitality
Inventory scattered across sources nobody can search at once
The problem
Travel inventory in Egypt sits across listing sites, agency spreadsheets and WhatsApp threads. A traveller looking for a chalet on the North Coast for six people under a budget has to hold the requirements in their head and check every source by hand.
The operator's side of the same problem is worse: five verticals — stays, hotels, tours, transport, activities — each with its own tooling, so nothing can answer a question that crosses two of them.
What we built
SolvTrav: one inventory layer under five verticals, with a conventional filtered search for people who know what they want and a booking assistant for people who would rather describe it. Both read the same inventory, so neither can offer something the other cannot book.
Read the SolvTrav case studyWhat transfers
A request is mostly hard constraints
Party size, dates and a price ceiling are limits, not preferences. Semantic similarity will happily return a listing that reads like the request and sleeps four, so the model's job is resolving the sentence into filters — and a conventional query answers from what is actually available.
Inventing is worse than returning nothing
A travel assistant that invents a villa is worse than no assistant. Whatever the system says exists has to exist and be bookable at the moment it says so, which makes the inventory layer the real engineering, not the conversation.
Bilingual is not a translation pass
The assistant, the listings and the search all have to work in Arabic and English, including the query understanding. A system that reasons in one language and renders in another degrades in ways that only show up for the audience it was translated for.
Capability: Intelligent Search & RAG