Розробка тикетингової платформи: де ламається продаж квитків
Продаж квитків — це коротке вікно, в якому сходиться все: маркетинг приводить трафік на старт продажів, платіжний провайдер відповідає із затримкою, а зал на 5 000 місць розбирають за хвилини.
Саме тут найчастіше ламаються самописні системи: пікове навантаження в перші секунди продажів вибиває базу, а подвійне бронювання спливає вже після оплати, коли двоє людей тримають один і той самий ряд.
Корінь більшості збоїв — в обліку місць. Якщо залишок вільних крісел рахується за лічильником у застосунку, а не за фактом зайнятості у сховищі, то при паралельних запитах двоє покупців отримують підтвердження на одне місце.
Різниця в частки секунди між перевіркою та записом — і на виході подвійний продаж, ручні повернення та репутаційна шкода в день релізу.
Розсинхрон місць і оплат додає другий шар проблем: платіж пройшов, а місце не закріпилося — або навпаки, бронь висить і блокує зал, поки гроші не дійдуть.
Без фонового зняття прострочених броней і звірки статусів із платіжним провайдером зал «залипає», а підтримка вручну розбирає кожен випадок. Повернення, обміни та перенесення на інший сеанс у такій схемі теж лягають на операторів.
Ми проєктуємо тикетингові платформи так, щоб ці вузькі місця закривалися на рівні архітектури, а не героїчними зусиллями команди в день старту. Розбираємо, як це влаштовано і які рішення знімають навантаження до того, як воно стане інцидентом.
Що дає керована платформа продажу квитків
Кероване бронювання вирішує головну проблему квиткових систем — гонку за місцем. Коли на один і той самий ряд одночасно надходять сотні запитів, місце закріплюється за конкретною сесією на короткий проміжок і звільняється автоматично, якщо оплата не пройшла.
Це прибирає подвійні продажі та «завислі» бронювання, через які підтримка розбирає конфліктні замовлення вручну.
Швидкість оформлення замовлення безпосередньо впливає на конверсію: чим менше кроків між вибором місця та оплатою, тим вища частка завершених покупок.
Ми зводимо шлях покупця до мінімуму — вибір, підтвердження, оплата — а стан кошика зберігається між пристроями, щоб людина не втрачала вибрані місця при перемиканні з телефона на комп'ютер.
Повернення та обміни перестають бути ручною роботою. Правила повернення описуються один раз: строки, частка утримання, умови для різних категорій подій.
Далі система сама звільняє місце, повертає його в продаж і запускає виплату — частка автоматичних повернень зростає, а навантаження на операторів падає.
Сплеск попиту — момент, коли стартує продаж на популярну подію і трафік за хвилини зростає в рази. Платформа тримає чергу запитів, розподіляє навантаження і не втрачає вже вибрані місця: покупець бачить зрозумілий статус очікування замість помилки. У пікові години продажі йдуть без обвалів, а місце залишається за тим, хто почав оформлення першим.
Моделі продажу квитків: порівняння підходів
Вибір моделі — це не «який движок візьмемо», а те, як влаштована посадка, скільки сутностей живе в замовленні та що відбувається при поверненні.
Помилка на цьому рівні спливає пізніше: переповнена зала, подвійний продаж місця або неможливість продати абонемент без переписування схеми даних.
| Модель | Коли підходить | Обмеження |
|---|---|---|
| Загальна схема зали | Театри, концертні майданчики, конференції з фіксованими місцями | Потрібна актуальна карта зали та правила видимості; перепланування вимагає перемальовування схеми й перерахунку вже проданих місць |
| Вільна посадка (без місць) | Фестивалі, open-air, вхідні квитки на потік | Не можна продати конкретне місце й запропонувати апгрейд; місткість контролюється лише лічильником, а не картою |
| Сеанси з місцями | Кінотеатри, повторювані покази, мультизальні майданчики | Кожен сеанс — окрема сутність зі своїм розкладом; зростає обсяг даних і складність звітності щодо завантаження |
| Абонементи та серії | Філармонії, театри, курси, регулярні події | Потрібен облік залишку відвідувань і правил перенесення; повернення рахується інакше, ніж у разового квитка |
На практиці майданчики рідко живуть в одній моделі: вдень — сеанси з місцями, ввечері — вільна посадка на фестивалі, плюс абонемент на сезон. Тому схему зали й логіку посадки ми виносимо в окремий шар, а не «зашиваємо» в квиток.
Тоді нова модель додається конфігурацією, а не переробкою ядра, і вже продані замовлення залишаються валідними.
Обмеження моделі варто проговорити до старту розробки тикетингової платформи: від них залежить і схема даних, і те, як рахуватимуться повернення, перенесення та звітність щодо завантаження. Опишіть, як продаєте зараз і що плануєте додати — повернемося з оцінкою та планом.
Як ми ведемо розробку тикетингової платформи
Розробка тикетингової платформи починається не з коду, а з розбору того, як квитки продаються зараз: де губляться замовлення, в який момент схема місць упирається в блокування, які способи оплати реально використовують покупці.
Такий аудит продажу показує вузькі місця до того, як вони перетворяться на переписування половини системи.
- Аудит поточного продажу. Дивимося воронку від вибору події до виданого квитка, рахуємо частку покинутих кошиків і відмов на оплаті, фіксуємо пікові вікна — старт продажів на популярну подію, повернення, перенесення. На виході — карта проблемних ділянок із пріоритетами.
- Схема даних. Проєктуємо модель подій, місць, тарифів, замовлень і платежів так, щоб місця й ціни не дублювалися між залом і складом квитків. Заздалегідь закладаємо історію змін: перенесення події або повернення не повинно ламати вже продані квитки.
- Утримання місць. Налаштовуємо тимчасове блокування вибраного місця на час оформлення: місце недоступне іншим покупцям, але звільняється автоматично, якщо оплата не пройшла. Це прибирає подвійні продажі без ручного розбору конфліктів.
- Інтеграції оплат. Підключаємо потрібні способи оплати й повернення, синхронізуємо статуси платежів із замовленнями, обробляємо повторні спроби й скасування. Кожен платіж отримує однозначний статус — бухгалтерія й підтримка бачать одну картину.
- Перевірка під навантаженням. Проганяємо сценарій старту продажів із розрахунковою кількістю одночасних покупців, перевіряємо поведінку утримання місць і черг оплати. Окремо дивимося, що відбувається при відмові зовнішнього платіжного сервісу.
- Передача. Розгортаємо платформу, передаємо доступи, схеми й регламенти, навчаємо команду замовника роботі з адмінкою та розбору інцидентів.
Порядок етапів невипадковий: схема даних і утримання місць визначають, чи витримає платформа пік, а інтеграції оплат і перевірка під навантаженням підтверджують це на реальних сценаріях. Опишіть вашу задачу — повернемося з оцінкою та планом за етапами.
Політики доступу, ролі та регламенти повернення
Права в тікетиновій платформі описуються не «на словах», а матрицею ролей: касир, старший зміни, організатор, фінансовий контролер, адміністратор майданчика.
Кожній ролі відповідає набір операцій — продаж, бронювання, повернення, обмін, сторно, вивантаження звітів, — і ці правила живуть у конфігурації, а не в інструкції на стіні. Тоді новий співробітник отримує рівно той обсяг доступу, який йому потрібен, а не «як у колеги».
Окремий шар — регламенти повернення та обміну. Платформа повинна вміти рахувати повернення за правилом самої події: частка утримання, крайній термін, повернення лише частини замовлення, обмін на іншу дату або категорію місця.
Правила задаються на рівні події та успадковуються вкладеними тарифами, тому організатор не переписує умови вручну під кожну залу.
Ліміти операцій закривають головний ризик касових змін — великі повернення та сторно «в один клік». Поріг суми, кількість операцій за зміну, обов'язкове підтвердження старшим — усе це налаштовується та логується.
Що фіксуємо в конфігурації та документації:
- матрицю ролей доступу з переліком дозволених операцій для кожної;
- правила повернення: терміни, частки утримання, винятки за категоріями місць;
- сценарії обміну квитків між датами, тарифами та власниками;
- ліміти на повернення, сторно та ручне коригування замовлення;
- порядок підтвердження операцій старшим зміни або контролером;
- журнал операцій: хто, коли, за яким замовленням, з якою підставою;
- регламент звірки каси та вивантаження звітів для бухгалтерії;
- політику зберігання та вивантаження персональних даних покупців.
Журнал операцій незмінний: запис не можна відредагувати заднім числом, лише додати коригувальний із посиланням на вихідний. Це те, що перетворює спірне повернення з «розгляду по пам'яті» на перевірювану історію з відповідальним і підставою.
Кейс: як платформа витримала старт продажів
Замовник — організатор концертних і театральних подій — прийшов із класичним болем тикетингової платформи: у перші хвилини старту продажів сайт лягав, а в замовленнях з'являлися подвійні бронювання на одні й ті самі місця. Розбираємо, що саме ламалося і як це закрили.
Що було до
Під піковим навантаженням замовлення оформлювалися в середньому за 40-50 секунд, частина користувачів не дочікувалася відповіді й ішла. Частка подвійних бронювань сягала 3-4% від усіх замовлень — кожну таку ситуацію розбирали вручну, а повернення коштів тривало днями. Під час старту продажів на популярну подію сервіс переставав відповідати протягом перших хвилин.
Що змінили
Перевели резервування місць на атомарні операції: місце блокується на короткий час і або підтверджується оплатою, або автоматично звільняється — гонка за один і той самий ряд більше не створює дубль.
Запровадили чергу на оформлення замовлення: під піком запити обробляються по порядку, а не обвалюють базу. Повернення перевели на автоматичний сценарій із перевіркою правил події.
Що стало після
Частка подвійних бронювань упала до часток відсотка й тримається на цьому рівні. Середній час оформлення замовлення скоротився до 8-12 секунд навіть у момент старту продажів. Частка автоматичних повернень зросла до 90%+ — ручний розбір майже зник. Платформа на базі Eventim витримала старт продажів без падінь і ручних втручань.
Чим відрізняється утримання місця від бронювання на час?
Це два різних стани місця в схемі залу, і різниця між ними — не термінологічна, а інженерна. Бронювання на час — це коротке блокування на період, поки клієнт вводить платіжні дані: місце позначається як зайняте, але право на нього ще не підтверджено.
Утримання місця — триваліший стан, за якого місце закріплене за конкретним замовленням і чекає на підтвердження оплати вже після того, як платіж пішов в обробку.
Змішувати їх в одній логіці не можна: якщо тримати місце годинами на етапі введення картки, зал «залипне» і продажі зупиняться.
Ключовий параметр тут — таймер і умова його скидання. У бронювання на час відлік іде від моменту вибору місця і переривається, щойно платіж прийнято або клієнт пішов.
В утримання відлік прив'язаний до статусу транзакції: місце залишається за замовленням, поки платіжний шлюз не поверне фінальну відповідь. Поки відповіді немає — місце не можна віддавати іншому, інакше отримаємо подвійний продаж і повернення.
Звільнення місця — це зворотна операція, і вона має спрацьовувати автоматично за кількома тригерами: минув таймер, платіж відхилено, замовлення скасовано клієнтом або оператором.
Добре спроєктована платформа звільняє місце не «колись», а тієї ж секунди, коли стан замовлення перестав бути активним, — інакше зал показує зайняті місця, які насправді вільні.
Підтвердження оплати — єдина подія, яка переводить утримання в повноцінний проданий квиток. До нього місце рахується зарезервованим, після — стає незворотно зайнятим, і звільнити його можна лише через повернення.
Саме на цій межі найчастіше ламаються самописні рішення: вони або відпускають місце занадто рано, або тримають вічно.
Ми розводимо ці стани на рівні моделі даних і таймерів, тому зал завжди відображає реальну картину, а не проміжні статуси. Опишіть, як у вас влаштовані продажі та схема залу, — повернемося з оцінкою та планом.
Що робити, якщо продаж квитків уже працює
Коли продаж квитків уже триває, змінювати все відразу — найгірше рішення: зупинка каси коштує дорожче, ніж сама заміна.
Тому ми спочатку розбираємо діючу систему: де зберігаються дані про замовлення та місця, як влаштовані канали продажу, які вузли тримають навантаження в пік, а які просто історично опинилися в ланцюжку. На виході — карта залежностей і список вузлів, які можна замінити окремо, не чіпаючи решту.
Далі йдемо поетапною заміною: першим виносимо вузол, який дає максимальний ефект за мінімального ризику — зазвичай це резервування місць або квитковий реєстр, бо саме там виникають подвійні продажі та розбіжності.
Новий вузол вмикається паралельно старому, трафік переводиться часткою, і тільки коли метрики збігаються, старий вимикається. Так кожен крок зворотний: якщо щось пішло не так, повертаємося до попереднього стану без втрати проданих квитків.
Канали продажу зберігаємо як є — сайт, каси, партнерські вітрини та зовнішні інтеграції продовжують працювати через попередні точки входу. Ми підміняємо начинку під ними, а не ламаємо звичні сценарії для покупця та оператора.
Це ключова умова: продажі не зупиняються на жодному етапі, а команда замовника продовжує працювати у знайомих інтерфейсах, поки нові поступово вводяться.
Окремо закриваємо цілісність даних під час переходу: звіряємо залишки місць, статуси замовлень і повернення на кожному кроці міграції, ведемо журнал розбіжностей і розбираємо їх до перемикання.
Без цього етапна заміна перетворюється на накопичення помилок, які спливають у найневідповідніший момент — у день старту продажів на велику подію.
Обговоримо ваше завдання щодо продажу квитків
Щоб оцінка була предметною, а не «середньою по ринку», нам потрібен мінімум вхідних даних: скільки подій і майданчиків, як продаєте зараз, які схеми бронювання та повернення, чи є інтеграції з платіжними провайдерами та вхідними турнікетами, які пікові навантаження очікуєте на старті продажів. Цього достатньо, щоб повернутися з планом та оцінкою за етапами, а не з однією цифрою «на все».
Далі працюємо так: розбираємо ваші матеріали, фіксуємо схему місць і правила бронювання, узгоджуємо архітектуру та обсяг першої черги, після чого передаємо на руки комплект, за яким платформу можна розвивати й підтримувати без нас.
- Схему залів і типів квитків: сектори, місця, квоти, правила розсадки.
- Сценарії купівлі: вибір місця, бронювання з таймером, оплата, повернення та обмін.
- Вимоги до навантаження: скільки одночасних покупців тримати на старті продажів.
- Перелік інтеграцій: платежі, розсилки, вхідний контроль, аналітика.
- Доступи та дані: тестові акаунти провайдерів, поточна база замовлень, якщо вона є.
- Обмеження: терміни, пріоритети, що вже працює і що не можна ламати.
Зі свого боку повертаємо оцінку за етапами зі складом робіт, план запуску першої черги, схему даних і бронювання, а також перелік ризиків — де вузькі місця і як їх закриваємо.
Після запуску беремо платформу на підтримку: стежимо за стабільністю в пікові продажі, оновлюємо залежності, доопрацьовуємо сценарії в міру зростання.
Опишіть завдання у вільній формі — повернемося з оцінкою та планом.
