A party takes five resources.No double bookings.

Ordinary online booking sells one service at one time. A kids’ party works differently. First the children play a quest in a room, then move to the activity zone for a challenge and a disco, then to the tea zone. While they have tea, the room gets cleaned. And all along, the venue belongs to their group alone.

This used to be the manager’s maths: how long the party runs, whether the tea zone is free in an hour and a half, whether the room can be cleaned before the next group. We moved those rules into the engine. A party is made of phases, each phase takes its own resources, with 5 minutes to move between phases, 30 minutes of cleanup after a kids’ quest and 20 after an adult one. A kids’ party ends no later than 23:00.

The worst thing in online booking is two bookings for the same time. On a Saturday afternoon it’s a real risk: several parents pick a time at once, and every phase of a party overlaps with its neighbours.

We closed this on two levels. When a customer picks a time, the engine locks every resource it needs and only then checks that it’s free. Confirmed bookings are also protected by a constraint in the database itself: even a bug in the code couldn’t write two overlapping parties into one room. The second customer immediately sees “this time is taken” and picks another.

There is also protection against repeats. If a customer’s connection drops and the page sends the same booking again, the engine recognises it by its key and doesn’t create a second one.

The server prices everything from a versioned catalogue: a quest for 6 children from 6,500 RUB, +800 RUB for each additional child, packages, challenges and extras. It ignores any amount sent by the page, and the payment amount is fixed when the payment is created.

A booking appears in amoCRM and the venue calendar straight away: yellow until prepaid, green after. The 2,000 RUB prepayment goes through YooKassa, and a note is added to the deal. If there’s no payment within 30 minutes, the time is released, the calendar event is removed and the manager gets one task. Every external step — CRM, calendar, payment — retries once a minute if it fails.

Booking with online prepayment went live on 9 October, after a 1 RUB test payment the night before. “Book” buttons sit on the kids’ quest pages, in the quiz and in the bot.

On 4 August the MORPHEUS theatre’s YClients subscription ran out, and it needed booking on its own website that same day. We didn’t repaint the cinema widget: it used cinema rates and recorded bookings as film sessions. Instead, the theatre got its own booking type on the shared core, which already handled theatre bookings and CRM fields.

What’s specific to the theatre stays specific. Shows have a day price until 18:00 and an evening price after, up to 4 guests in the price and +1,000 RUB for each additional one, 6 at most. The hall is separate, so a show can run alongside the cinema and the quests. The customer pays a 2,000 RUB prepayment and uploads the receipt, and the manager sees a link to it in the deal.

Cinema, theatre and escape-room booking follow the same rules: the server sets the price, an unpaid booking is held for 30 minutes, a prepayment secures the time, and bookings land in the venue calendar and the CRM. Only the rates differ, along with what is being booked: a film session, a show or a party made of several phases.

So a new venue or a new format doesn’t need a new system. The theatre moved in a day because the core was ready. Kids’ parties needed a richer resource model, and it sits alongside the shared rules rather than replacing them.