Платформа генерации сайтов отелей на шаблонах
(01)
Вкратце
Запустил внутреннюю платформу генерации сайтов отелей: система позволила собирать сайт из шаблона и единой базы данных за ~30 минут вместо ручной работы через IT, которая раньше занимала часы или дни.
(02)
По результатам
- сократил время запуска сайта: с часов/дней до ~30 минут
- сократил время редактирования: с часов до нескольких минут
- появилась единая база контента по отелям
- появилась возможность быстро запускать и тестировать новые шаблоны
- система масштабировалась примерно до 2000 сайтов
- решение используется до сих пор
(03)
Контекст
Это один из первых проектов, над которым я работал в компании (туристическое агентство с собственной сетью сайтов отелей).
На старте:
Процесс выглядел так:
Это занимало часы или дни.
Пока сайтов было немного, такой процесс можно было поддерживать вручную. Но при росте количества отелей и регионов ручная модель стала ограничением: каждый новый сайт или изменение требовали участия IT и замедляли запуск рекламных кампаний.
На старте:
- у компании был пул сайтов отелей на старых шаблонах
- шаблоны были устаревшими визуально и по UX
- каждый сайт создавался вручную через IT
Процесс выглядел так:
- менеджер создаёт задачу
- разработчики создают сайт
- верстальщик вручную наполняет контентом
Это занимало часы или дни.
Пока сайтов было немного, такой процесс можно было поддерживать вручную. Но при росте количества отелей и регионов ручная модель стала ограничением: каждый новый сайт или изменение требовали участия IT и замедляли запуск рекламных кампаний.
(04)
Моя роль
Я отвечал за исследование проблемы, концепцию платформы, проектирование логики шаблонов и админки, согласование решения с IT и запуск первых итераций.
В рамках проекта я:
В рамках проекта я:
- изучил текущий процесс создания и редактирования сайтов
- собрал проблемы менеджеров и IT-команды
- сформировал концепцию “шаблон + данные = готовый сайт”
- участвовал в проектировании структуры данных и админки
- запускал и сравнивал шаблоны через A/B-тесты
- сопровождал развитие системы и масштабирование на новые сайты
(05)
Проблемы
С точки зрения бизнеса:
С точки зрения продукта:
- низкая скорость запуска новых сайтов
- высокая нагрузка на IT и верстальщиков
- зависимость маркетинга и менеджеров от разработки
- невозможность быстро масштабировать сайты под новые отели и регионы
- сложность быстрого запуска рекламных гипотез
С точки зрения продукта:
- устаревшие и неудобные шаблоны
- нестабильная конверсия на разных сайтах
- разрозненный контент без единого стандарта
- сложность тестирования изменений
- отсутствие гибкой системы для обновления структуры сайта
(06)
Цели
Главная цель — перейти от ручного производства сайтов к масштабируемой системе, где новый сайт можно собрать из шаблона и подготовленных данных без отдельной разработки под каждый запуск.
- ускорить запуск сайтов
- снизить зависимость от разработчиков
- повысить удобство сайтов для пользователей
- улучшить конверсионность шаблонов
- создать единую систему хранения данных
- внедрить возможность тестирования и сравнения шаблонов
Discovery: как выявил проблемы процесса
Интервью
- менеджеры жаловались на долгий запуск сайтов
- изменения приходилось проводить через IT
- редактирование контента занимало слишком много времени
Анализ процесса
- создание сайта занимало часы или дни
- значительная часть работы повторялась вручную
- один и тот же тип сайта каждый раз собирался почти заново
Косвенные сигналы
- регулярные задачи в IT на создание и редактирование сайтов
- разные форматы данных по отелям
- сложность быстрого тестирования новых шаблонов на рекламном трафике
Ключевой инсайт
Проблема была не только в устаревшем дизайне сайтов. Основное ограничение находилось в самом процессе: каждый сайт создавался почти вручную, данные хранились разрозненно, а любое изменение требовало участия IT.
Поэтому решение должно было быть не просто новым шаблоном, а системой, которая разделяет структуру сайта и контент: шаблон отвечает за отображение, а данные подтягиваются из единой базы.
Поэтому решение должно было быть не просто новым шаблоном, а системой, которая разделяет структуру сайта и контент: шаблон отвечает за отображение, а данные подтягиваются из единой базы.
Проект развивался итерационно
Решения
(01)
Обновление шаблонов
На первом этапе я обновил подход к шаблонам сайтов: подготовил несколько вариантов структуры страниц, чтобы проверить, какие решения лучше работают для пользователей и рекламного трафика.
Это дало основу для дальнейших итераций: мы могли не просто обновить визуальный слой, а начать сравнивать разные варианты сайтов по поведению пользователей.
Это дало основу для дальнейших итераций: мы могли не просто обновить визуальный слой, а начать сравнивать разные варианты сайтов по поведению пользователей.
(02)
Внедрение A/B тестов
Новые шаблоны тестировали на рекламном трафике и сравнивали поведение пользователей: переходы, вовлеченность и конверсионные действия.
По результатам тестов более успешные варианты подключали к системе и масштабировали на новые сайты.
По результатам тестов более успешные варианты подключали к системе и масштабировали на новые сайты.
(03)
Переход к системе шаблонов
После первых итераций стало понятно, что основной bottleneck — не только дизайн, а сам процесс создания сайтов.
Если каждый сайт продолжать собирать вручную, команда будет упираться в одни и те же ограничения: задачи в IT, ручное наполнение, разные форматы данных и долгие правки.
Я сформулировал концепцию:
шаблон + данные = готовый сайт
Шаблон отвечает за структуру и отображение, а данные по отелю подтягиваются из единой базы и частично заполняются автоматически.
Если каждый сайт продолжать собирать вручную, команда будет упираться в одни и те же ограничения: задачи в IT, ручное наполнение, разные форматы данных и долгие правки.
Я сформулировал концепцию:
шаблон + данные = готовый сайт
Шаблон отвечает за структуру и отображение, а данные по отелю подтягиваются из единой базы и частично заполняются автоматически.
(04)
Из чего состояло решение
1. библиотека шаблонов — разные варианты сайтов под отели, регионы и рекламные задачи.
2. единая база данных — стандартизированный контент по отелям.
3. админка — интерфейс для выбора шаблона, заполнения и редактирования данных.
4. API-интеграции — часть информации подтягивалась автоматически.
5. A/B-тесты — возможность сравнивать шаблоны на рекламном трафике.
6. масштабирование — новые сайты можно было создавать быстрее без отдельной разработки с нуля.
2. единая база данных — стандартизированный контент по отелям.
3. админка — интерфейс для выбора шаблона, заполнения и редактирования данных.
4. API-интеграции — часть информации подтягивалась автоматически.
5. A/B-тесты — возможность сравнивать шаблоны на рекламном трафике.
6. масштабирование — новые сайты можно было создавать быстрее без отдельной разработки с нуля.
(05)
Разработка админки
Мы сделали админку, через которую можно было выбрать шаблон, заполнить данные по отелю и быстро собрать сайт без отдельной разработки под каждый запуск.
В системе было предусмотрено:
В системе было предусмотрено:
- выбор шаблона
- заполнение и редактирование данных
- автоподтягивание части данных по API
- ручное заполнение нестандартных блоков
- гибкие блоки для шапки, текстов, логотипов и контента
- возможность быстро обновлять информацию на уже созданных сайтах
(06)
Единая база данных
Для масштабирования нужно было отделить контент от шаблона. Мы стандартизировали данные по отелям и привели их к единому формату.
Это позволило использовать одни и те же данные в разных шаблонах, быстрее обновлять информацию и уменьшить количество ручных ошибок при создании сайтов.
Это позволило использовать одни и те же данные в разных шаблонах, быстрее обновлять информацию и уменьшить количество ручных ошибок при создании сайтов.
(07)
Масштабирование
После запуска системы новые шаблоны можно было добавлять в библиотеку и подключать к сайтам без пересборки всего процесса.
Команда могла быстрее запускать сайты под новые отели и регионы, тестировать разные варианты и переключать шаблон “в один клик”, если нужно было проверить новую гипотезу или обновить структуру сайта.
Команда могла быстрее запускать сайты под новые отели и регионы, тестировать разные варианты и переключать шаблон “в один клик”, если нужно было проверить новую гипотезу или обновить структуру сайта.
Внедрение и результаты
Система стала рабочей инфраструктурой для запуска сайтов отелей и используется до сих пор. Со временем в ней накопилось около 2000 сайтов.
Время запуска сайта:
Время запуска сайта:
- было: часы / дни
- стало: ~30 минут
Редактирование:
Что изменилось для команды:
- было: часы
- стало: минуты
Что изменилось для команды:
- менеджеры и маркетинг стали меньше зависеть от IT
- сайты стало проще запускать под разные отели и регионы
- появилась единая база контента
- шаблоны можно было тестировать и масштабировать
- редактирование стало быстрее и безопаснее
“
Этот проект показал, что иногда продуктовая задача начинается как “обновить шаблоны”, но в процессе превращается в задачу про систему, данные и масштабирование.
Если бы мы просто сделали несколько новых дизайнов, скорость запуска сайтов почти не изменилась бы. Поэтому ключевым решением стал переход к платформенному подходу: шаблоны, единая база данных, админка и возможность быстро тестировать разные варианты.
Для меня этот проект стал важным опытом работы не только с интерфейсом, но и с продуктовой логикой, процессом запуска, ограничениями IT и масштабированием решения внутри бизнеса.
Если бы мы просто сделали несколько новых дизайнов, скорость запуска сайтов почти не изменилась бы. Поэтому ключевым решением стал переход к платформенному подходу: шаблоны, единая база данных, админка и возможность быстро тестировать разные варианты.
Для меня этот проект стал важным опытом работы не только с интерфейсом, но и с продуктовой логикой, процессом запуска, ограничениями IT и масштабированием решения внутри бизнеса.
