Как мы сделали первый в России маркетплейс туров для активных путешествий

Заказчик

Егор Похващев — CEO, Pro Adventure, победитель конкурса тревел стратапов конференции TRAVELHUB 2018

Задача

Маркетплейс для взаимодействия поставщиков и покупателей с ЛК и автоматизацией финансовых расчетов

В 2016 году мы начали работу над интересным проектом по разработке сайта для турагентства, который по итогу стал единым маркетплейсом туров. Забегая вперёд — такое решение ещё не было представлено на рынке туристических услуг. Заказчик — владелец небольшого турагентства с конкретным узким направлением, у которого к моменту начала проекта уже был сайт.

С чем пришёл заказчик

Я хочу сделать Booking для экстремального туризма, чтобы поставщики могли регистрироваться в ЛК на нашем сервисе и публиковать свои туры, а покупатели могли их оплачивать на нашем сервисе. Мы будем получать за это комиссию.

Он хотел расширить проект и сделать платформу для удобного взаимодействия между поставщиками туров и покупателями. Маркетплейс, который предоставит поставщикам личный кабинет для самостоятельного добавления туров, ведения учёта клиентов и полную автоматизацию финансовых расчётов. А клиентам — личный кабинет для выбора и оплаты туров онлайн, удобный каталог и сравнение туров между собой, а также CRM-систему для частных туроператоров. Позиционирование ставилось так: крупнейший агрегатор туров активного отдыха как минимум для российской аудитории.

Как всё работало раньше

У агентства был сайт на платформе WIX, но он уже не справлялся с задачами: количество туров на сайте стало таким, что сайт открывался очень медленно, недостаточные возможности админки платформы сдерживали развитие.

Мы разрабатывали индивидуальное решение, потому что на тот момент в России не было ни одного аналогичного сервиса, который занимался бы только сбором информации и продажей туров для активного отдыха в одном месте. Нас не устраивали технические ограничения готовых решений, и заказчик имел много требований к итоговому результату, удовлетворить которые без разработки с нуля мы не видели возможности.

Сложности в начале проекта

Я понимал, что всю жизнь надо потратить, и всё равно не всё сделать. Начало работы над проектом усложнялось не слишком глубокими знаниями нашего заказчика о процессе разработки.

Мы предложили начать с каталога туров, ЛК поставщиков оставить в админке Django, так как она удобная, а от основной массы софта (автоматизация процессов, личные кабинеты) отказаться.

Основная проблема, с которой тут же столкнулись, — необходимость стандартизации информации о туре. Заказчиком была проделана большая работа по аналитике туров, а нами — по разработке модели данных и макетов для туров. Это была отличная работа команды с хорошим результатом в итоге. Оглядываясь назад, трудно сказать, было ли такое решение правильным — не удалось доказать, что пользователям важно сравнивать активный отдых. По словам заказчика:

Маркетплейс пылесосов и сравнение их цен нужны людям, а активного отдыха — нет.

Основные задачи проекта

Генерация входящих заявок в админке за счёт подробнейшей проработки UX страницы и побуждения пользователя заполнить форму заявки на участие, привязанную к каждому туру.

1. Удобный поиск тура за счёт разработки каталога, приоритезации поисковых фильтров и UX-проработки процесса поиска.
2. Имиджевая задача (задача доверия) — выполнение роли представительства компании: возможность задать вопрос реальному человеку за счёт размещения на сайте телефона и ссылки на чат.
3. Возможность добавления новых туров за счёт подробной формы в админ-панели, которая позволит подготовить страницу нового тура, заполняя минимум текста.

Процесс работы

В процессе работы полностью сменилась бизнес-модель проекта заказчика. До работы с нами у него был сайт турагентства на определённое направление с несколькими поставщиками.

После того, как наш проект вышел, получился маркетплейс на разные направления с большим количеством поставщиков.

У каждого поставщика — разные комиссии, тарифы и ценообразование. Нагрузка, которая ложится на производственный процесс, — огромна. Из-за этого случилась проблема, которую мы на тот момент не смогли решить, так как мощности бизнеса заказчика и операционной мощности не хватало, чтобы покрывать расходы на разработку CRM. Сайт автоматизировал только сбор заявок, а производственный процесс — документооборот (в тревел-отрасли огромный), финансовый учёт, расчёты с агентствами не автоматизировались.

Технологический стек и рабочее окружение

Для кода проекта был создан репозиторий на GitHub. Тестовая версия была развёрнута на сервере DigitalOcean, настроено Continuous Integration и Continuous Deployment.

При каждом изменении в проекте автоматически происходила сборка, автоматические тесты и статический анализ кода. Была настроена отправка статусов сборки проекта в GitHub так, чтобы изменения кода можно было принять только в случае успешной сборки.

Production сервер был настроен при помощи автоматических сценариев, написанных на fabric. Автоматическое развёртывание новых версий было настроено при помощи TeamCity. QA-специалист писал функциональные тесты для автоматической проверки работы проекта в реальных сценариях использования. Для написания функциональных тестов использовался Selenium и Python 3.

Дизайн

Для сайта типа «маркетплейс» важно, чтобы пользователь мог узнать всю нужную информацию, просто и понятно забронировать тур и оплатить его. Мы создали CJM и на его основе проработали макеты страниц сайта.

Всего в сервисе не больше 4 типов страниц, но в Zeplin у нас около ста экранов по проекту. Это связано с тем, что на каждом экране важно проработать детали: учесть все состояния «нажато/наведено/отжато» для мобайла, десктопа, и, желательно, планшета.

Дизайнер потратил 3 месяца на эту работу, если не считать дальнейшие доработки по ходу изменения сервиса. Результатом стало то, что наши UX-решения впоследствии стали копировать появляющиеся агрегаторы туров.

Ключевые разработки в проекте

Мы создали и реализовали интерактивную карту тура, которая показывает маршрут по дням с возможностью быстро ознакомиться с активностями каждого дня.

Самым интересным решением разработки стала связь карты с днями маршрута. Но это было и самым сложным — мы сменили кучу технологий: интегрировались сами, затем перешли на leoflet.js.

Результат работы

Отличным вознаграждением за работу стало то, что отрасль стала повально копировать наши решения.

• https://sportnrelax.com/tours/velotur-po-osennej-toskane/
• http://www.atv51.ru/
• https://adventure-guide.ru/tours/?type%5B%5D=6& и др.

Реализован гибкий поиск туров по множеству параметров (место, время проведения, тип активности, сложность и т.д.).

Для бронирования туров разработана форма, в которой можно выбрать дату начала тура, заполнить контактные данные и т.д.

Административная панель сервиса позволяет

• Работать с заявками от клиентов.
• Создавать и редактировать туры с возможностью редактировать маршрут тура непосредственно на карте.
• Создавать подборки туров для быстрого запуска посадочных страниц.
• Работать со статическими страницами.

Мы сделали длинную и очень подробную форму заполнения информации о туре, руководствуясь двумя вещами:

1. Чтобы покупатель мог узнать исчерпывающую информацию о туре, принять решение о покупке сразу.
2. Чтобы поставщику было просто заполнить конкретные поля, мы их разделили на понятные и удобные части.

Команда проекта и сроки реализации

Над проектом работали 4 разработчика, QA специалист и менеджер проекта. Первая версия маркетплейса был сделана за 9 месяцев, затем мы доделывали требования по SEO, экспериментировали со страницей тура, пытались стандартизировать процесс заявки на тур и многое другое ещё год.

Итоги сотрудничества с заказчиком

Сотрудничество не было простым — в результате работы над проектом бизнес-модель заказчика была изменена.

Мы много исправляли карту, дорабатывали детали. Тем не менее, у нас получилось сделать огромный проект, который является актуальным продуктом сейчас.

Горжусь, что в футере стоит логотип моей компании.

Перейти на сайт