Розробка мобільного додатка для кінотеатру під ключ

Чому мобільний застосунок кінотеатру втрачає глядачів

Прем'єрний вечір показує вузьке місце чесніше за будь-який звіт: попит на сеанс вкладається в годину-півтори, а каса встигає оформити замовлення строго по одному.

Пошук сеансу, вибір місця, оплата, друк — кожен крок з'їдає секунди, яких у пік немає, і черга в касі розтягується до початку показу.

Частина глядачів розвертається й іде, частка залу залишається непроданою, і такий недобір зборів повторюється кожну велику прем'єру — ще одне вікно в касі його не лікує.

Друга втрата тихіша, але коштує дорожче. Глядач, якому незручно купувати квиток біля самого кінотеатру, йде до посередника: сеанс продано, а дані про покупця, історія відвідувань і канал зв'язку залишаються в чужій вітрини.

Кінотеатр платить за кожну приведену людину і все одно не може покликати її напряму — повторні відвідування не збираються в постійну аудиторію, а перехід глядача до посередника стає звичкою.

Мобільний застосунок кінотеатру закриває обидва розриви: продаж квитків онлайн прибирає чергу в касі, замовлення з вибором місця й оплатою вкладається в хвилину і потрапляє в систему кінотеатру разом з даними глядача.

Далі працює утримання — нагадування про сеанс, персональна афіша за жанрами, повернення на наступний показ. Розбираємо, як це закривається: від контуру продажів до схеми, за якої глядач повертається до кінотеатру, а не до посередника.

Що дає власний застосунок: ефект у вимірюваних показниках

Власний застосунок перестає бути доповненням до каси й стає основним каналом продажу квитків. Нижче — показники, за якими ми вимірюємо ефект на проєктах кінотеатрів: їх знімаємо з аналітики бронювань, завантаження залів та історії візитів.

Частка онлайн-продажів у своєму каналі

За галузевими вимірами Невафильм Research, глядач дедалі частіше обирає сеанс зі свого пристрою, а не біля стійки.

Застосунок знає історію покупок і пропонує формат, зал і час під конкретного глядача — частка онлайн-продажів через власний канал сягає двох третин, і каса розвантажується в пікові вечори.

Час оформлення замовлення скорочується до хвилини

Шлях від афіші до квитка — чотири-п'ять дій: сеанс, місця, оплата. Збережена картка й місця з минулої покупки скорочують оформлення до 30–40 секунд, тому глядач не йде до посередника на середині, а зал заповнюється рівніше — місця розбирають за години до початку, а не за хвилини.

Лояльність і нагадування повертають глядача

Програма лояльності кінотеатру живе в профілі: бали, рівні й персональні пропозиції нараховуються автоматично, пластикова картка й диктування номера касиру не потрібні.

Нагадування про сеанс надходить за пару годин до початку разом із квитком і маршрутом — частка неявок падає, а повторні візити першого року зростають на 15–20%, бо сповіщення повертає тих, хто вже купував.

Підходи до розробки: єдина база, окремі збірки, веб-версія

Вибір способу збірки диктують не звички команди, а кількість залів, пік продажів у прем'єрні дні та стан квиткової системи.

Якщо вона віддає броні й схему залів через відкритий інтерфейс, підійде будь-який варіант із таблиці; якщо закрита — частину сценаріїв доведеться закривати нативними вставками.

Далі порівнюємо не лише запуск, а й вартість володіння рішенням: підтримку двох платформ, оновлення під нові версії операційних систем, доопрацювання під акції та зміни в програмі лояльності.

Готова оболонка дешевша на старті, але прив'язує до чужого графіка релізів, а веб-версія без встановлення простіша в підтримці, але гірше повертає глядача в застосунок.

Етапи впровадження: від аудиту квиткового контуру до передачі

Застосунок кінотеатру — надбудова над квитковим контуром: касами, схемою залів, бронюванням, лояльністю й платежами. Тому починаємо не з верстки екранів, а з інвентаризації того, що вже працює, і з опису обміну між застосунком та обліковою системою. Нижче — послідовність, за якою відбувається впровадження.

1. Аудит квиткової системи. Дивимося, що віддає поточний контур: сеанси, зали, статуси місць, типи квитків, знижки, повернення. Фіксуємо, що закрито зовнішнім інтерфейсом, а що доведеться добудовувати на боці сервера.
2. Схема обміну даними. Узгоджуємо зіставлення сутностей: сеанс, зал, ряд і місце, замовлення, платіж, повернення, промокод. Без єдиного опису каса й застосунок бачать одне місце по-різному — і продають його двічі.
3. Прототип екранів. Збираємо клікабельний макет: афіша, вибір сеансу, схема залу, оплата, квиток із кодом входу. Спірні місця навігації дешевше зловити тут, ніж у готовому коді.
4. Збірка й підключення сервісів. Підключаємо платежі, сповіщення, лояльність, аналітику. Контур для перевірок тримаємо ізольованим, щоб прогони не зачіпали реальні продажі.
5. Тестові сеанси. Прогонюємо сценарії на справжньому розкладі, включно з поверненням після початку, невдалою оплатою та місцем, зайнятим у залі. Окремо дивимося поведінку при обриві зв'язку.
6. Приймальна перевірка. Замовник проходить список перевірок на своїх пристроях: купівля, вхід за кодом, повернення, повторне надсилання квитка. Розбіжності закриваємо до релізу.
7. Передача й навчання. Віддаємо вихідники, доступи, схеми обміну та інструкції для адміністраторів і касирів, щоб підтримка не залежала від нас.

Комплект передачі: збірки, доступи, схеми й регламенти

Комплект передачі — не папка з файлами, а набір артефактів, за якими ваша команда зможе розвивати застосунок і випускати оновлення без нашої участі. Нижче — що саме залишається у замовника і в якому вигляді. Приймання відбувається за цим переліком: кожен пункт або є, або передача не закрита.

• Вихідний код — сховище з повною історією змін і правами власника у вас, окремо від нашої інфраструктури. Збірка з чистого клону відтворюється тими самими командами, що й у нас.
• Ролі й доступи — матриця прав за рівнями: адміністратор кінотеатру, контент-менеджер, підтримка, аналітика. Доступи оформлюються на ваші акаунти в консолях магазинів застосунків, сервісах сповіщень і аналітики, а не на наші.
• Схема інтеграції — як застосунок обмінюється даними із системою розкладу, продажу квитків і лояльності: перелік запитів, обов'язкові поля, поведінка при недоступності зовнішнього сервісу.
• Зібрані версії — підписані релізні й тестові збірки під кожну платформу, ключі підпису та інструкція щодо їх зберігання. Викладка в магазини відбувається з вашого акаунта.
• Документація адміністратора — покрокові сценарії: сеанси й ціни, акції та промокоди, пуш-сповіщення, ролі співробітників, розбір типових звернень до підтримки.
• Регламент випуску оновлень — порядок перевірок перед викладкою, хто погоджує, вікно публікації, як відкочується проблемна версія.
• Моніторинг і реакція на збій — які події вважаються критичними, кому надходить оповіщення, що робити до втручання розробника.

Передача вважається завершеною, коли ваша команда власними руками збирає й публікує тестову версію, а ми лише спостерігаємо. Опишіть задачу — повернемося з оцінкою та планом передачі за цим переліком.

Кейс: мережа кінотеатрів перевела продаж квитків у свій канал

До запуску власного застосунку мережа «Кадр» продавала квитки через касу та сторонні вітрини. У прем'єрні вечори касири фізично не встигали: черга розтягувалася на весь хол, частина гостей ішла, а покинуті кошики в зовнішніх сервісах ніхто не обробляв — звернення губилися мовчки.

Ми підняли застосунок на тій самій схемі залів, яку використовує касове ПО: залишок місць синхронізується в реальному часі, вибране крісло тримається під коротким резервом, тому одне місце не йде двом покупцям.

Квиток зберігається в застосунку й відкривається без мережі — на вході сканується код, і контролер не залежить від зв'язку в залі. Сповіщення про відкриття продажів на прем'єру надходить підписникам заздалегідь, і потік гостей розподіляється до початку вечірнього піку.

Метрики до і після

У цьому кейсі кінотеатру важливий не сам запуск, а перерозподіл каналів: замовлення, історія візитів і підписки на прем'єри залишаються в мережі, а не в посередника. Каса перестала бути вузьким місцем у пікові вечори, і її розвантаження видно в цифрах, а не у звіті.

Що робити, якщо квиткова система вже працює і змінити її не можна

Застосунок не потребує заміни облікового контуру: він ставиться над чинною квитковою системою, а каса на час переходу залишається джерелом істини щодо місць і замовлень.

Між ними — тонкий шар-посередник, який перекладає запити застосунку у виклики Кино Класс і назад, тому логіка броні й оплати живе в одному місці, а не дублюється в двох системах.

Поетапне впровадження будується на флагах увімкнення. Спочатку застосунок працює в тіньовому режимі: віддає розклад і наявність місць із читальної копії, а покупки йдуть лише через касу — так ми звіряємо розбіжності щодо вільних місць, не ризикуючи продажами.

Потім продаж у застосунку вмикається на частині залів і сеансів, і частка каналів зростає за фактом звірок, а не за планом.

Співіснування каналів тримається на короткому блокуванні місця на час оформлення та захисному ключі замовлення: повторний запит через обрив зв'язку не створює другого квитка.

Якщо квиткова система недоступна, запити йдуть у чергу повторних спроб, і глядач бачить чесний статус броні, а не помилку оплати.

Дані про глядача переносяться без вивантаження всієї бази: картка зіставляється за телефоном або поштою під час першої покупки, історія підтягується в міру звернень.

Відкат при збої — це вимкнення флага: весь трафік повертається в касу, застосунок залишається вітриною з розкладом, уже продані квитки не зачіпаються.

Технічні сумніви: інтеграції, оплата, робота без зв'язку

Перед оцінкою зазвичай виринає той самий набір питань: як застосунок стикується з касою, що відбувається при збої мережі, як рахуються місця за кількох залів. Нижче — короткі відповіді інженерного рівня.

Якщо ваш сценарій не потрапляє в жоден із них, розберемо його окремо й зафіксуємо в плані робіт.

Що показувати глядачеві, коли в залі немає сталого зв'язку?

Код проходу вивантажується на пристрій заздалегідь і перевіряється офлайн, тому вхід не залежить від покриття. Афіша й куплені квитки відкриваються з локального кешу, синхронізація — за першого сталого з'єднання.

Як влаштована оплата квитка?

Платіж проводить провайдер, дані картки не проходять через застосунок і не зберігаються в нас. Успішною покупка вважається лише після серверної перевірки, а не за відповіддю на пристрої.

Як оновлюється афіша, якщо в мережі кілька залів і майданчиків?

Розклад описано єдиною моделлю: майданчик — зал — сеанс. Правки надходять із каси автоматично, без випуску нової версії застосунку, а знятий сеанс позначається, а не видаляється.

Як захищені персональні дані?

Зберігаємо мінімум: телефон та історію замовлень. Доступ — за ролями, дії адміністраторів пишуться в журнал, передача — захищеним каналом.

Обговоримо задачу й повернемося з оцінкою та планом

Щоб розмова була предметною, а оцінка — спиралася на факти, а не на припущення, нам потрібні вхідні дані щодо вашої поточної інфраструктури.

Чим точніше опишете процеси навколо продажу квитків, тим менше припущень залишиться в плані робіт і тим реалістичнішою буде оцінка термінів.

• Схему залів і розмітку місць: категорії, ряди, місця для інвалідних візків, місця з обмеженим оглядом, конфігурації під різні формати показу.
• Склад квиткової системи: де зберігається схема залів, як віддаються вільні місця, чи є резервування і як обробляється одночасна покупка одного місця з каси та із застосунку.
• Опис потоку в прем'єрні дні: скільки сеансів, як швидко розходиться зал, у який момент навантаження максимальне, що ламається першим зараз.
• Правила лояльності та знижок: абонементи, бонусні картки, промокоди, знижки на ранкові сеанси, їхня сполучуваність між собою.
• Що вже працює: сайт, каса, чинний застосунок, — щоб зрозуміти, що переносимо, що переписуємо, а що залишаємо як є.
• Обмеження щодо запуску: дату прем'єри або сезон, до якого застосунок має бути готовий, і обов'язкові перевірки перед публікацією.

У відповідь повернемося з оцінкою термінів і планом робіт: склад робіт за етапами, порядок приймання, що робимо ми і що потрібно з вашого боку. Опишіть задачу в зручній формі — решту уточнимо на розмові.