White label vagy saját foglalási rendszer?

Megjött az ajánlat, és első ránézésre kibírható. Egy fejlesztő, akiben bízik, beárazta a foglalási rendszert — keresés, találati lista, pénztár, egy admin felület, három hónap —, és a szám nem abszurd. Két éve szeretne saját rendszert. Pontosan ilyenkor dől el a white label vagy saját foglalási rendszer kérdés, és többnyire rossz bizonyíték alapján dől el: az első hónap ára alapján, nem a második év alakja alapján.
Az ajánlat tisztességes. Csak arra a részére szól a munkának, amit lát.
Mit áraz be valójában egy fejlesztési ajánlat
Szinte minden költségvetés, amit a kezébe adnak, felületeket áraz: keresőűrlapot, találati listát, utasadat-oldalt, fizetési lépést, foglalási táblát az adminban. Ez a munka valós, és egy hozzáértő csapat jól megoldja. Ez ugyanakkor a tömegtermék fele — az a fele, amin két, ugyanazt a járatot értékesítő iroda soha nem verseng. Senki nem azért választott irodát, mert szebb sortávolság volt a szabadhely-felületén.
A másik fele a kapcsolat azon oldalán van, amit böngészőből nem látni. Oda mennek el az évek.
A költség az integrációk száma, nem a felület
Ha hozzáférést kér egy szállítótól, nem API-kulcsot kap válaszlevélben. Kap egy tesztkörnyezetet, egy tanúsítási folyamatot, jogi személyenként kiadott belépőket, egy szabálydokumentumot és egy kapcsolattartót, aki a saját naptára szerint válaszol. Utána találkozik az adott szállító nyelvjárásával: statikus árak az egyik helyen, élő szabadhely a másikon, allotment release period-dal a free-sale mellett, cut-off, amit a rendszerének tartania kell, fare rules, amik eldöntik, hogy egy módosítás díjköteles-e, és egy ancillaries-katalógus, ami senki máséra nem képezhető le. Ezt most szorozza meg annyi szállítóval, amennyit a klienseitől elvárnak.
Egy integráció projekt. Hat integráció osztály — és soha nem fejeződik be, mert a hat közül egyik sem vállalta, hogy abbahagyja a változást.
Ugyanez a csapda ott van minden felület mögött, amit az ajánlat felsorol. A keresés egy funkciónak látszik addig, amíg nem visz két légitársaságot, amelyek ugyanazt az útvonalat más áron adják vissza, és kódban kell eldöntenie, melyiket látja a kliens. A visszafizetés gombnak látszik addig, amíg a fare rule bánatpénzt mond, a szállító vouchert, a kliens pedig kártyát. A felárak egy számnak látszanak a beállításokban addig a napig, amikor egy szabályt akar a céges ügyfelekre, egy másikat egy debreceni alügynökre és egy harmadikat az utcáról betérőre — ugyanazon a jegyáron.
Ez az a számtan, amit a fejlesztési ajánlat kihagy, és ez nem kerekítési hiba a felülethez képest — ez maga a termék. Egy white label platformon a munka már készen van és már van rá ember: a szállítói tartalom supplier groups révén ér el az üzletig, nem egyenként megírt szerződések révén, és egy oldal aszerint kapcsolja be a repülőjegyet, a szállodát, a csomagokat vagy a látnivalókat, amit tényleg értékesít.
Az összehasonlítás, ami kitart a második évig
Üzemeltetőként olvassa a táblázatot, ne beszerzőként. Minden sorban ugyanaz a kérdés: kinek a nyakán van?
| Saját fejlesztés | White label | |
|---|---|---|
| Idő az első valódi foglalásig | Egy fejlesztési ciklus, utána tanúsítás minden szállítónál | Ugyanaznap, a platform aldomainjén — a regisztrációs varázsló kártya nélkül létrehozza |
| Szállítói kapcsolatok | A magáé megszerezni, tanúsítani és életben tartani, egyenként | Benne van; azt kapcsolja be, amit értékesít |
| Nyelvek és valuták induláskor | Amit specifikált és kifizetett | 40 nyelv, a jobbról balra írókkal együtt; minden oldal maga választ alapvalutát és kínált listát |
| Egy szállító módosítja az API-ját | A maga backlogja, az ő határidejükre | A platform gondja, egyszer megoldva minden tenantnak |
| Hajnali kettőkor elhasal a ticketing | Ön, vagy az a fejlesztő, aki felveszi | A platform készenléte |
| Az oldal megjelenésének módosítása | Egy release | Egy beállítás — téma, színek, betűtípusok és logó az adminból változik, újratelepítés nélkül |
| Olyan folyamat, amit más nem értékesít | Megépíthető, pontosan úgy, ahogy dolgozik | Csak ha a platform már modellezi |
| Kié a kód | Az Öné | Nem az Öné — a márka, a kliensek és a kereskedelmi feltételek az Önéi |
Két sor a fejlesztés mellett szól. Ezek nem vigaszdíjak. Ha elég szokatlan, amit értékesít, többet nyomnak a latban, mint felettük minden.
Mibe kerül, ha rosszul dönt
A saját rendszer nem összeomlással hibázik. Az összeomlás látható, fájdalmas és túlélhető. A drága változat egy működő rendszer — ami aztán lassan leáll.
A fejlesztő, aki megírta, továbbmegy, a következő pedig minden apró módosítást kockázatként áraz, mert a kódot élő ember nem olvasta. Egy szállító a saját naptára szerint kivezet egy endpointot, és a foglalások úgy kezdenek hibázni, hogy a kliensek előbb észreveszik, mint a monitorozás. Az első évben helyesen kódolt fare rule-t senki nem vizsgálja újra, és a nyomában érkező ADM az Ön IATA-számára megy, nem a vállalkozóéra. A fizetési belépők lejárnak. A tanúsítványok lejárnak. Egy két verzióval elmaradt framework biztonsági beszélgetéssé válik, amire nem tervezett egy hetet.
Ezek egyike sem számlaként érkezik, és épp ezért nem szerepel abban az összehasonlításban, amit az emberek valóban elvégeznek. Figyelemként érkezik. Az a tulajdonos, aki a keddjét egy elrontott PNR-re fordítja, kedden nem értékesít; és azok az irodák, amelyek egy saját fejlesztés után elhallgatnak, ritkán a szoftver hibája miatt hallgatnak el — azért hallgatnak el, mert aki korábban hozta az üzletet, most üzemeltet.
Amikor a fejlesztés valóban a helyes döntés
Néha az, és az esetek elég konkrétak ahhoz, hogy magát hozzámérje.
- A szoftver maga a különbség. Ha technológiát ad el más utazási cégeknek, nem utazást, nem szervezheti ki azt, amiért számláz.
- Már van fejlesztője, és a másodikat is betervezte. Nem azt, aki megépíti — azt az üzemeltetőt, aki átveszi, amikor az első továbbmegy. Utódlási terv nélküli fejlesztés bérlés, plusz néhány lépés.
- Olyan folyamatot visz, amit senki nem modellez. Egy zarándokutakat szervező operátor, aki saját ágyakat tart és csoportos PNR-eket fűz vízum-mérföldkövekhez, nem olyat csinál, amire egy általános rendszer valaha is pontosan illeszkedik.
Van egy út, ami egyik sem: vegye meg az üzletet, és csak azt a darabot építse meg, ami valóban a magáé. A platform épp erre tesz elérhetővé repülőjegy- és szálloda-API-kat, bár a hozzáférés beszélgetéssel indul, nem önkiszolgáló kulccsal. Árazza be a hibridet, mielőtt a teljes fejlesztés mellett elkötelezi magát, mert amit valóban kézben akart tartani, az általában egy folyamat, nem egy egész rendszer.
És ha a modellje alügynökökön áll, azt is árazza be rendesen. A hitelkeret és a settlement-számlázás itt elsőrangú fogalmak, nem egy táblázat, amit valaki vasárnap egyeztet; saját fejlesztésben ezek egy második projekt, amit senki nem tett bele az első ajánlatba.
Egy kérdés, mindkét oldalnak
Mielőtt bármit aláír, tegye fel ugyanazt a kérdést a fejlesztőnek és a platformnak: egy szállító márciusban módosítja a tanúsítását — ki végzi el a munkát, kinek a határidejére, és én honnan tudom meg? A válaszok nem lesznek hasonlók, és a különbségük az, amiből valójában választ.
Egy futó üzletet ajánlathoz mérni tisztességesebb próba, mint két dokumentumot összevetni, úgyhogy ha látni akarja, mi jön létre valójában, mielőtt bármit elkötelez, indítson egy oldalt a varázslóban — kártyát nem kér, és a kapott aldomain véglegesen megmarad, akkor is, ha később a saját domainjét kötötte rá.