Ugrás a tartalomra
Blog

White label vagy saját foglalási rendszer?

Tekravel Szerkesztőség

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ésWhite label
Idő az első valódi foglalásigEgy fejlesztési ciklus, utána tanúsítás minden szállítónálUgyanaznap, a platform aldomainjén — a regisztrációs varázsló kártya nélkül létrehozza
Szállítói kapcsolatokA magáé megszerezni, tanúsítani és életben tartani, egyenkéntBenne van; azt kapcsolja be, amit értékesít
Nyelvek és valuták induláskorAmit specifikált és kifizetett40 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átA maga backlogja, az ő határidejükreA platform gondja, egyszer megoldva minden tenantnak
Hajnali kettőkor elhasal a ticketingÖn, vagy az a fejlesztő, aki felvesziA platform készenléte
Az oldal megjelenésének módosításaEgy releaseEgy 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ítMegépíthető, pontosan úgy, ahogy dolgozikCsak ha a platform már modellezi
Kié a kódAz Ö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á.

Tekravel Szerkesztőség

Utazástechnológiai rovat

A Tekravel utazástechnológiai rovata a szakmának ír: irodatulajdonosoknak, konszolidátoroknak és az őket integráló fejlesztőknek. Minden cikket a leírt platformon ellenőrzünk a megjelenés előtt.