Booking online, operated from a phone

A booking site is the easy half. The hard half is the morning after a booking lands: which rooms are free, who is arriving today, who has paid and who still has to be verified at the desk. Toobler built both halves — a public booking platform for a regional accommodation market, and the Android app the staff run the day from.

Customer and context

The client wanted direct bookings rather than depending only on third-party sites, across a portfolio that was broader than hotels: apartments, service apartments, resorts, auditoriums and tourist homes. Each property had its own rooms, room types, rates, cancellation terms and tax treatment, and each property’s own staff had to manage them without being able to touch anyone else’s.

Toobler engineered it across 2016 and 2017, with a team of sixteen over the life of the engagement. The largest single phase was not a build sprint — it was the work that came out of client review, which says something true about how a first-of-its-kind product in a local market actually gets finished.

The challenge

• Two audiences, one system. A guest wants to search and pay. Staff want the opposite view: today’s arrivals, which rooms are free, which bookings are still unpaid.
• Not every booking is paid online. In this market a large share of guests expect to settle at the desk. A booking engine that only takes cards does not fit the way the business runs.
• Every property is different, and every property’s staff are different people. Permissions had to be real, not cosmetic.
• Identity has to be checked before arrival, which makes verification a workflow with two sides rather than a form field.
• The day is not run from a desktop. Whoever is on the desk needs the calendar on a phone.

The solution

A booking flow that can end at the desk, not only at a gateway. Card and netbanking payments run through PayUMoney. Alongside them is a pay-on-check-in option that completes the booking and blocks the room without charging anything up front — the booking is real, the room is held, and the money is collected on arrival. That single option is what made the platform usable in its market.

Search built around how people actually choose a room. Location, property name and check-in and check-out dates on the home page; results with pagination and filters for category and price; and a map view that highlights the lowest nightly rate so a guest can see where the cheaper options are before opening anything.

A portal per property, on its own subdomain. Each property gets its own admin URL and its own staff accounts. An access-control module decides what each role sees — a superadmin across the whole site, a property admin for their own property, and managers with a narrower view — filtering menus and pre-filling permissions by role rather than hiding links in the interface.

The estate modeled the way a property describes itself. Category levels, then properties, then room types, then rooms, with site-wide amenities, per-property settings, cancellation policy and tax rate applied to the total on both the guest and admin sides.

Guest verification as a two-sided workflow. The guest uploads an ID document; staff download it and approve or reject before arrival, with the result visible against the booking.

An Android app for the people running the day. A calendar view to pick a date and see every booking on it, a room-wise view down to room numbers, orders with date and room-type filters, a customer list with verification built in, and notifications when a booking is confirmed or canceled.

A REST API as the contract between the two sides. Thirty endpoints covering property and user details, rooms filtered by date, room details, bookings by id, customer verification, orders, notifications and blocking or releasing a room — so the app and the web admin read the same data rather than drifting apart.

Direct booking from the admin side. Staff taking a booking over the phone search availability and complete it with the same payment options a guest has, including pay-on-check-in, so a phone booking is the same record as a web booking.

Results

Booking, occupancy and revenue figures for this engagement are not published. The delivery record carries none, and none are estimated here.

What can be stated is the scope: a public booking platform and a staff operations app for a multi-property accommodation market, delivered across 2016 and 2017 — search and booking, online and pay-at-desk payments, a per-property admin portal with role-based access, guest ID verification, direct booking from the admin side, and a REST API shared by web and mobile.

What this means for hospitality software

Most booking products are built for one of the two audiences and bolt the other on later. The useful lesson here is that the operator side is not a smaller version of the guest side — it is a different product, with a different shape of data, that happens to share a database. Engineering both at once is what lets a property take a booking by phone, hold a room for a guest paying at the desk, and still see one accurate picture of the day.

That is the same discipline behind Toobler’s hotel property management work, its in-room guest experience engineering and the wider hospitality engineering practice. More of the work is in the case studies. If you are building an accommodation or booking product and need the guest side and the operator side engineered as one system, talk to Toobler’s engineering team.