In partnership with
AI Spotlight · Case Study
How Omio Rebuilt a Travel Platform From the Ground Up With OpenAI
Not a chatbot bolted onto an old product. Not a pilot program. Omio restructured every internal function, mandated Codex across its entire engineering lifecycle, and cut product development effort to 20 percent of what it used to require.
Most companies that announce an AI transformation are describing something much narrower: a new chatbot in customer support, a coding assistant for a handful of engineers, or a dashboard with AI-generated summaries. The underlying processes remain unchanged. The org chart looks the same. The timelines compress slightly, if at all. The announcement uses the language of transformation while describing something closer to addition.
Omio took a different position. The European multimodal travel platform, which coordinates booking across more than 3,000 transportation providers in 47 countries, made a company-wide decision to reject the superficial layering of AI onto existing processes. Its CTO, Tomas Vocetka, required every internal function to redesign its operational frameworks from scratch to operate as a native AI enterprise. That mandate applied to engineering first and expanded from there.
The results are specific enough to be worth examining closely. Technical effort required to build specific products now sits at approximately 20 percent of previous levels. Projects that previously required multiple developers for a full quarter now require a single engineer for roughly one month. And Omio launched one of the earliest conversational travel booking interfaces in the industry, connecting OpenAI models directly to live transportation inventory across trains, buses, ferries, and flights. This issue walks through exactly how they did it and what the architecture looks like.
* * *
The mandate
Why Omio refused to add AI on top of existing processes
The strategic position Vocetka articulated internally is worth understanding before looking at the technical specifics. The argument is that bolting generative AI onto outdated internal processes produces marginal gains at best and creates new complexity at worst. The process was designed for a world without these capabilities. Optimising it incrementally does not make it a native AI workflow. It makes it a legacy process with an AI layer on top.
The alternative Omio chose requires more upfront commitment: redesigning how each function actually works, starting from what the job requires, and building the workflow around the capabilities now available rather than adapting the capabilities to fit the existing workflow. That is a harder conversation internally. It means acknowledging that the way things were done was built for a different toolset, and that keeping it intact because it is familiar is a choice with a cost.
|
The core policy distinction Omio does not use AI to assist existing processes. It redesigns processes to operate natively within AI capabilities. The difference is not semantic. One produces a slightly faster version of the old workflow. The other produces a fundamentally different output at a fundamentally different cost. |
* * *
The technical rollout
How Omio deployed Codex across its entire engineering lifecycle
The deployment followed a two-phase sequence. Vocetka started by giving the entire workforce base ChatGPT access. This was not the primary integration. It was a deliberate onboarding step: establishing familiarity with generative models across the organisation before executing the deeper technical integration. Engineers, product managers, and operations staff built baseline intuitions about how these tools work before the more demanding deployment began.
The second phase was the substantive one. Omio embedded OpenAI Codex directly into its engineering operations and mandated its application across the entire software development lifecycle. That mandate is broader than it might sound. Engineers currently apply Codex to preliminary research, architectural planning, active coding, automated testing, code reviews, and ongoing system maintenance. It is not a tool used at one stage. It is present at every stage.
|
The full lifecycle coverage Preliminary research: Engineers use Codex to survey technical approaches and existing solutions before beginning architecture design. Architectural planning: System design decisions are developed and evaluated with Codex analysing tradeoffs and surfacing implications. Active coding: The primary implementation workload runs through Codex, with engineers reviewing and directing rather than writing from scratch. Automated testing: Test generation and execution integrated into the same Codex workflow as the implementation itself. Code reviews: Codex participates in review cycles, flagging issues and surfacing potential improvements before human review. Ongoing maintenance: System upkeep, debugging, and iterative improvement all run through the same integrated Codex environment. |
The engineering division also built custom internal connectors to link proprietary data environments directly with these tools. This setup allows developers to bypass basic information retrieval and proceed directly to active task execution within their integrated development environments. The connector layer is what transforms Codex from a general-purpose coding tool into something operating within Omio's specific technical context.
* * *
The results
What the deployment actually produced in measurable terms
Internal analysis at Omio produced two figures that are stark enough to be worth sitting with. The technical effort required to build specific products now sits at approximately 20 percent of previous levels. And projects that previously demanded the attention of multiple developers for an entire fiscal quarter now require a single engineer operating for roughly one month.
|
|
The downstream effects matter as much as the headline numbers. Faster cycle times allow the engineering teams to test experimental concepts and validate consumer demand with minimal resource expenditure. Management can now allocate capital and engineering hours with greater precision, relying on prototyping to eliminate unviable features before committing to full-scale production. The cost of being wrong about a product idea dropped significantly, which changes how the company evaluates risk.
Lowering the time and cost barrier for software creation enables quicker internal decision-making. The technical teams iterate on existing products at a much higher velocity, pushing updates and new interface elements to the live environment at accelerated pace. The compounding effect of faster iteration cycles on a platform serving 47 countries is substantial.
ChatGPT gives you generic answers because you give it generic prompts.
You know the fix: longer prompts, more context, clearer constraints. But typing all that takes five minutes per prompt, so you shortcut it. Every time.
Wispr Flow lets you speak your prompts instead of typing them. Talk through your thinking naturally — include context, constraints, examples — and get clean text ready to paste. No filler words. No cleanup.
Works inside ChatGPT, Claude, Cursor, Windsurf, and every other AI tool. System-level, so there's nothing to install per app. Tap and talk.
Millions of users worldwide. Teams at OpenAI, Vercel, and Clay use Flow daily. Free on Mac, Windows, and iPhone.
The consumer product
The conversational booking interface built on live transport data
The internal engineering transformation enabled a parallel product development track. In 2023, Omio launched one of the earliest conversational travel booking interfaces in the industry by connecting OpenAI models directly to its proprietary transportation inventory. The timing was early. The architecture was deliberate.
The system processes natural language queries about complex multimodal routes. A traveler can input a request asking for the fastest route from Rome to Florence, or ask to compare flights and trains between Paris and Barcelona. The generative models parse the intent, ping the booking systems, and construct viable travel paths grounded in live pricing and availability data. The architecture explicitly prevents the generation of travel options based on static or outdated training data. Every itinerary the system presents is directly bookable at the time of presentation.
|
What the old process looked like vs what Omio replaced it with Legacy travel booking: Users navigated multiple websites, manually compared modes of transport, and independently aggregated itineraries across multiple providers. The mental overhead of comparing a train from Paris to Brussels with a flight and then checking onward connections sat entirely with the traveler. The Omio interface: A single natural language input. The system handles aggregation across trains, buses, ferries, and flights from more than 3,000 providers. The consumer states the destination and the constraint. The interface returns directly bookable itineraries with live pricing. |
Omio subsequently expanded the initial integration into a dedicated ChatGPT experience that directly accesses the global transportation network the company maintains. By grounding the user interaction in verified data rather than general model knowledge, the technical team ensures high-fidelity responses. Consumers receive personalised journey options rather than generic travel advice that may not reflect current availability or pricing.
* * *
A new category
Why Omio calls this conversational commerce and why it matters
Omio defines the structural setup as a new category of conversational commerce. The framing is specific: the AI operates as the primary interface layer mediating the interaction between the consumer and the underlying global transportation network. This is distinct from a chatbot that answers questions about a product. The AI is the product interface. The inventory is what sits behind it.
The company views this as a departure from legacy search-based interfaces toward native generative customer experiences. Search-based interfaces require the consumer to translate their travel intent into the structured query format the system understands: origin, destination, date, passenger count, class. Conversational interfaces invert this. The consumer states what they want in natural language and the system handles the translation to structured queries internally.
|
The architecture in plain terms Consumer inputs natural language request. Model parses intent. Model pings live inventory across 3,000+ providers. Live pricing and availability data grounds the response. Model constructs directly bookable itinerary. Consumer books without leaving the interface. No static training data. No outdated options. No fractured multi-site navigation. The entire journey from intent to booking happens within a single conversational interface. |
The deployment points toward a future where travel planning relies entirely on interacting with intelligent systems connected directly to live transportation networks. The implication for legacy travel aggregators that have not made this architectural shift is significant. The interface layer is where consumer attention lives. Ceding the interface layer to conversational AI while maintaining legacy search as the primary experience is a strategic position that is increasingly difficult to defend.
* * *
The governance layer
How Omio keeps humans in charge without slowing everything down
Broad AI deployment across engineering and non-technical functions creates a governance question that Omio addressed explicitly in its corporate policy. The answer Vocetka landed on is precise: generative tools function strictly as acceleration engines for development, analysis, and decision-making. Human personnel retain full accountability for all deployed code and final business outcomes.
|
Direct quote from Tomas Vocetka, CTO "The responsibility and accountability stay with people. AI helps us develop faster, analyse faster, and make decisions faster, but people stay in charge." |
This governance structure prevents automated systems from independently executing irreversible changes to the booking infrastructure or the core multimodal routing algorithms. The practical implication: speed comes from AI assistance at every stage of the workflow, not from removing human review at the decision points that matter most.
The combination of broad employee access to OpenAI tools and rigorous oversight at production boundaries creates an environment that prioritises both speed and systemic stability. This is the governance model that makes aggressive deployment sustainable: acceleration everywhere, accountability at the boundary where changes become irreversible.
* * *
What this case study actually teaches
The Omio deployment is worth studying not because it uses OpenAI tools but because of the sequence and the philosophy behind the sequence. Start with baseline access to build familiarity. Build the connectors that give the tools context from your proprietary data environment. Mandate the new workflow across the full lifecycle rather than at selected stages. Expand beyond technical functions once the engineering model is established. Maintain explicit human accountability at the production boundary.
The 20 percent effort figure is not magic. It is the compound output of each of those steps executed in the right order, in an organisation that was willing to redesign its processes rather than add to them. The companies that will look back at 2025 and 2026 as a turning point are not the ones that gave their employees AI access. They are the ones that restructured around it.
|
Adding AI to old processes produces AI-assisted old processes. Redesigning processes to operate natively within AI capabilities produces something different: a company that moves at a fundamentally different speed and cost structure than the one it replaced. |
* * *
|
Before you go Is your organisation adding AI to existing processes or redesigning processes around AI capabilities? Hit reply with one honest sentence. The distinction matters more than which tools you are using, and the most candid responses will shape a follow-up issue on what the redesign process actually looks like inside companies that have done it. |
Until next time,
AI Spotlight
Practical AI, translated into real work, once a week.