Oroko Travel

Oroko ran on Tiger Bay — old, slow, and split into disconnected parts. The trip in one place, the customer in another, the calls and emails somewhere else. Even the customer list never held the full story.

For a luxury agency, that's the core problem: the whole job is personal service, and you can't give it when everything you know about a client is scattered across tools.

So the goal wasn't a better Tiger Bay. It was one connected system — customer, trip, suppliers, payments and every conversation in one place — so a designer plans the trip and looks after the client at once.

I sat in on real sales calls and pulled Tiger Bay apart screen by screen — noting where people gave up and switched to email or a spreadsheet. The requirements didn't arrive in a document; they surfaced in the back-and-forth.

One thing stood out. Old systems treat a trip as a list of bookings — flight, hotel, transfer, in a row. But designers think in days: day one they land, day two they drive to the coast, day three is free. So I built the itinerary around days, not a list — each day holds everything happening that day.

Oroko wanted it to feel like Tiger Bay, so no one had to relearn. I went the other way — clear sections that link into each other: open a customer and their trips, calls and payments are right there. Familiar isn't the same as easy.

There's plenty of software for travel agencies — Travefy, Lemax, Tourplan — and we looked. But they're built for high-volume operators selling the same packaged trip again and again. Oroko is the opposite: every trip is bespoke, and tools built for volume don't fit a business built on personal service.

The closer ones still only solve a slice — an itinerary here, a booking system there. None gave Oroko what it needed: one system, shaped around their way of working, where the customer, the trip and every conversation are connected. That only comes from building it.

Each module stands on its own — customers, the itinerary builder, calls, emails, invoices, tasks, products. You can work in any of them directly: every email in one place, every invoice in another, every trip in a third.

But the same information also gathers inside each customer. Open a person and you get their preferences, travel history, household, notes and documents — plus their own calls, emails, invoices and trips. Open one of those trips and you drop straight into the builder for it.

So a designer works by module or by customer, whichever the moment needs — the same data, reachable from wherever they are.

It starts with an enquiry. A new customer becomes a record, and their trip hangs off it. From the customer you can see everything about them — past trips, preferences, every call and email — so you're never guessing what they want.

Then you open the trip and build it. You add products day by day — flights, hotels, transfers — group the travellers, and set the dates. When it's ready, you confirm with the suppliers in one go, and each one approves or comes back with an alternative.

Once it's agreed, invoicing pulls straight from the trip — nothing re-typed — and you publish. The customer gets a clean itinerary, and the version is saved. The whole path, from a cold enquiry to a booked trip, stays in one place.

Where the user flow traces a single journey — enquiry to booked trip — the sitemap lays out everything the product can do: every module, and under each, the pages and functions it holds.

It's the view I kept coming back to while designing. For a system this connected, seeing the whole structure in one frame is what keeps it from becoming a pile of features — it stays something you can hold in your head.

The product runs on two brand colours — olive for primary, sage for the quieter work — over a soft off-white. Three signal colours do the rest: orange for pending, green for confirmed, red for anything that needs attention. Restrained on purpose: in a tool this dense, colour has to mean something.

Oroko Aura runs the agency now, with real trips booked through it. The biggest shift is that the team stopped leaving the tool. The customer, the trip, the suppliers and the invoice all live in one place, so nobody's rebuilding a booking out of four tabs and an email thread.

The day-to-day got quicker in small ways that add up. Getting hold of a supplier or a customer takes seconds, because the contact and the whole history of the trip sit on the same screen. And a product can be changed at the last minute, with the update landing in the customer's own app straight away — that used to mean a phone call and a fresh document.

Oroko Private, the second system, is in testing ahead of going out to their high-profile clients.

Most of this was invisible work. None of it is flashy — it's a hundred small decisions about where a thing should live and who's allowed to see it. When those decisions are right, the software just feels obvious and nobody notices the design at all. That's the job.

I put the system up against the tools the industry already uses, and I think it holds: it's simpler to learn, it keeps the whole operation in one place, and the private module does something most of those tools don't attempt. If I started again, I'd get end users in front of the hardest screens sooner — the one-day-many-travellers problem would have shown itself weeks earlier. But the bet the whole thing was built on — structure over familiarity, one place over many — was the right one. It's the reason the team actually moved.