White label или своя система бронирования: что считать

Смета приходит, и сумма выглядит подъёмной. Разработчик, которому вы доверяете, оценил систему бронирования — поиск, выдача, оплата, админка, три месяца — и цифра не выглядит безумной. Своя система нужна вам уже два года. Именно в этот момент и решается выбор: white label или своя система бронирования. И решается он почти всегда по неверному признаку: по цене первого месяца, а не по форме второго года.

Смета честная. Просто она оценивает только ту часть работы, которую видно.

Что на самом деле оценивает смета

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

Вторая половина — это сторона, которую из браузера не видно: сторона поставщиков. Там и уходят годы.

Цена — это количество интеграций, а не интерфейс

Попросите у поставщика доступ — и API key ответным письмом вы не получите. Вы получите тестовую среду, процедуру сертификации, учётные данные, выдаваемые на юридическое лицо, документ с правилами и контакт, который отвечает по своему графику. Дальше начинается диалект конкретного поставщика: статические тарифы в одном месте и живое наличие в другом, квота с периодом снятия рядом с free-sale, cut-off, который ваш движок обязан соблюдать, правила тарифа, решающие, платный ли обмен, каталог допуслуг, не совпадающий ни с чьим. Теперь умножьте это на число поставщиков, которых от вас ждут клиенты.

Одна интеграция — это проект. Шесть — это отдел, и работа в нём не заканчивается никогда, потому что никто из этих шести не обещал перестать меняться.

Именно эту арифметику смета оставляет за скобками, и на фоне интерфейса она не погрешность, а сам продукт. На white label платформе работа уже сделана и за ней уже закреплены люди: контент поставщиков попадает в витрину через группы поставщиков, а не через договоры, которые вы подписываете по одному, и сайт включает авиабилеты, отели, турпакеты или экскурсии — в зависимости от того, что он действительно продаёт.

Та же ловушка сидит за каждым экраном, который смета как раз перечисляет. Поиск кажется одной функцией, пока две авиакомпании не отдадут один и тот же маршрут по разным ценам — и решать в коде, какую увидит клиент, придётся вам. Возврат кажется кнопкой, пока правило тарифа говорит «штраф», поставщик — «ваучер», а клиент — «на карту». Наценка кажется числом в настройках, пока вам не понадобится одно правило для корпоративных клиентов, другое для субагента в Алматы и третье для розницы — на одном и том же билете.

Сравнение, которое выдерживает второй год

Читайте таблицу как оператор, а не как покупатель. Вопрос в каждой строке один: на ком ответственность?

Две строки здесь — за собственную разработку. Это не утешительный приз: если то, что вы продаёте, достаточно нетипично, они перевешивают всё, что выше.

Во что обходится ошибка

Своя система ломается не так, что проект рушится. Рухнувший проект виден, болезнен и переживаем. Дорогой вариант — система, которая работает, а потом медленно перестаёт.

Разработчик, который её написал, уходит, и следующий оценивает любую мелкую правку как риск, потому что этот код не читал никто из живых. Поставщик отключает endpoint по своему графику, и брони начинают срываться так, что клиенты замечают это раньше вашего мониторинга. Правило тарифа, верно закодированное в первый год, больше не пересматривают, и ADM выставляют на ваш номер IATA, а не подрядчику. Платёжные ключи истекают. Сертификаты истекают. Фреймворк, отставший на две версии, превращается в разговор о безопасности, на который вы не закладывали неделю.

Ничего из этого не приходит счётом — потому и не попадает в то сравнение, которое люди делают на самом деле. Оно приходит вниманием. Владелец, который проводит вторник над сломанным PNR, во вторник не продаёт; и агентства, затихающие после собственной разработки, затихают редко из-за отказа софта — они затихают потому, что человек, приносивший бизнес, стал человеком, который этот софт содержит.

Когда разработка действительно оправдана

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

• Софт и есть ваше отличие. Если вы продаёте технологию другим travel-компаниям, а не поездки, отдать на сторону то, за что берёте деньги, нельзя.
• У вас уже есть инженеры, и заложен бюджет на второго. Не на того, кто напишет, — на того, кто примет систему после ухода первого. Разработка без плана преемственности — это аренда с лишними шагами.
• У вас процесс, который никто не моделирует. Оператор паломничества со своими койками, сшивающий групповые PNR с этапами визы, в универсальный движок до конца не поместится.

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

А если ваша модель держится на субагентах, посчитайте и это как следует. Кредитные лимиты и взаиморасчётные счета здесь — полноценные сущности, а не таблица, которую кто-то сводит в воскресенье; в собственной разработке это второй проект, не попавший в первую смету.

Один вопрос — обеим сторонам

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

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