White label или сопствени систем резервација?

Понуда је стигла мејлом и на прво читање изгледа преживљиво. Програмер коме верујете је испроцењивао систем резервација — претрага, резултати, наплата, један администраторски екран, три месеца — и цифра није апсурдна. Свој систем желите већ две године. Управо се тада заиста решава питање white label или сопствени систем резервација, и решава се обично по погрешном доказу: по цени првог месеца, а не по облику друге године.

Понуда није непоштена. Она само покрива онај део посла који видите.

Шта понуда за развој заиста процењује

Скоро сваки буџет који ће вам дати процењује површине: форму за претрагу, листу резултата, страницу са подацима путника, корак плаћања, таблицу резервација у администрацији. Тај посао је стваран и способан тим га одради добро. То је, међутим, роба — она половина на којој две агенције које продају исту линију никада не конкуришу. Нико није изабрао агенцију зато што је њен екран за расположивост имао бољи проред.

Друга половина стоји на оној страни везе која се из прегледача не види. Тамо одлазе године.

Цена је број интеграција, а не интерфејс

Тражите од добављача приступ и нећете добити API кључ повратном поштом. Добијате тест окружење, процес сертификације, приступне податке издате по правном лицу, документ са правилима и особу за контакт која одговара по свом календару. Затим се сусрећете са дијалектом баш тог добављача: статичне цене на једном месту и живу расположивост на другом, allotment са release period-ом уз free-sale, cut-off који ваш систем мора да поштује, fare rules који одлучују да ли је измена наплатива, и каталог ancillaries који се не мапира ни на чији други. Сад то помножите бројем добављача које клијенти очекују да носите.

Једна интеграција је пројекат. Шест их је одељење — и никада се не завршава, јер ни један од те шесторице није обећао да ће престати да се мења.

Иста замка стоји и за сваким екраном који понуда јесте набројала. Претрага изгледа као једна функција све док не носите две авио-компаније које враћају исти итинерер по различитој цени, па у коду морате одлучити коју клијент види. Рефундација изгледа као дугме све док fare rule не каже пенал, добављач не каже voucher, а клијент карту. Маржа изгледа као број у подешавањима до дана када хоћете једно правило за корпоративне клијенте, друго за подагента у Новом Саду и треће за оног који уђе са улице — на истој цени.

Та аритметика је оно што понуда за развој испушта, и то није грешка заокруживања према интерфејсу — то је сам производ. На white label платформи посао је већ обављен и већ покривен људима: садржај добављача долази до продавнице преко supplier groups, а не преко уговора које потписујете један по један, и сајт укључује авио-карте, хотеле, туристичке пакете или атракције према томе шта заиста продаје.

Поређење које преживи другу годину

Читајте таблицу као оператива, не као купац. У сваком реду је исто питање: на чијем је врату?

Два реда говоре у корист градње. Нису утешне награде. Ако је оно што продајете довољно необично, претежу над свим осталим.

Колико вас кошта погрешан избор

Сопствени систем не пада као пројекат који се уруши. Урушавања су видљива, болна и преживљива. Скупа верзија је систем који ради — а онда споро престаје.

Програмер који га је написао одлази даље, а следећи процењује сваку малу измену као риск, јер кода нико живи није прочитао. Добављач укине endpoint по свом календару и резервације почну да падају тако да клијенти то виде пре вашег мониторинга. Fare rule тачно кодиран прве године више се не преиспитује, а ADM који дође наплаћује се на ваш IATA број, не на извођачев. Платни подаци истичу. Сертификати истичу. Framework две верзије назад постаје разговор о безбедности за који нисте планирали недељу.

Ништа од тога не долази као фактура, и зато никада не улази у поређење које људи стварно направе. Долази као пажња. Власник који уторак проведе над поквареним PNR-ом у уторак не продаје; а агенције које утихну после сопствене градње ретко утихну зато што је софтвер отказао — утихну зато што онај који је раније доводио посао сада одржава систем.

Када је градња заиста прави потез

Понекад јесте, и случајеви су довољно конкретни да се измерите по њима.

• Софтвер је сама разлика. Ако продајете технологију другим туристичким фирмама, а не путовања, не можете изнети другоме баш оно за шта наплаћујете.
• Већ имате инжењере и предвидели сте другог. Не онога који гради — оног који одржава кад први отиде. Градња без плана наслеђивања је закуп са неколико корака више.
• Водите процес који нико не моделује. Организатор поклоничких путовања који држи своје лежајеве и веже групне PNR-ове са роковима за визе не ради ништа у шта ће општи систем икада тачно лећи.

Постоји и пут који није ни једно ни друго: купите продавницу, изградите само онај део који је стварно ваш. Платформа излаже API за авио-карте и хотеле управо за то, мада приступ почиње као разговор, а не као самоуслужни кључ. Испроцењујте хибрид пре него што се обавежете на целу градњу, јер део који сте заиста хтели да контролишете обично је један процес, а не цео систем.

А ако вам модел стоји на подагентима, испроцењујте и то како треба. Кредитни лимити и settlement фактурисање су овде појмови првог реда, а не таблица коју неко усклађује недељом; у сопственој градњи то је други пројекат који нико није ставио у прву понуду.

Једно питање, постављено обема странама

Пре него што нешто потпишете, поставите исто питање програмеру и платформи: добављач у марту промени своју сертификацију — ко ради посао, по чијем року и како ја то сазнам? Одговори неће бити слични, а разлика међу њима је оно између чега стварно бирате.

Упоредити продавницу која ради са понудом је поштенији тест од упоређивања два документа, па ако хоћете да видите шта се заиста обезбеђује пре него што се на било шта обавежете, покрените сајт у чаробњаку — картицу не тражи, а поддомен који добијете остаје вам заувек, чак и после што прикачите свој домен.