Boni

Boni Reservations

Controlled pilot

Keep inventory, bookings, distribution, and operator work in sync.

Boni Hotel OS and Boni Bus OS provide a shared reservations foundation for inventory, rates or fares, holds, bookings, distribution, changes, cancellations, and settlement workflows.

For: Independent hotels, resorts, homestays, small chains, private bus operators, fleets, counters, agents, and travel platforms.

What the product connects

One operating record across the workflow

Hotel OS

Properties, room types, rates, availability, holds, bookings, guest work, and distribution.

Bus OS

Operators, routes, stops, trips, vehicles, seats, fares, bookings, crew work, and distribution.

Shared foundation

Booking state, availability control, payments, webhooks, audit, channel sync, and operator exceptions.

How it works

Give every sales channel the same availability and booking truth.

The operator experience stays specific to the business while the underlying reservation lifecycle stays consistent and auditable.

  1. 01

    Set up the operator

    Create the property or transport operator, locations, roles, policies, inventory structure, and commercial rules.

  2. 02

    Publish availability

    Maintain rooms or seats, rates or fares, schedules, restrictions, and the channels allowed to sell them.

  3. 03

    Hold inventory

    Create time-bounded holds so two channels do not sell the same room or seat while a buyer completes checkout.

  4. 04

    Confirm the booking

    Turn a valid hold and payment outcome into one confirmed reservation with customer and source references.

  5. 05

    Operate changes

    Handle cancellation, release, refund, reschedule, guest or passenger updates, and service exceptions from the same record.

  6. 06

    Reconcile distribution

    Review bookings, channel source, payments, settlement, availability drift, and operator follow-up.

Product scope

What the product covers.

Hotel properties, rooms, rate plans, availability, holds, bookings, and guest workflows.

Bus operators, routes, stops, trips, buses, seat maps, fares, holds, and bookings.

Direct, agent, Bino, API, and approved external distribution paths.

Idempotent booking and payment references so callbacks do not create duplicate reservations.

Cancellations, inventory release, refund state, and operator-visible exceptions.

Customer confirmations and service follow-up connected to the reservation.

Payments and settlement evidence without treating the booking service as the accounting ledger.

API-first availability and booking contracts for approved partners.

Operator-specific views over a shared, auditable reservation core.

Start with a defined operating scope.

Each rollout names the workflow, participants, source records, owner, success measures, and the parts that remain in existing systems.

Separate operator experiences

Hotel OS and Bus OS keep domain-specific screens and terminology. The shared reservation layer is infrastructure, not a generic interface forced onto staff.

Inventory ownership is explicit

The pilot defines which inventory Boni owns, mirrors, or distributes and how conflicts, stale availability, and channel updates are handled.

Payments do not equal settlement

A successful customer payment, operator payable, cancellation, refund, platform fee, and accounting entry remain separately traceable.

Readiness is scoped

The working foundation is suitable for controlled pilots. Broader parity with mature hotel PMS, channel-manager, or bus GDS products depends on the contracted workflow.

Questions

Common questions

Is this one generic reservation screen for hotels and buses?

No. Hotels and bus operators use separate operating views because rooms, rates, trips, seats, stops, and fares have different workflows. They share a reliable booking and distribution foundation underneath.

Can inventory appear on Bino?

Yes, a controlled implementation can expose approved hotel or bus inventory through Bino booking journeys while keeping the operator's reservation record authoritative.

Does this replace every PMS or operator system immediately?

No. The first pilot should define the inventory and booking lane it owns, the systems it must synchronize with, and the operational gaps that remain before wider rollout.

Is the product generally self-serve?

Not yet. The current product is offered as a controlled pilot with onboarding, inventory setup, distribution scope, payment and settlement rules, and operator support agreed in advance.

Start with one bounded workflow

Bring the current process, files, and operating constraints. We will define the smallest useful pilot.

Discuss a reservations pilot