Offline hotels — design story

How the hotel flow is shaped, where it differs from flights, and where the MVP line sits.

Internal working document · concept for discussion · sample data only

1 · The lifecycle, end to end

Hotels are a different shape from flights: light at the front (no competitive quote — the officer selects from contracted hotels) and heavy downstream (amend, cancel, no-show, reconcile, settle). Bukit generates the outbound request to the hotel; the hotel stays on email and adopts nothing. Two things remain open with NLNG (amber): the path when no contracted hotel exists in a location, and the reservation letter that bills attach to — referenced in the examples but not provided.

Offline hotels booking lifecycleThe hotel flow from request through settlement, showing which actor owns each phase, the setup data feeding selection, and the open questions: approval placement, out-of-location path, and the reservation letter. Booking 1 · RequestBooker · location, room category 2 · Select hotelOfficer · discretion · sequential Setup · maintained datahotels · rates · room types · contacts 3 · Hotel confirms (email)officer records number + PDF Approval · BAC/DFAafter selection — as flights Live booking — the downstream lifecycle AmendmentOfficer · update in place Cancel / no-showOfficer · manual determination Settlement Invoice + reconcileOfficer · vs reservation letter TMC settles hotelperiodic, or immediate Reservation letterwhat / who issues · need example Outside contracted areapath TBC — asked of NLNG Out of scope Post-stay incidentals (meals, laundry) → ancillaries · NLNG guesthouses → guesthouse bookingsGuest-upfront-payment bookings → existing expense-claim process
Booking record Settlement Open question to NLNG Setup data

2 · The settlement tail — where the complexity lives

The booking doesn't end at confirmation; it stays open for days or weeks, then settles. The hard part is the matching: one hotel invoice covers many bookings, and the amount owed can differ from the amount booked once amendments and no-shows are accounted for. Coral boxes are data-integrity / scope fish-hooks.

Hotel settlement and reconciliation tailAfter confirmation: post-stay charges, the periodic batched invoice, line-by-line reconciliation against reservation letters, and TMC settlement. Contracted and non-contracted settle differently. Fish-hooks and the reservation-letter question are flagged. Confirmed bookingthe anchor for everything below Stay happensactual ≠ booked if amended Hookowed ≠ booked Hotel invoice · 15/30 daysone invoice, many bookings Hookmany-to-one match Reconcile each lineofficer · vs reservation letter Res. letterneed example Officer instructs TMCsettle reconciled lines TMC settles hotelloop closed Non-contractedTMC pays atbooking — skips tail What makes this tail the hard part The booking is open for days/weeks before settling — its identity must stay stable across amendments,so one reservation still reconciles as one line even after dates or guest name change. Reconciliation is line-matching against a batched invoice. For the MVP, Bukit records the booking andreferences; NLNG reconciles in the existing process. Automating the matching is a phase-2 step.
Reconciliation Payment Fish-hook Open question

3 · Where the MVP line sits

The cut isn't "booking in, settlement out" — it's "system of record in, reconciliation engine out". The control value (every booking captured, costed, auditable) stays in the MVP. The genuinely large finance build — automated matching and payment — is deferred, not dropped. Until then NLNG reconciles in their existing process, but against clean Bukit records instead of scattered emails.

Hotel MVP scope lineThe auditable booking record is in scope; the reconciliation matching and payment automation is deferred to phase 2. The line keeps spend-control value while deferring the finance-system build. MVP — the auditable booking recorddelivers the control value: every booking captured, costed, traceable Request + select hotelofficer · sequential Confirm + storenumber · PDF · rate Amend · cancel · no-showupdate in place Claim number · the spinesingle reference, un-bypassable Hold reservation letter + capture invoice referenceclean data for whoever reconciles — Chinemelum asked for this All of the above is the system of record — the reason the project exists MVP line — records the data, doesn't run the engine Phase 2 — the reconciliation enginethe finance-system build · deferred, not dropped Auto-match invoice linesmany-to-one reconciliation Compute owed · instruct TMCpayment automation Until phase 2, NLNG reconciles in their existing process — but now against clean Bukit records,not scattered emails. The hard finance build is deferred; the control value is already delivered.
Chokepoint (claim number) MVP record Phase 2 engine

4 · The resolved flow

Mapped onto the flights pattern: request → select → claim → approval → commit. The one thing hotels add is the sequential availability loop (try a hotel, if full try the next). The claim mints at selection — the chokepoint — and approval sits after selection, before commit, for both payment models. The only place contracted and non-contracted differ is what "commit" means.

Offline hotels resolved flowBooker requests, officer checks contracted hotels sequentially with retry when full, selects the first available which mints the claim, then BAC/DFA approval, then commit — differing for contracted (room held) vs non-contracted (TMC pays). Settlement out of scope; claim number is the audit spine. 1 · Booker requests roomlocation · room category · dates 2 · Officer emails a hotelavailability query · no commitment Room available?full → try next hotel full —retry available 3 · Select → claim mintedclaim number = audit spine 4 · BAC / DFA approvalafter selection, before commit approved 5 · Commit the booking Contractedroom held · settle later Non-contractedTMC pays at booking Settlement, invoicing & reconciliation — out of MVP scope (phase 2)but the claim number stays the audit spine that records and ties it all together
Booking step Decision / loop Claim minted Approval

Settled by design: approval sits after selection (as flights); Bukit generates the outbound request to the hotel, which stays on email. Two questions remain open with NLNG: the path when no contracted hotel exists in a location, and the reservation letter that bills attach to — referenced but not yet provided. Neither blocks the core booking flow; the reservation letter sits with settlement.