Демоверсия

История успеха клиента

Travel Horizontal: единый процесс маркетплейса для клиентов и партнёров

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

  • Весь мир
  • B2B + B2C
  • Перестройка операций маркетплейса
  • Запуск в 2024 году

Маркетплейс

История успеха Travel Horizontal в кратком изложении

Travel Horizontal управляет глобальным маркетплейсом путешествий с двумя типами покупателей: туристами, которые бронируют для себя, и торговыми партнёрами, которые бронируют для своих клиентов. Оба канала продают одни и те же поездки, но со временем работа за каждым бронированием стала вестись по-разному.

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

Проект построен на PHPTRAVELS, том же ядре бронирования, что стоит за страницами Онлайн-турагентства и B2B-портал для туризма.

Отрасль
Маркетплейс путешествий
Регион
Весь мир
Модель
B2B + B2C
Объём
Перестройка операций маркетплейса
Запуск
2024
Карта каналов
B2CКанал клиентовТуристы, которые бронируют для себя
B2BКанал партнёровТорговые партнёры, которые бронируют для своих клиентов

Единый процесс маркетплейса

  1. Поиск
  2. Бронирование
  3. Управление
  4. Поддержка
Единая точка административного контроляКоманда ведёт оба канала из одного места
Упрощённая схема целевого устройства, а не диаграмма систем Travel Horizontal.

От диагноза к результату

Три проблемы, которые назвал маркетплейс, и что изменилось

Каждая линия начинается с проблемы, которую описала Travel Horizontal, и заканчивается результатом, о котором компания сообщила своими словами.

  1. Единообразие пути

    Проблема

    Несогласованность каналовПути клиентов и партнёров по-разному обрабатывались в операционной работе.

    Результат

    Согласованный поток каналовБронирования клиентов и партнёров теперь проходят один и тот же процесс, и команда обрабатывает их одинаково.

  2. Операционное управление

    Проблема

    Разрозненные точки контроляКоманды работали в слишком большом числе несвязанных административных точек.

    Результат

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

  3. Эффективность поддержки

    Проблема

    Процедуры с частыми эскалациямиТиповые случаи эскалировались, потому что процесс не был стандартизирован.

    Результат

    Меньше эскалацийСтандартные процедуры позволяют решить типовой случай первому, кто его увидел.

Результаты по данным Travel Horizontal. Цифры по проекту не публиковались.

Равенство каналов

Пути клиентов и партнёров на одних рельсах

Выровнять каналы не значит сделать их одинаковыми. Шаги и правила общие, а каждый канал сохраняет то, что ему действительно нужно, например партнёр, который платит из своего раздела Кошельки агентов. Переключите вид для сравнения.

Смотреть как

  • ПоискОбщее для обоих каналовТот же ассортимент и тот же процесс поиска.B2CB2BПубличные цены на сайте маркетплейса.Партнёрские цены после входа партнёра.
  • БронированиеОбщее для обоих каналовЕдиный формат записи для каждой продажи.B2CB2BТурист бронирует для себя.Партнёр бронирует от имени своего клиента.
  • ОплатаОбщее для обоих каналовЕдиный статус оплаты в каждом бронировании.B2CB2BТурист платит онлайн при оформлении.Партнёр может оплатить с баланса своего счёта.
  • УправлениеОбщее для обоих каналовТе же статусы и те же шаги изменений.B2CB2BТурист видит бронирование в своём аккаунте.Партнёр видит все свои бронирования в панели.
  • ПоддержкаОбщее для обоих каналовОдна стандартная процедура для типовых запросов.B2CB2BЗапросы приходят напрямую от туриста.Запросы приходят от партнёра с привязкой к его аккаунту.

Иллюстрация того, как PHPTRAVELS разделяет общие шаги и шаги конкретного канала, а не конфигурация Travel Horizontal.

Единая админка

От разрозненных точек к единой консоли маркетплейса

Разрозненные точки контроля были второй проблемой. Когда бронирования клиентов, запросы партнёров, платежи и поддержка находятся в разных местах, каждая ежедневная задача начинается с поиска нужного экрана.

До: отдельные места

  • Бронирования клиентов
  • Запросы партнёров
  • Проверка платежей
  • Ящик поддержки

После: одна консоль

  • Бронирования клиентов и партнёров в одном списке с меткой канала.
  • Партнёры, клиенты, поставщики и платежи управляются из одной админки.
  • Один статус для каждого бронирования, и никому не нужно проверять второй экран.

Данные клиентов и партнёров затем могут использоваться для дальнейшей работы в CRM для турбизнеса.

Админка маркетплейсаB2CB2B
  • Бронирования
  • Клиенты
  • Партнёры
  • Поставщики
  • Платежи
  • Настройки

Бронирования

№КаналПродуктСтатус
#2041B2CАвиабилетПодтверждено
#2042B2BОтельВ ожидании
#2043B2BТурПодтверждено
#2044B2CОтельИзменено

Иллюстративный вид админки с примерами бронирований, а не снимок экрана админки Travel Horizontal.

Меньше эскалаций

Типовые случаи остаются на первой ступени

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

Выберите случай

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

  1. Команда платформыИзменения в работе самого маркетплейсаРешается здесь
  2. Руководитель операцийИсключения, требующие решенияРешается здесь
  3. Первая линияЕжедневные случаи по стандартной процедуреРешается здесь
Решено при первом обращении по стандартной процедуре.Эскалировано, потому что случай действительно нестандартный.

Иллюстрация принципа, описанного Travel Horizontal, а не реальный график поддержки.

Их словами

Что говорит команда платформы

Наш межканальный процесс теперь проще в управлении и более предсказуем в ежедневной работе.

Команда Travel HorizontalКоманда платформы

Одна запись бронирования, из какого бы канала она ни пришла

Проект работает на PHP, MySQL и JavaScript с REST API, поэтому бронирования партнёров и клиентов имеют одну структуру. Подробнее о подключении систем на странице Интеграция туристических API.

GET /api/bookings/2042

{
  "channel": "b2b",
  "product": "hotel",
  "status": "pending",
  "payment": "unpaid"
}

Иллюстративный запрос и ответ, а не рабочий API Travel Horizontal.

Технологический стек

  • PHP
  • MySQL
  • JavaScript
  • REST API

Улучшите операции своего маркетплейса

Объедините процессы B2B и B2C в одной согласованной системе. PHPTRAVELS размещается на вашем сервере и поставляется с исходным кодом по коммерческой лицензии.

Начать с демоСмотреть цены

Связанные решения

Вопросы

Вопросы о проекте Travel Horizontal

Короткие ответы о маркетплейсе, перестройке и о том, что нужно для похожего проекта.

Отдел продаж

Она описывает, как Travel Horizontal, глобальный маркетплейс путешествий, продающий туристам и торговым партнёрам, перестроил операции на PHPTRAVELS, чтобы выровнять каналы, собрать административный контроль в одном месте и сократить эскалации.

Маркетплейс продаёт напрямую туристам (B2C) и через торговых партнёров, которые бронируют для своих клиентов (B2B). Перестройка перевела оба канала на один процесс, сохранив то, что специфично для каждого.

Согласованный поток каналов, более чёткий административный контроль и меньше эскалаций. Маркетплейс описал результаты своими словами; цифры не публиковались.

Проект запущен в 2024 году.

PHP, MySQL, JavaScript и REST API. PHPTRAVELS размещается на вашем сервере и включает исходный код по коммерческой лицензии.

Да. Запишитесь на демо, чтобы разобрать, как сегодня работают ваши каналы клиентов и партнёров, а затем сравните разовые тарифы на странице цен: Startup $2499, Agency $4999 и Enterprise $9999.

Узнайте больше

Ещё о платформе