
Система управления оповещениями для горнолыжного курорта
Заказчик: Крупный горнолыжный курорт с несколькими зонами катания, где в пиковые часы популярные канатные дороги перегружены, а гости стоят в очередях до 30 минут.
Задача: Создать систему, которая на основе прогнозов загрузки автоматически отправляет гостям Telegram/SMS-оповещения: «эта канатка переполнена, проезжайте на другую». Это позволило бы перераспределять поток и снижать очереди без расширения инфраструктуры.
Проблемы: Прогнозы формировала внешняя система, но её данные были нестабильными, а API иногда работал некорректно. Требовалось исключить ложные срабатывания и спам, учесть время суток, зоны курорта и сложность трасс. Чёткого регламента, как именно оповещать гостей, не было.
Что сделали: За 3 месяца команда АЙТИФОКС разработала Django-админку с гибкими сценариями оповещений, интегрировала её с внешним API и спроектировала логику срабатывания с защитой от нерелевантных рассылок. На основе двухлетних данных команда подготовила 30 сценариев оповещений.
Итог: Система прошла интеграционные тесты, 30 сценариев приняты заказчиком и подтверждены его аналитикой.
Почему заказчик решил автоматизировать оповещения
Представьте горнолыжный курорт в разгар сезона. Утром и днём одни подъёмники переполнены — люди стоят по 30 минут, нервничают, толкаются. В это же время соседние канатки пустуют. Персонал пытается регулировать потоки вручную, но это малоэффективно: невозможно одновременно следить за всеми зонами и быстро сообщать гостям, куда лучше идти.
Заказчик хотел не просто ускорить проход, а научиться заранее предупреждать гостей о загрузке. Идея: на основе прогнозов автоматически отправлять сообщения — «эта канатка скоро будет переполнена, поезжайте на другую». Это позволило бы распределить поток без расширения инфраструктуры и без участия персонала.
Часть системы — прогностическую модель — разрабатывал другой подрядчик, мы же сделали админку, которая будет получать прогнозы и запускать оповещения.
Задача и в чём была главная сложность
Когда мы начали разбираться, выяснилось, что самое трудное — не написать админку, а понять, как она должна себя вести.
Второй момент — не было правил, по которым это должно работать. При каком пороге считать канатку перегруженной? Как часто отправлять? Учитывать ли время суток и сложность трасс? Всё это мы собирали по кусочкам: предлагали гипотезы, обсуждали с заказчиком, проверяли на тестовых данных. Порой решение выглядело очевидным, а потом выяснялось, что в реальности оно создаёт нагрузку на персонал или путает гостей.
Ну и третий фактор — время. Весь проект вместе с аналитикой двухлетних данных должен был уместиться в три месяца. Из-за этого у нас не было права на долгие согласования: мы быстро принимали решения, тестировали на единственном киоске, который привезли прямо в офис, и итерациями доводили логику до ума.
Какие были ограничения
|
Что мешало |
Как мы с этим работали |
|
Прогнозы нестабильны |
Настроили проверку нескольких последовательных прогнозов перед отправкой, чтобы исключить ложные срабатывания |
|
Логика не продумана |
Провели 4–5 итераций, проверяя гипотезы вместе с заказчиком |
|
Внешний API сбоил |
Постоянно мониторили, фиксировали проблемы и оперативно передавали заказчику |
|
Срок — 3 месяца |
Сразу начали с аналитики и параллельно проектировали логику |
|
Команда небольшая |
Работали двумя специалистами: разработчик и бизнес-аналитик, который совмещал тестирование и коммуникацию |
Что мы сделали
Команда АЙТИФОКС разработала на Django систему управления сценариями оповещений для горнолыжного курорта. В админке можно создавать и настраивать сценарии без изменения программного кода.
Система получает прогнозы загрузки канатных дорог через API внешней прогностической системы, проверяет несколько последовательных значений и запускает отправку сообщения только после подтверждения триггера.
Параллельно АЙТИФОКС провёл бизнес-анализ двухлетних данных по загрузке канатных дорог и на их основе подготовил 30 сценариев для разных пиковых ситуаций.
Главные решения по логике
Пороги загрузки. Сначала система считала канатку перегруженной слишком рано, хотя на самом деле люди ещё могли поместиться. Из-за этого предупреждения уходили впустую, а персонал отвлекался на ложные срабатывания, подняли пороги — теперь оповещение срабатывает, только когда загрузка достигает 80–90% от того, сколько людей она реально может принять.
Время отправки. Изначально сообщения уходили сразу после срабатывания, но на практике это оказалось неудобно: в пиковые часы гостям важно получить информацию как можно быстрее, а вечером лишнее уведомление только мешает. Сделали время отправки настраиваемым в зависимости от времени суток.
Зоны и сложность трасс. Курорт разделён на зоны, трассы разной сложности: На «синих» трассах больше всего гостей — там оповещения должны быть быстрыми и точными, на «чёрных» людей меньше, но цена ошибки выше: если гости массово поедут не туда, это перегрузит другую зону. Для каждой зоны настроили свои правила срабатывания.
Итерации. Мы провели 4–5 волн настроек. Часть параметров добавляли, часть убирали. Это была не доработка «по наитию», а практическая проверка гипотез вместе с заказчиком.

Какие инструменты использовали
- Django — для админки и управления сценариями.
- База данных — для хранения настроек и логов срабатываний.
- Интеграция по API — для получения прогнозов от внешней системы.
- Telegram/SMS-каналы — для отправки оповещений гостям.
- Бизнес-аналитика — обработка двухлетних данных по загрузке канаток.
Как мы работали
Проект длился около трёх месяцев. Команда — два человека: разработчик и менеджер проекта.
Типичный цикл выглядел так:
- Анализировали данные по загрузке канаток и проектировали сценарии.
- Реализовывали настройки в админке и подключали к API.
- Тестировали срабатывание триггеров на тестовых данных.
- Обнаруживали проблему (например, нестабильный прогноз или ложное срабатывание) — связывались с командой заказчика.
- Они правили свою часть или уточняли требования, а мы дорабатывали логику.
- Через несколько дней — снова проверка новой версии.
Так, итерациями, мы за 3 месяца превратили «сырую» идею в готовую систему с 30 сценариями.
Итог
АЙТИФОКС разработал и протестировал систему управления сценариями оповещений для горнолыжного курорта. Команда подготовила 30 сценариев, которые были проверены аналитикой заказчика и приняты в работу.
Что мы обеспечили:
- Защиту от нерелевантных рассылок — сообщения уходят только при подтверждении.
- Гибкие настройки под зоны, время суток и сложность трасс.
- Готовую админку, в которую можно добавлять новые сценарии без переписывания кода.
- Полную интеграцию с внешней прогностической системой.
Мы уже делали для этого курорта другую систему
Ранее АЙТИФОКС разработал для этого же горнолыжного курорта систему бронирования через киоски, которая позволила гостям заранее бронировать время спуска и проходить без очереди. Результат: очереди сократились в 2–3 раза, за два сезона прошло более 10 000 бронирований. Подробнее об этом проекте можно почитать здесь.
Почему даже «простая» интеграция оказалась непростой
Часто заказчики думают: «У нас уже есть система прогнозирования, нужно только подключиться и слать сообщения. Это же просто». На деле именно в таких задачах всплывают главные риски: нестабильные данные, непродуманная логика, сжатые сроки.
АЙТИФОКС разрабатывает системы автоматизации с внешними API, сложной бизнес-логикой и интеграциями с существующими IT-системами заказчика. Видим проект целиком: анализируем данные, проектируем сценарии, продумываем защиту от ложных срабатываний и доводим систему до рабочего состояния — даже если внешние сервисы работают с перебоями.
Если у вас есть данные, прогнозы или внешние системы, которые нужно превратить в управляемые сценарии оповещений — напишите нам. Обсудим вашу задачу.
Технологии
Часто задаваемые вопросы
Кейсы, которыми мы гордимся



