Демоверсія

Історія успіху клієнта

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.

Дізнайтеся більше

Ще про платформу