White label, nebo vlastní rezervační systém?

Nabídka přišla e-mailem a na první pohled se dá přežít. Programátor, kterému věříte, nacenil rezervační systém — vyhledávání, výsledky, košík, jedna obrazovka v administraci, tři měsíce — a to číslo není absurdní. Vlastní systém chcete už dva roky. Přesně v tuhle chvíli se rozhoduje otázka white label, nebo vlastní rezervační systém, a rozhoduje se obvykle podle špatného důkazu: podle ceny prvního měsíce místo podle toho, jak bude vypadat druhý rok.

Ta nabídka není nečestná. Je jen za tu část práce, kterou vidíte.

Co rozpočet na vývoj skutečně nacenil

Téměř každý rozpočet, který dostanete do ruky, oceňuje povrchy: vyhledávací formulář, seznam výsledků, stránku s údaji cestujících, platební krok, tabulku rezervací v administraci. Ta práce je reálná a schopný tým ji odvede dobře. Je to ovšem ta komoditní polovina — polovina, na které dvě agentury prodávající stejnou linku nikdy nesoutěží. Nikdo si nikdy nevybral agenturu proto, že měla lépe odsazenou obrazovku dostupnosti.

Druhá polovina leží na té straně spojení, kterou z prohlížeče nevidíte. Tam odcházejí roky.

Cena je v počtu integrací, ne v rozhraní

Když požádáte dodavatele o přístup, nedostanete zpětnou poštou API klíč. Dostanete testovací prostředí, certifikační proces, přihlašovací údaje vydané na konkrétní právní subjekt, dokument s pravidly a kontaktní osobu, která odpovídá podle svého vlastního kalendáře. Pak narazíte na dialekt daného dodavatele: statické ceny na jednom místě a živá dostupnost na druhém, allotment s release period hned vedle free-sale, cut-off, který váš systém musí respektovat, fare rules rozhodující o tom, zda je změna zpoplatněná, a katalog ancillaries, který se nemapuje na ničí jiný. Teď to vynásobte počtem dodavatelů, které od vás klienti očekávají.

Jedna integrace je projekt. Šest je oddělení — a nikdy neskončí, protože ani jeden z těch šesti dodavatelů se nezavázal přestat se měnit.

Stejná past se skrývá i za obrazovkami, které rozpočet vyjmenovává. Vyhledávání vypadá jako jedna funkce, dokud nevezete dvě letecké společnosti, které vrátí totožné spojení za různou cenu, a vy musíte v kódu rozhodnout, kterou z nich klient uvidí. Refundace vypadá jako tlačítko, dokud fare rule říká penále, dodavatel říká voucher a klient říká kartu. Přirážky vypadají jako číslo v nastavení do dne, kdy chcete jedno pravidlo pro korporátní klienty, druhé pro subagenta v Ostravě a třetí pro pult v obchodním centru — na téže ceně.

Tohle je ta aritmetika, kterou nabídka na vývoj vynechává, a není to zaokrouhlovací chyba proti UI. Je to samotný produkt. Na white label platformě je ta práce hotová a obsazená lidmi: obsah dodavatelů se dostane do obchodu přes supplier groups, ne přes smlouvy, které podepisujete jednu po druhé, a web zapíná lety, hotely, zájezdy nebo atrakce podle toho, co skutečně prodává.

Srovnání, které vydrží druhý rok

Čtěte tabulku jako provozní člověk, ne jako nákupčí. V každém řádku je stejná otázka: kdo to má na triku?

Dva z těch řádků mluví pro vlastní vývoj. Nejsou to útěchy. Pokud je to, co prodáváte, dost neobvyklé, převáží všechno nad nimi.

Co vás stojí špatné rozhodnutí

Selhání vlastního systému nevypadá jako projekt, který se sesype. Takové jsou vidět, bolí a dají se přežít. Drahá varianta je systém, který funguje — a pak pomalu přestává.

Programátor, který ho napsal, odejde jinam, a ten další nacení každou malou změnu jako riziko, protože ten kód nikdo živý nepřečetl. Dodavatel vyřadí endpoint podle svého kalendáře a rezervace začnou padat způsobem, který si klienti všimnou dřív než váš monitoring. Fare rule správně zakódovaná v prvním roce se už nikdy nerevidovala, a ADM, které přijde, jde na vaše IATA číslo, ne na dodavatelovo. Platebním údajům vyprší platnost. Certifikátům vyprší platnost. Framework dvě verze pozadu se změní v bezpečnostní rozhovor, na který jste si týden nevyhradili.

Nic z toho nepřijde jako faktura, a proto se to v žádném srovnání neobjeví. Přijde to jako pozornost. Majitel, který stráví celé úterý nad rozbitým PNR, v úterý neprodává — a agentury, které po vlastním vývoji utichnou, málokdy utichnou proto, že selhal software. Utichnou proto, že člověk, který dřív přiváděl obchod, ho teď udržuje.

Kdy je vlastní vývoj opravdu správná volba

Někdy je, a ty případy jsou dost konkrétní, abyste si je na sebe zkusili přiložit.

• Software je ta odlišnost. Když prodáváte technologii jiným cestovním firmám místo cestování, nemůžete outsourcovat právě to, za co si účtujete.
• Už máte vývojáře a máte rozpočet na druhého. Ne na toho, kdo to postaví — na toho, kdo to převezme, až první odejde. Vývoj bez plánu následnictví je nájem s dvěma mezikroky.
• Provozujete workflow, které nikdo nemodeluje. Operátor poutí, který drží vlastní postele a sešívá skupinová PNR s milníky víz, nedělá nic, do čeho by obecný systém někdy úplně sedl.

Existuje i cesta, která není ani jedno: kupte obchod a postavte jen tu část, která je opravdu vaše. Platforma na to nabízí API pro lety a hotely, i když přístup začíná rozhovorem, ne samoobslužným klíčem. Nacenit hybrid má cenu dřív, než se zavážete k celému vývoji, protože to, co jste opravdu chtěli mít pod kontrolou, je většinou jedno workflow, ne celý systém.

A pokud váš model stojí na subagentech, naceňte i to pořádně. Kreditní limity a settlement faktury tu jsou prvotřídní pojmy, ne tabulka, kterou někdo v neděli odsouhlasuje; ve vlastním vývoji jsou to druhý projekt, který v prvním rozpočtu nikdo neměl.

Jedna otázka pro obě strany

Než něco podepíšete, položte programátorovi i platformě tutéž otázku: dodavatel v březnu změní certifikaci — kdo tu práci odvede, v čím termínu, a jak se to dozvím? Odpovědi nebudou podobné, a rozdíl mezi nimi je to, mezi čím si reálně vybíráte.

Porovnat běžící obchod s rozpočtem je poctivější test než porovnávat dva dokumenty, takže pokud chcete vidět, co se vlastně zřídí, spusťte web v průvodci — kartu nechce a subdoména, kterou dostanete, vám zůstane natrvalo i po připojení vlastní domény.