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

Офертата пристига по имейл и на първо четене изглежда преживяема. Програмист, на когото вярвате, е остойностил резервационна система — търсене, резултати, checkout, един административен екран, три месеца — и числото не е абсурдно. Искате своя система вече две години. Точно в този момент въпросът white label или своя резервационна система наистина се решава, и обикновено се решава по погрешното доказателство: по цената на първия месец вместо по формата на втората година.
Офертата е честна. Тя просто покрива само онази част от работата, която виждате.
Какво всъщност остойностява една оферта за разработка
Почти всеки бюджет, който ще ви подадат, остойностява повърхности: форма за търсене, списък с резултати, страница с данни на пътниците, стъпка за плащане, таблица с резервации в администрацията. Тази работа е реална и компетентен екип я върши добре. Тя е обаче стоковата половина — половината, по която две агенции, продаващи една и съща линия, никога не се конкурират. Никой не е избирал агенция, защото екранът ѝ за наличности е имал по-добри отстояния.
Другата половина стои на онази страна на връзката, която не се вижда от браузър. Там отиват годините.
Цената е броят интеграции, не интерфейсът
Поискайте достъп от доставчик и няма да получите API ключ с обратна поща. Получавате тестова среда, процес по сертификация, идентификационни данни, издадени за конкретно юридическо лице, документ с правила и лице за контакт, което отговаря по свой собствен календар. После се сблъсквате с диалекта точно на този доставчик: статични цени на едно място и живи наличности на друго, allotment с release period редом с free-sale, cut-off, който системата ви трябва да спазва, fare rules, които решават дали промяната е платена, и каталог с ancillaries, който не се съотнася с ничий друг. Сега умножете това по броя доставчици, които клиентите очакват да носите.
Една интеграция е проект. Шест са отдел — и той никога не завършва, защото нито един от тези шест не е поемал ангажимент да спре да се променя.
Същият капан стои зад всеки екран, който офертата все пак изброява. Търсенето изглежда като една функция, докато не носите две авиокомпании, които връщат един и същ маршрут на различна цена, и трябва в код да решите коя от двете вижда клиентът. Възстановяването изглежда като бутон, докато fare rule казва неустойка, доставчикът казва voucher, а клиентът казва карта. Надценките изглеждат като число в настройките до деня, в който искате едно правило за корпоративни клиенти, друго за подагент във Варна и трето за влязъл от улицата — на същата цена.
Тази аритметика е онова, което офертата за разработка пропуска, и това не е грешка при закръгляне спрямо интерфейса — това е самият продукт. При white label платформа работата вече е свършена и вече е обезпечена с хора: съдържанието на доставчиците стига до магазина през supplier groups, а не през договори, които подписвате един по един, и сайтът включва самолетни билети, хотели, пакетни турове или атракции според това, което наистина продава.
Сравнението, което издържа втората година
Четете таблицата като оператор, не като купувач. Във всеки ред въпросът е един и същ: на кого е вратът?
| Сами си я правите | White label | |
|---|---|---|
| Време до първата истинска резервация | Цикъл на разработка, после сертификация при всеки доставчик | Същия ден, на поддомейн на платформата — съветникът за регистрация го осигурява, без да иска карта |
| Връзки с доставчици | Ваши са за издействане, сертифициране и поддръжка, една по една | Включени; включвате тези, които продавате |
| Езици и валути при старт | Каквото сте задали и платили | 40 езика, включително пишещите се отдясно наляво; всеки сайт избира своя валута по подразбиране и списъка, който предлага |
| Доставчик променя своя API | Вашият backlog, по техния срок | Проблем на платформата, решен веднъж за всички tenant-и |
| Издаването на билети пада в 02:00 | Вие, или онзи програмист, който отговори | Дежурството на платформата |
| Промяна във вида на сайта | Release | Настройка — тема, цветове, шрифтове и лого се сменят от администрацията без ново разгръщане |
| Работен процес, който никой друг не продава | Може да се изгради точно както работите | Само ако платформата вече го моделира |
| Кой притежава кода | Вие | Не вие — притежавате бранда, клиентите и търговските условия |
Два от тези редове говорят в полза на собствената разработка. Те не са утешителни награди. Ако това, което продавате, е достатъчно необичайно, те натежават над всичко останало.
Какво ви струва грешният избор
Собствената система се проваля не като проект, който се срутва. Срутванията са видими, болезнени и преживяеми. Скъпата версия е система, която работи — и после бавно спира.
Програмистът, който я е писал, продължава нататък, а следващият остойностява всяка дребна промяна като риск, защото никой жив не е чел кода. Доставчик спира endpoint по свой календар и резервациите започват да падат така, че клиентите го забелязват преди мониторинга ви. Fare rule, кодирано правилно през първата година, никога не се преглежда отново, а ADM, който идва след това, се начислява на вашия IATA номер, не на изпълнителя. Платежните данни изтичат. Сертификатите изтичат. Framework две версии назад се превръща в разговор за сигурност, за който не сте планирали седмица.
Нищо от това не идва като фактура и точно затова никога не влиза в сравнението, което хората наистина правят. Идва като внимание. Собственик, който изкарва вторника върху счупен PNR, във вторник не продава; а агенциите, които замлъкват след собствена разработка, рядко замлъкват защото софтуерът е отказал — замлъкват, защото човекът, който преди носеше бизнес, сега поддържа система.
Кога собствената разработка наистина е правилният ход
Понякога е, и случаите са достатъчно конкретни, за да се премерите по тях.
- Софтуерът е разликата. Ако продавате технология на други туристически фирми, вместо да продавате пътувания, не можете да изнесете навън точно това, за което таксувате.
- Вече имате инженери и сте предвидили втория. Не онзи, който ще го построи — поддържащия, който го поема, след като първият си тръгне. Разработка без план за приемственост е наем с допълнителни стъпки.
- Водите процес, който никой не моделира. Оператор на поклоннически пътувания, който държи свои легла и шие групови PNR към етапи по визите, не прави нещо, в което един общ софтуер някога ще легне точно.
Има и път, който не е нито едното: купете магазина, изградете само онова парче, което наистина е ваше. Платформата предоставя API за самолетни билети и хотели точно за това, макар достъпът да започва като разговор, а не като самообслужващ ключ. Остойностете хибрида, преди да се обвържете с цялата разработка, защото частта, която всъщност искахте да контролирате, обикновено е един процес, не цяла система.
А ако моделът ви върви на подагенти, остойностете и това както трябва. Кредитните лимити и settlement фактурирането тук са понятия от първи ред, а не таблица, която някой засича в неделя; в собствена разработка са втори проект, който никой не е сложил в първата оферта.
Един въпрос, зададен и на двете страни
Преди да подпишете нещо, задайте един и същ въпрос на програмиста и на платформата: доставчик променя сертификацията си през март — кой върши работата, по чий срок и как научавам за това? Отговорите няма да си приличат, а разликата между тях е онова, между което наистина избирате.
Да сравните работещ магазин с оферта е по-честен тест от сравняването на два документа, така че ако искате да видите какво реално се осигурява, преди да се обвържете с нещо, стартирайте сайт в съветника — карта не иска, а поддомейнът, който получавате, остава завинаги, дори след като закачите собствен домейн.