Mbiztravel is Mbizmarket’s new pillar for government business travel. After flights, hotels can now be booked, approved, invoiced and proven inside the same platform.
Real screen from the Mbiztravel design file. Traveller data is fictional.
Mbiztravel only did flights, so hotels were booked elsewhere and dropped out of the procurement trail.
Made the Trip the container for every booking, put agent comparison inside the hotel card, added one shared “booking type” marker everywhere, and ran design QA until staging matched the mockups.
One approval for flight and hotel, proof of stay ready for expense reports, and hotel spend back on the platform.
Mbiztravel transaction value once hotels joined flights in the same trip.
time spent reconciling travel invoices, now that orders, invoices and payments live in one place.
to put together a trip’s expense report (SPJ). Proof of stay can be downloaded right after check-out.
A government business trip almost always means a flight and a hotel, with the same travellers, travel order and budget. Mbiztravel started with flights only, so hotels were booked elsewhere and fell out of the procurement trail.
Requesters and multi-level approvers. They create the trip, book, and get the voucher.
Process the booking, issue invoices, and see the stay details.
Monitor bookings, invoices, payments and travel fees in the admin portal.
Every part of Mbiztravel assumed an order is a flight: columns, details, invoices, even documents. Adding hotels meant undoing that assumption on every page, without confusing the people already booking flights.
The detail column only had “Flight details”, and no listing showed what kind of booking a row was.
That can’t be squeezed into seats and routes, yet it still has to read the same for buyers, agents and admins.
One trip can need several approval levels, and every order needs an invoice and printable proof.
Agencies handle business travel in one place, agents get hotel bookings through the official channel, and Mbizmarket opens a new line beyond goods and services.
A normal UX process, plus the step people often skip: making sure what’s built actually matches the design.
I mapped why hotels were booked off-platform, and where “every order is a flight” was baked into each page.
The Trip as container, tiered approval, then two parallel order flows all the way to the voucher.
One stay-details pattern across buyer web, agent web, the admin portal and printable documents.
Failure scenarios checked, then staging compared against the mockups until colours, fonts and field behaviour matched. 30+ issues caught before release.
“One trip already means one approval. Next up: one invoice.”
The first release kept flight and hotel invoices separate on purpose, and changes after confirmation aren’t supported yet. Those are the obvious next steps, and the Addendum pattern could be reused for changing stay dates or the guest list.
Real screens from the Mbiztravel design file. Traveller data is fictional.
