Вайт лейбл чи власна система бронювання

Кошторис приходить і виглядає підйомним. Розробник, якому ви довіряєте, оцінив систему бронювання — пошук, результати, checkout, один адмінекран, три місяці — і сума не абсурдна. Два роки ви хотіли власну систему. Саме в цю мить вирішується питання вайт лейбл чи власна система бронювання, і зазвичай воно вирішується на хибних доказах: на ціні першого місяця замість форми другого року.

Кошторис чесний. Але він лише про ту частину роботи, яку видно.

Що насправді оцінює кошторис розробки

Майже будь-який кошторис, який вам дадуть, оцінює поверхні: форму пошуку, список результатів, сторінку з даними пасажирів, крок оплати, таблицю бронювань в адмінпанелі. Ця робота реальна, і вправна команда робить її добре. Це також та взаємозамінна половина, на якій дві агенції, що продають той самий напрямок, ніколи не конкурують. Ніхто ще не обрав агенцію через те, що в неї екран availability мав кращі відступи.

Друга половина — це той бік з'єднання, якого з браузера не видно. Саме туди йдуть роки.

Витрати — це кількість інтеграцій, а не інтерфейс

Попросіть у постачальника доступ — і у відповідь не отримаєте ключ API. Отримаєте тестове середовище, процес сертифікації, credentials, що видаються окремо на кожну юридичну особу, документ із правилами та контактну особу, яка відповідає у власному темпі. Далі знайомитеся з власним діалектом цього постачальника: static rates в одному місці і live availability в іншому, allotment із release period поруч із free-sale, cut-off, який ваша система мусить поважати, fare rules, що вирішують, чи зміна платна, каталог ancillaries, який не лягає на чийсь інший. Тепер помножте це на кількість постачальників, яких від вас очікують клієнти.

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

Та сама пастка сидить за кожним екраном, який кошторис таки перелічив. Пошук виглядає однією функцією, доки дві авіакомпанії не повертають той самий маршрут за різними цінами і вам не доводиться вирішувати в коді, яку побачить клієнт. Повернення коштів виглядає кнопкою, доки fare rule каже штраф, постачальник каже ваучер, а клієнт каже картка. Markup виглядає числом на сторінці налаштувань до того дня, коли вам потрібне одне правило для корпоративних клієнтів, інше для sub-agent у Львові і третє для роздрібу з вулиці на тому самому тарифі.

Саме цю арифметику кошторис лишає поза дужками, і проти інтерфейсу це не похибка округлення — це і є продукт. На платформі вайт лейбл ця робота вже зроблена і вже має людей: контент постачальників доходить до вітрини через supplier groups, а не через договори, які ви підписуєте по одному, і сайт вмикає рейси, готелі, тури або attractions залежно від того, що він справді продає.

Порівняння, яке переживає зустріч із другим роком

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

Два з цих рядків грають за власну розробку. Це не втішні призи. Якщо те, що ви продаєте, достатньо нетипове, вони переважують усе вище.

Скільки коштує помилитися

Режим відмови власноруч зробленої системи — це не проєкт, що розвалився. Такі видно, вони болять і їх переживають. Дорога версія — це система, яка працює, а потім поволі перестає.

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

Ніщо з цього не приходить рахунком, і саме тому воно ніколи не з'являється в тому порівнянні, яке люди справді роблять. Воно приходить увагою. Власник, що витрачає вівторок на зламаний PNR, того вівторка не продає, а агенції, які затихають після власної розробки, затихають рідко через те, що програма зламалася — вони затихають тому, що людина, яка приводила клієнтів, тепер підтримує систему.

Коли будувати справді правильно

Іноді правильно, і випадки достатньо конкретні, щоб приміряти їх на себе.

• Програма і є вашою відмінністю. Якщо ви продаєте технологію іншим туристичним бізнесам, а не подорожі, ви не можете віддати назовні те, за що берете гроші.
• У вас уже є інженери, і ви заклали бюджет на другого. Не на того, хто будує — на того, хто підхопить це після відходу першого. Розробка без плану наступності — це оренда з додатковими кроками.
• У вас процес, якого ніхто не моделює. Оператор паломництв, що тримає власні місця й зшиває групові PNR з етапами віз, робить те, у що універсальна система ніколи повністю не вкладеться.

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

А якщо ваша модель тримається на sub-agent, порахуйте і її як слід. Тут credit limits і виставлення settlement — поняття першого класу, а не таблиця, яку хтось звіряє в неділю; у власній розробці це другий проєкт, якого ніхто не вписав у перший кошторис.

Одне питання, поставлене обом

Перш ніж щось підписати, поставте однакове питання розробнику й платформі: у березні постачальник змінює сертифікацію — хто робить роботу, за чиїм дедлайном і як я про це дізнаюся? Відповіді не будуть схожими, і різниця між ними — це те, між чим ви насправді обираєте.

Порівнювати діючу вітрину з кошторисом — чесніша перевірка, ніж порівнювати два документи. Тож якщо хочете побачити, що саме розгортається, перш ніж на щось погоджуватися, почніть сайт у майстрі — він не питає картку, а субдомен, який ви отримуєте, лишається назавжди, навіть після підключення власного домену.