BookingsPayments
Guest relocations as a first-class flow
Hotel booking platform, 1M+ users a month
Otello (2GIS)
2025 · Led the feature over two months, from requirements to release
~150 h
of support work saved every month
The problem
Sometimes a hotel cannot host a guest who has already paid, and the guest has to be rehoused fast.
Support did this by hand: found a new hotel, booked it, and occasionally paid with a personal card. The only record of what happened lived in chat logs. Every case took manual work and left no structured trail for accounting or disputes.
What I did
- Led the feature over two months: shaped the requirements with support and product, wrote the technical design, split the work into a plan and took it to release.
- Designed the flow so that each relocation creates its own booking and its own payment, both linked to the original order.
- Implemented the booking and payment side in Go on PostgreSQL, and wrote the whole chain into the order history: original booking, relocation, payments.
Decisions
- A relocation is a new booking and a new payment, not an edit of the original. Money and history stay traceable per step.
- The link to the original order is explicit, so support, accounting and the admin panel see one chain instead of unrelated records.
What changed
- Support stopped rebooking guests by hand: about 150 hours a month back.
- No more personal cards. Every relocation is paid through the platform and shows up in the order history.
- Both the original and the new booking are visible in the admin panel with their payments.
Stack
GoPostgreSQLAdmin panel