Hotel Reservations Booking Application Suite
REQUIREMENT
A rapidly growing and exclusive 3rd-party hotel reservations booking service in Las Vegas serves travel agencies and large corporate travel customers, and exclusive hotel properties and brands. Bookings are made by travel agents using client’s own reservation system managed outside of NetSuite. The booking number is unique to each reservation and must be meticulously tracked for audit with every subsequent transaction, whereas more granular details are required for each transaction line (names, room types, dates).
Transaction types and flows are more complex and dynamic in this business model, for example, 1) travel agent deposits are required in full, and provide large payments that must be divided and associated to many listed bookings, and 2) vendor deposits are also required in full, and made via AMEX “single-use credit card” (virtual cards) auto-generated by AMEX at the time of each travel agent’s booking.
Complicating both cases, 1) bookings are frequently changed or cancelled before the stay, while 2) actual stay details are not reported by vendors until after departure date and frequently include changes or cancellations, so both sales and expenses must wait to be finalized with changes applied, and new refund and account balancing transactions often become required for only those allowable changes.
ISSUES
The requirements do not fit well, or sometimes at all, within NetSuite’s native transaction types and flows. However, another NetSuite consulting firm had, at great time and expense, implemented several customizations, integrations and automations with no auditable history of changes, little validation of data accuracy, and no scalability, while a number of requirements were left entirely unresolved, leaving even more complicated and laborious manual processes.
SOLUTION
Envisioning a totally new strategy we designed and built an entirely new scalable framework and set of processes that solved all the issues of data integrity and audit-ability, reduced all manual labor requirements, improved customer service visibility and dramatically reduced transaction processing and data processes.
Bookings Suite: Replaced the flat Booking record architecture whereby every incoming change replaced the previous fully detailed version, with a hierarchical structure whereby each line-level detail set, and each subsequent version change and transaction was grouped as sub-lists under the new Master Booking record, including Deposit Earmarks. Master Booking record now serves as the single user interface for customer service representatives, and makes data for reporting far more accessible.
Bookings Integration was updated to support the new architecture.
New Transaction Types: Vendor Deposits, Vendor Deposit Refunds, Single Use Credit Cards were configured to specifically manage the unique accounting requirements, with some new GL accounts, and all required auditable details applied and linked to Master Booking.
Transaction Automations: SOs and POs were eliminated, and with all changes effectively stored at the top of hierarchy (Bookings Suite) only the final transactions are created, after all stay details have been reported, including invoices, vendor bills, late fees, change fees, various refund types, and journal entries to clear certain GL accounts.
Data Entry User-Interfaces: After automation so much of what used to require manual data entry/edits, anything a user did have to interact with could be done from an editable list view.
*Image provided by Michael Monahan
