Разработка маркетплейса туров для активного отдыха
Заказчик — владелец небольшого турагентства с конкретным узким направлением, у которого к моменту начала проекта уже был сайт.
С чем пришел заказчик
Я хочу сделать Booking для экстремального туризма, чтобы поставщики могли регистрироваться в ЛК на нашем сервисе и публиковать свои туры, а покупатели могли их оплачивать на нашем сервисе. Мы будем получать за это комиссию.
Он хотел расширить проект и сделать платформу для удобного взаимодействия между поставщиками туров и покупателями. Маркетплейс, который предоставит поставщикам личный кабинет для самостоятельного добавления туров, ведения учёта клиентов и полную автоматизацию финансовых расчётов. А клиентам — личный кабинет для выбора и оплаты туров онлайн, удобный каталог и сравнение туров между собой, а также CRM-систему для частных туроператоров. Позиционирование ставилось так: крупнейший агрегатор туров активного отдыха как минимум для российской аудитории.
Как все работало раньше
У агентства был сайт на платформе WIX, но он уже не справлялся с задачами: количество туров на сайте стало таким, что сайт открывался очень медленно, недостаточные возможности админки платформы сдерживали развитие.
Мы разрабатывали индивидуальное решение, потому что на тот момент в России не было ни одного аналогичного сервиса, который занимался бы только сбором информации и продажей туров для активного отдыха в одном месте. Нас не устраивали технические ограничения готовых решений, и заказчик имел много требований к итоговому результату, удовлетворить которые без разработки с нуля мы не видели возможности.
Сложности в начале проекта
Я понимал, что всю жизнь надо потратить, и все равно не всё сделать. Начало работы над проектом усложнялось не слишком глубокими знаниями нашего заказчика о процессе разработки (иначе бы он к нам и не обращался).
Мы предложили начать с каталога туров, ЛК поставщиков оставить в админке Django, так как она удобная, а от основной массы софта (автоматизация процессов, личные кабинеты) отказаться.
Основная проблема, с которой тут же столкнулись, — необходимость стандартизации информации о туре. Заказчиком была проделана большая работа по аналитике туров, а нами — по разработке модели данных и макетов для туров. Это была отличная работа команды с хорошим результатом в итоге. Оглядываясь назад, трудно сказать, было ли такое решение правильным — не удалось доказать, что пользователям важно сравнивать активный отдых. По словам заказчика:
Маркетплейс пылесосов и сравнение их цен нужны людям, а активного отдыха — нет.
Основные задачи проекта
Генерация входящих заявок в админке за счёт подробнейшей проработки UX страницы и побуждения пользователя заполнить форму заявки на участие, привязанную к каждому туру.
- Удобный поиск тура за счёт разработки каталога, приоритизации поисковых фильтров и UX-проработки процесса поиска.
- Имиджевая задача (задача доверия) — выполнение роли представительства компании: возможность задать вопрос реальному человеку за счёт размещения на сайте телефона и ссылки на чат.
- Возможность добавления новых туров за счёт подробной формы в админ-панели, которая позволит подготовить страницу нового тура, заполняя минимум текста.
Процесс работы
В процессе работы полностью сменилась бизнес-модель проекта заказчика. До работы с нами у него был сайт турагентства на определённое направление с несколькими поставщиками.
После того, как наш проект вышел, получился маркетплейс на разные направления с большим количеством поставщиков.
У каждого поставщика — разные комиссии, тарифы и ценообразование. Нагрузка, которая ложится на производственный процесс, — огромна. Из-за этого случилась проблема, которую мы на тот момент не смогли решить, так как мощности бизнеса заказчика и операционной мощности не хватало, чтобы покрывать расходы на разработку CRM. Сайт автоматизировал только сбор заявок, а производственный процесс — документооборот (в тревел-отрасли огромный), финучёт, расчёты с агентствами не автоматизировались.
Технологический стек и рабочее окружение
Для кода проекта был создан репозиторий на GitHub. Тестовая версия была развёрнута на сервере DigitalOcean, настроено Continuous Integration и Continuous Deployment.
При каждом изменении в проекте автоматически происходила сборка, автоматические тесты и статический анализ кода. Была настроена отправка статусов сборки проекта в GitHub так, чтобы изменения кода можно было принять только в случае успешной сборки.
Production сервер был настроен при помощи автоматических сценариев, написанных на fabric. Автоматическое развёртывание новых версий было настроено при помощи TeamCity. QA специалист писал функциональные тесты для автоматической проверки работы проекта в реальных сценариях использования.Для написания функциональных тестов использовался Selenium и Python 3.
Дизайн
Для сайта типа «маркетплейс» важно, чтобы пользователь мог узнать всю нужную информацию, просто и понятно забронировать тур и оплатить его. Мы создали CJM и на его основе проработали макеты страниц сайта.
Всего в сервисе не больше 4 типов страниц, но в Zeplin у нас около ста экранов по проекту. Это связано с тем, что на каждом экране важно проработать детали: учесть все состояния «нажато/наведено/отжато» для мобайла, десктопа, и, желательно, планшета.
Дизайнер потратил 3 месяца на эту работу, если не считать дальнейшие доработки по ходу изменения сервиса. Результатом стало то, что наши UX-решения впоследствии стали копировать появляющиеся агрегаторы туров.
Ключевые разработки в проекте
Мы создали и реализовали интерактивную карту тура, которая показывает маршрут по дням с возможностью быстро ознакомиться с активностями каждого дня.
Самым интересным решением разработки стала связь карты с днями маршрута. Но это было и самым сложным — мы сменили кучу технологий: интегрировались сами, затем перешли на leoflet.js.
Результат работы
Отличным вознаграждением за работу стало то, что отрасль стала повально копировать наши решения:
Реализован гибкий поиск туров по множеству параметров (место, время проведения, тип активности, сложность и т.д.).
Для бронирования туров разработана форма, в которой можно выбрать дату начала тура, заполнить контактные данные и так далее.
Административная панель сервиса позволяет
- Работать с заявками от клиентов.
- Создавать и редактировать туры с возможностью редактировать маршрут тура непосредственно на карте.
- Создавать подборки туров для быстрого запуска посадочных страниц.
- Работать со статическими страницами.
Мы сделали длинную и очень подробную форму заполнения информации о туре, руководствуясь двумя вещами:
- чтобы покупатель мог узнать исчерпывающую информацию о туре, принять решение о покупке сразу;
- чтобы поставщику было просто заполнить конкретные поля, мы их разделили на понятные и удобные части.
Команда проекта и сроки реализации
Над проектом работали 4 разработчика, QA специалист и менеджер проекта. Первая версия маркетплейса был сделана за 9 месяцев, затем мы доделывали требования по SEO, экспериментировали со страницей тура, пытались стандартизировать процесс заявки на тур и многое другое ещё год.
Итоги сотрудничества с заказчиком
Сотрудничество не было простым — в результате работы над проектом бизнес-модель заказчика была изменена.
Мы много исправляли карту, дорабатывали детали. Тем не менее, у нас получилось сделать огромный проект, который является актуальным продуктом сейчас.
Узнайте, сколько стоила разработка маркетплейса туров активного отдыха в WB—Tech.