White label alebo vlastný rezervačný systém?

Ponuka prišla mailom a na prvé prečítanie sa dá prežiť. Programátor, ktorému veríte, naceňoval rezervačný systém — vyhľadávanie, výsledky, platba, jedna obrazovka v administrácii, tri mesiace — a to číslo nie je absurdné. Vlastný systém chcete už dva roky. Presne v tejto chvíli sa rozhoduje otázka white label alebo vlastný rezervačný systém, a rozhoduje sa zvyčajne podľa nesprávneho dôkazu: podľa ceny prvého mesiaca namiesto toho, ako bude vyzerať druhý rok.

Tá ponuka nie je nečestná. Je len za tú časť práce, ktorú vidíte.

Čo ponuka na vývoj naozaj naceňuje

Takmer každý rozpočet, ktorý dostanete do ruky, oceňuje povrchy: vyhľadávací formulár, zoznam výsledkov, stránku s údajmi cestujúcich, platobný krok, tabuľku rezervácií v administrácii. Tá práca je reálna a schopný tím ju odvedie dobre. Je to však tá komoditná polovica — polovica, na ktorej dve agentúry predávajúce tú istú linku nikdy nesúťažia. Nikto si nikdy nevybral agentúru preto, že mala lepšie riadkovanie na obrazovke dostupnosti.

Druhá polovica leží na tej strane spojenia, ktorú z prehliadača nevidíte. Tam odchádzajú roky.

Cena je počet integrácií, nie rozhranie

Keď požiadate dodávateľa o prístup, nedostanete spätnou poštou API kľúč. Dostanete testovacie prostredie, certifikačný proces, prihlasovacie údaje vydané na konkrétny právny subjekt, dokument s pravidlami a kontaktnú osobu, ktorá odpovedá podľa vlastného kalendára. Potom narazíte na dialekt práve toho dodávateľa: statické ceny na jednom mieste a živú dostupnosť na druhom, allotment s release period hneď vedľa free-sale, cut-off, ktorý váš systém musí rešpektovať, fare rules rozhodujúce o tom, či je zmena spoplatnená, a katalóg ancillaries, ktorý sa nemapuje na nikoho iného. Teraz to vynásobte počtom dodávateľov, ktorých od vás klienti očakávajú.

Jedna integrácia je projekt. Šesť je oddelenie — a nikdy sa nedokončí, pretože ani jeden z tých šiestich sa nezaviazal prestať sa meniť.

Tá istá pasca sa skrýva aj za obrazovkami, ktoré ponuka vymenúva. Vyhľadávanie vyzerá ako jedna funkcia, kým nevezete dve letecké spoločnosti, ktoré vrátia totožné spojenie za inú cenu, a vy musíte v kóde rozhodnúť, ktorú z nich klient uvidí. Refundácia vyzerá ako tlačidlo, kým fare rule hovorí penále, dodávateľ hovorí voucher a klient hovorí kartu. Prirážky vyzerajú ako číslo v nastaveniach do dňa, kedy chcete jedno pravidlo pre korporátnych klientov, druhé pre subagenta v Košiciach a tretie pre pult v obchodnom centre — na tej istej cene.

Toto je tá aritmetika, ktorú ponuka na vývoj vynecháva, a nie je to chyba zaokrúhlenia proti UI. Je to samotný produkt. Na white label platforme je tá práca hotová a už obsadená ľuďmi: obsah dodávateľov sa dostane do obchodu cez supplier groups, nie cez zmluvy, ktoré podpisujete jednu po druhej, a stránka zapína letenky, hotely, zájazdy alebo atrakcie podľa toho, čo skutočne predáva.

Porovnanie, ktoré vydrží druhý rok

Čítajte tabuľku ako prevádzkar, nie ako nákupca. V každom riadku je tá istá otázka: na kom to visí?

Dva z tých riadkov hovoria za vlastný vývoj. Nie sú to útechy. Ak je to, čo predávate, dosť neobvyklé, prevážia všetko nad nimi.

Čo vás stojí nesprávne rozhodnutie

Vlastný systém nezlyháva ako projekt, ktorý sa zrúti. Tie sú viditeľné, bolia a dajú sa prežiť. Drahá verzia je systém, ktorý funguje — a potom pomaly prestáva.

Programátor, ktorý ho napísal, odíde inam, a ďalší naceňuje každú malú zmenu ako riziko, pretože ten kód nikto živý nečítal. Dodávateľ vyradí endpoint podľa vlastného kalendára a rezervácie začnú padať spôsobom, ktorý si klienti všimnú skôr než váš monitoring. Fare rule správne zakódované v prvom roku sa už nikdy nereviduje, a ADM, ktoré príde, ide na vaše IATA číslo, nie na dodávateľovo. Platobným údajom vyprší platnosť. Certifikátom vyprší platnosť. Framework dve verzie pozadu sa zmení na bezpečnostný rozhovor, na ktorý ste si týždeň nevyhradili.

Nič z toho neprichádza ako faktúra, a preto sa to v žiadnom porovnaní neobjaví. Prichádza to ako pozornosť. Majiteľ, ktorý strávi utorok nad rozbitým PNR, v utorok nepredáva — a agentúry, ktoré po vlastnom vývoji utíchnu, málokedy utíchnu preto, že zlyhal softvér. Utíchnu preto, že človek, ktorý predtým prinášal obchod, ho teraz udržiava.

Kedy je vlastný vývoj naozaj správna voľba

Niekedy je, a tie prípady sú dosť konkrétne, aby ste sa k nim priložili.

• Softvér je ten rozdiel. Ak predávate technológiu iným cestovným firmám namiesto cestovania, nemôžete outsourcovať práve to, za čo si účtujete.
• Už máte vývojárov a máte rozpočet na druhého. Nie na toho, kto to postaví — na toho, kto to prevezme, keď prvý odíde. Vývoj bez plánu nástupníctva je nájom s dvoma krokmi navyše.
• Vediete proces, ktorý nikto nemodeluje. Organizátor pútí, ktorý drží vlastné postele a zošíva skupinové PNR s termínmi víz, nerobí nič, do čoho by všeobecný systém niekedy úplne sadol.

Existuje aj cesta, ktorá nie je ani jedno: kúpte obchod a postavte len tú časť, ktorá je naozaj vaša. Platforma na to sprístupňuje API pre letenky a hotely, aj keď prístup začína rozhovorom, nie samoobslužným kľúčom. Naceňte hybrid skôr, než sa zaviažete k celému vývoju, pretože to, čo ste naozaj chceli mať pod kontrolou, je väčšinou jeden proces, nie celý systém.

A ak váš model stojí na subagentoch, naceňte aj to poriadne. Kreditné limity a settlement fakturácia sú tu pojmy prvého rádu, nie tabuľka, ktorú niekto v nedeľu odsúhlasuje; vo vlastnom vývoji je to druhý projekt, ktorý v prvej ponuke nikto nemal.

Jedna otázka pre obe strany

Skôr než čokoľvek podpíšete, položte programátorovi aj platforme tú istú otázku: dodávateľ v marci zmení certifikáciu — kto tú prácu odvedie, v koho termíne, a ako sa to dozviem? Odpovede nebudú podobné, a rozdiel medzi nimi je to, medzi čím si reálne vyberáte.

Porovnať bežiaci obchod s ponukou je čestnejší test než porovnávať dva dokumenty, takže ak chcete vidieť, čo sa vlastne zriadi, spustite stránku v sprievodcovi — kartu nechce a subdoména, ktorú dostanete, vám zostane natrvalo aj po pripojení vlastnej domény.