Авторизация
Сброс пароля
Как сеть городских курортов заменила PDF на живые данные и подняла конверсию в 6 раз
Заказчик: Термоленд

Раньше цену и расписание нужно было искать в отдельном файле. Теперь они подтягиваются из 1С прямо в интерфейс покупки. В кейсе Alto — как это изменило конверсию сайта сети курортов.
1. Вводная задача от заказчика, проблематика, цели
Первичный осмотр: трафик на максимуме, конверсия на уровне погрешности
«Термоленд» — сеть термальных комплексов. Когда-то начинали как локальный проект, затем выросли до сети из 16 филиалов в Москве, Санкт-Петербурге и Краснодаре. Сайт всегда был основным каналом продаж, в него вкладывались и развивали. Но основа сайта так и осталась на уровне «локального комплекса» и уже не справлялась с нагрузкой.
Трафик на сайт шёл, маркетинговый бюджет работал, но показатели конверсии оставались на уровне погрешности. Инфраструктура не позволяла протестировать простую гипотезу без привлечения разработки на две недели.
В итоге работа коммерческого блока упиралась в дисбаланс: бизнес уже хочет бежать марафон, а инфраструктура сайта позволяет только медленно ходить. С этим они к нам и пришли.
На старте вызов был двойным:
- «Термоленд» не продает «билеты в СПА». Это сложный конструктор услуг: будни и выходные, льготные категории, абонементы, SPA-процедуры, пакетные предложения и сертификаты. Каждая позиция живет по своим правилам и должна синхронизироваться с базами 1С.
- Каждую минуту на сайте кто-то покупал. Любое резкое движение, попытка «переписать всё с нуля» или неудачный релиз останавливали продажи по сети.
Перед нами встал вопрос: как реформировать систему, когда продажи нельзя останавливать, то есть «вылечить связки», когда «марафонец уже стартовал»?
Когда команда проанализировала воронку продаж, увидели, что сайт работал как сито. Трафик был, но на этапе оплаты пользователи массово уходили.
Основные «боли», которые мешали бизнесу расти:
- Конверсия 0,3% на фоне высокого интереса: для отрасли это критически низкий показатель для лояльной аудитории. Пользователи заходили на сайт, чтобы отдохнуть, но вместо этого сталкивались с квестом. Огромная доля трафика просто «сливалась» в пустоту из-за перегруженных сценариев.
- «Маркетинговый паралич»: запуск любой сезонной акции превращался в бюрократический ад. Чтобы добавить промокод, нужно было ставить задачу разработке, ждать очереди в бэклоге, проходить цикл тестирования и релиза. Маркетинг не мог быстро запускать актуальные акции.
- PDF-барьер: актуальное расписание и цены хранились в статических PDF-файлах. Пользователю приходилось скачивать файл, изучать мелкий шрифт на смартфоне, запоминать условия для «будней после 18:00» и только потом возвращаться в интерфейс покупки, чтобы попытаться найти нужный билет. На этом этапе терялось до 40% потенциальных покупателей.
На первый взгляд казалось, что марафонец просто бежит в старой форме и достаточно «купить новые кроссовки» (сделать редизайн). Но внешние правки не решили бы проблему. Проект был истощен технически: «перекраска кнопок» не помогла бы там, где нужно восстанавливать фундамент, менять логику продукта и внедрять системный подход. Спортсмен бежал со связанными ногами, и проблема была не в форме, а в архитектурных ограничениях.
2. Описание реализации кейса и творческого пути по поиску оптимального решения
Что «заморозило» конверсию на уровне 0,3%
Симптомы указывали на интерфейс, но причины обнаружились в инфраструктуре. Сайт страдал от классических болезней быстрорастущего проекта, который долгое время дорабатывался разными подрядчиками.
Диагностика «красных флажков» выявила три критические зоны:
- «Фундамент» разработки отсутствовал: в проекте не было Git (системы контроля версий), вменяемых регламентов и управляемого бэклога. Каждое изменение вносилось «по живому». То есть любая попытка программиста поправить опечатку в корзине могла «внезапно уронить» расчет стоимости абонементов. Риск фатальной ошибки при релизе был слишком высок.
- Технологический тупик Битрикса: стандартная логика 1С-Битрикс «из коробки» не рассчитана на такие сложные механики. На сайте пытались совместить несколько акций, скидок и типов продуктов (билет + сертификат + SPA) в одной корзине. В итоге код превратился в нагромождение «костылей», где одна скидка блокировала другую, а итоговая стоимость в корзине могла не совпадать с ценой на кассе.
- Синхронизация с 1С: каждый из 16 филиалов работает в собственной базе данных и под отдельным юрлицом. Инфраструктура сайта не имела четкой прослойки для работы с этими данными. Это создавало постоянный риск рассинхронизации между тем, что видит пользователь на сайте, и тем, что реально происходит на объекте.
Для e-com директора это был диагноз: система находилась в состоянии «технического отравления». Любая попытка масштабировать бизнес на такой базе привела бы к коллапсу при первой же серьезной нагрузке. Система справлялась с текущими задачами, но расти дальше не позволяла.
Тактика малых шагов: развиваем систему без остановки продаж
Путей решения проблемы было три:
- 1. Снести всё до основания и построить заново
Очевидное, интуитивное, но редко правильное решение. Новая система, чистая архитектура, никакого legacy. Звучит привлекательно до момента, когда считаешь косты и потери. Остановка продаж на месяцы, кассовый разрыв и риск, что новая система просто не «побежит» так, как ожидалось. Такой риск мы не могли себе позволить.
- 2. Косметические правки
Поменять цвета, переставить блоки, обновить баннеры. Быстро, дёшево, безопасно. Только конверсия от этого вырастет на доли процента, а системные проблемы останутся ровно там, где были.
- 3. Последовательная трансформация
Мы выбрали путь развития системы итерациями без её остановки. Бизнес продолжает продавать, пока команда меняет логику изнутри.
Как это работало
Мы выдвигали гипотезы на основе данных Яндекс Метрики: точки выхода, глубина просмотра, поведение в корзине. Интуиция помогает задать направление, цифры — выбрать, куда идти первым.
Если итерация давала рост, мы закрепляли результат. Если гипотеза не срабатывала, мы теряли неделю, а не полгода разработки.
Параллельно выстраивали инфраструктуру: Git, регламенты разработки, процесс синхронизации двух команд. Это фундамент, без которого любые улучшения остаются хрупкими.
- 1. Прощай, PDF-расписание!
Главным барьером в воронке было расписание в PDF. Пользователь скачивал файл, разбирался в условиях, запоминал выбирал день — и только потом возвращался на сайт, чтобы найти билет на нужный день.
Мы перенесли выбор билетов в интерфейс сайта. Теперь прямо на главной странице пользователь выбирает дату, тип билета и количество — цены подтягиваются автоматически из 1С. Можно сравнить варианты, добавить нужное количество и положить в корзину, не покидая страницу.
- 2. Умная корзина
Часто пользователи отказывались от покупки из-за ошибки при покупке детских билетов. По правилам комплекса ребенок не может находиться в термах без взрослого. Старая система просто выдавала ошибку: «Покупка невозможна». Пользователь злился и уходил.
Мы внедрили логику «зависимых сценариев». Если в корзине только детский билет, интерфейс не блокирует действие, а мягко подсказывает: «Для посещения ребенку нужен сопровождающий», и предлагает добавить билет для взрослого в один клик.
Для роста среднего чека добавили автоматическую скидку при покупке от пяти билетов. Стоимость пересчитывается в реальном времени при любом изменении корзины.
Переписали с нуля систему подарочных сертификатов. Электронный сертификат приходит сразу после оплаты — PDF с QR-кодом на почту и в мессенджер. Каждая продажа автоматически создаёт сделку в Битрикс24, так что все данные сразу попадают в CRM.
Петр
руководитель разработки, Alto
«Путь изменений без остановки процессов является оптимальным практически для любого «живого» проекта. В реальности у бизнеса нет возможности остановиться на полгода. Приходится работать в условиях, когда марафонец уже стартовал, и ваша задача — лечить его, не сбавляя темп забега».

Вот так удобный функционал сайта заменяет PDF-расписание на сайте термального комплекса

Система автоматически предупреждает об ограничениях посещений для детей и сразу предлагает варианты взрослого билета
3. Результаты сотрудничества
Переход к «здоровому образу жизни»:
- Конверсия в покупку выросла с 0,3% до 1,8%. На том же уровне трафика продажи выросли. Рост достигнут благодаря устранению барьеров для конверсии: вместо PDF-прайсов и картинке, где всё прописано руками, расписание заполняется в 1С и автоматически подставляется на сайт, и внедрению логики «подсказок» в корзине (например, автоматическое предложение билета для взрослого при выборе детского).
- Маркетинг перестал зависеть от разработки в операционных задачах. Акции, промокоды, персональные предложения для разных категорий — всё управляется из админки. Гипотезу можно проверить быстро, механику запустить в день принятия решения.
- Сложный продукт стал управляемым. Билеты, абонементы, сертификаты, льготные категории, пересекающиеся акции — вся логика работает предсказуемо. Маркетолог видит, где пользователи останавливаются и на каком шаге уходят.
- Платформа готова к росту. Каждый новый блок или механика встраивается в систему без пересборки того, что уже работает. Для бизнеса, который продолжает открывать новые объекты, это принципиально.

Акции и спецпредложения можно отфильтровать по дню посещения и категории посетителя, применяется персональная скидка
4. Заключение
Заказчик пришёл с гипотезой «нужен редизайн». Кнопки, баннеры, внешний вид — понятная и быстрая задача. Мы могли согласиться и закрыть проект за месяц.
Команда Alto пошла глубже: разобрала воронку, нашла точки, где пользователи реально уходят, и увидела, что дело не в интерфейсе, а в архитектуре — в PDF-расписании, в зависимости маркетинга от разработки, в связке с 1С.
Дальше стоял выбор: снести всё и построить заново, рискуя остановкой продаж, или лечить систему на ходу, пока бизнес продолжает работать. Мы выбрали второй путь, пошли итерациями, без остановки работы.
В результате конверсия выросла в 6 раз, а бизнес ни на день не прекращал продавать. Иногда самое ценное, что может сделать подрядчик — не выполнить задачу в том виде, в котором её сформулировали, а разобраться, что нужно на самом деле.



