White label, yoxsa öz booking engine-ini qurmaq

Təklif gəlir və dözüləsi görünür. Etibar etdiyiniz developer booking engine-in qiymətini vermişdir — axtarış, nəticələr, checkout, bir admin ekranı, üç ay — və rəqəm absurd deyil. İki ildir öz sisteminizi istəyirsiniz. Məhz bu anda white label, yoxsa öz booking engine sualı həll olunur və adətən səhv dəlil üzərində həll olunur: ikinci ilin formasına yox, birinci ayın qiymətinə baxılır.

Təklif vicdanlıdır. Sadəcə işin yalnız gördüyünüz hissəsinə aiddir.

Qiymət təklifi əslində nəyin haqqını yazır

Sizə veriləcək demək olar ki, hər təklif səthlərin qiymətidir: axtarış formu, nəticə siyahısı, sərnişin məlumatları səhifəsi, ödəniş addımı, admin paneldə rezervasiyalar cədvəli. Bu iş realdır və bacarıqlı komanda onu yaxşı görür. Amma bu, eyni zamanda kommodity hissəsidir — eyni marşrutu satan iki agentliyin heç vaxt rəqabət aparmadığı hissə. Heç kim availability ekranının boşluqları daha səliqəli olduğu üçün agentlik seçməyib.

Digər yarısı isə bağlantının brauzerdən görünməyən tərəfidir. İllər orada gedir.

Xərc interfeys deyil, inteqrasiyaların sayıdır

Təchizatçıdan giriş istəyəndə cavab məktubunda API açarı almırsınız. Test mühiti, sertifikasiya prosesi, hər hüquqi şəxs üçün ayrıca verilən credentials, qaydalar sənədi və öz cədvəli ilə cavab verən bir əlaqələndirici alırsınız. Sonra həmin təchizatçının öz dialekti ilə tanış olursunuz: bir yerdə static rates, başqa yerdə live availability, release period-lu allotment-in yanında free-sale, engine-inizin əməl etməli olduğu cut-off, dəyişikliyin ödənişli olub-olmadığını həll edən fare rules, heç kimin siyahısına oturmayan ancillary kataloqu. İndi bunu müştərilərinizin sizdən gözlədiyi təchizatçı sayına vurun.

Bir inteqrasiya bir layihədir. Altı inteqrasiya bir şöbədir və heç vaxt bitmir, çünki o altıdan heç biri dəyişməyi dayandırmağa söz verməyib.

Eyni tələ təklifin saydığı hər ekranın arxasında da oturur. İki aviaşirkət eyni marşrutu fərqli qiymətə qaytarana və müştərinin hansını görəcəyinə kodda qərar verməli olana qədər axtarış bir funksiya kimi görünür. Fare rule cərimə deyənə, təchizatçı voucher deyənə, müştəri isə kart deyənə qədər geri ödəniş bir düymə kimi görünür. Korporativ müştərilər üçün bir qayda, Gəncədəki sub-agent üçün başqa, eyni tarifdə küçədən gələn müştəri üçün üçüncü qaydanı istədiyiniz günə qədər markup parametrlər səhifəsindəki bir rəqəmdir.

Bu hesab qiymət təklifindən kənarda qalır və bu, UI-a nisbətən yuvarlaqlaşdırma xətası deyil — məhsulun özüdür. White label platformada iş artıq görülüb və kadrı var: təchizatçı məzmunu bir-bir imzaladığınız müqavilələrlə deyil, supplier groups vasitəsilə storefront-a çatır, sayt isə həqiqətən nə satırsa onu — uçuşları, otelləri, tur paketlərini və ya attraction-ları — işə salır.

İkinci illə toqquşmaya davam gətirən müqayisə

Cədvəli alıcı kimi yox, operator kimi oxuyun. Hər sətirdə sual eynidir: məsuliyyət kimin üzərindədir?

Bu sətirlərdən ikisi qurmağın xeyrinədir. Bunlar təsəlli mükafatı deyil. Satdığınız şey kifayət qədər qeyri-adidirsə, onlar yuxarıdakı hər şeydən ağır gəlir.

Səhv qərarın qiyməti

Öz-özünə qurulmuş engine-in uğursuzluğu dağılan layihə deyil. Onlar görünür, ağrıdır və keçir. Bahalı variant işləyən, sonra yavaş-yavaş dayanan sistemdir.

Onu yazan developer başqa yerə keçir, növbəti isə hər kiçik dəyişikliyə risk kimi qiymət verir, çünki o kodu sağ olan heç kim oxumayıb. Təchizatçı öz cədvəli ilə bir endpoint-i ləğv edir və rezervasiyalar elə şəkildə uğursuz olur ki, müştəriləriniz bunu monitorinqinizdən əvvəl görür. Birinci ildə düzgün yazılmış fare rule bir daha nəzərdən keçirilmir və ardınca gələn ADM podratçıya yox, sizin IATA nömrənizə yazılır. Ödəniş credentials-ının müddəti bitir. Sertifikatların müddəti bitir. İki versiya geri qalmış framework bir həftə ayırmadığınız təhlükəsizlik söhbətinə çevrilir.

Bunların heç biri invoys kimi gəlmir, ona görə də insanların həqiqətən apardığı müqayisədə heç vaxt görünmür. O, diqqət şəklində gəlir. Çərşənbə axşamını sınıq PNR-a sərf edən sahibkar həmin gün satmır; öz sistemini qurduqdan sonra səssizləşən agentliklər adətən proqram sındığı üçün yox, biznes gətirən adamın indi sistemi saxladığı üçün səssizləşir.

Qurmaq həqiqətən düzgün olanda

Bəzən düzgündür və hallar özünüzü yoxlaya biləcəyiniz qədər konkretdir.

• Fərqiniz proqram təminatıdır. Səyahət satmaq əvəzinə digər səyahət bizneslərinə texnologiya satırsınızsa, pul aldığınız şeyi kənara verə bilməzsiniz.
• Artıq mühəndisləriniz var və ikincisinin büdcəsini ayırmısınız. Quran developer yox — birincisi gedəndən sonra onu üzərinə götürən adam. Varislik planı olmayan bir build əlavə addımlarla icarədir.
• Heç kimin modelləşdirmədiyi bir iş axınınız var. Öz yerlərini saxlayan, qrup PNR-larını viza mərhələlərinə tikən ziyarət operatoru universal engine-in heç vaxt tam oturmayacağı bir iş görür.

Üçüncü yol da var: storefront-u alın, yalnız həqiqətən sizə aid olan hissəni qurun. Platforma məhz bunun üçün uçuş və otel API-ləri verir, amma giriş self-serve açardan çox bir söhbətlə başlayır. Bütöv build-ə keçməzdən əvvəl bu hibridin qiymətini hesablayın, çünki nəzarət etmək istədiyiniz hissə adətən bütöv engine yox, bir iş axınıdır.

Modeliniz sub-agent-lər üzərində qurulubsa, onu da düzgün qiymətləndirin. Burada credit limit və settlement invoysu birinci dərəcəli anlayışlardır, kiminsə bazar günü tutuşdurduğu cədvəl deyil; build-də isə bu, ilk təklifə heç kimin yazmadığı ikinci layihədir.

Hər iki tərəfə verilən bir sual

Nəsə imzalamazdan əvvəl eyni sualı həm developerə, həm platformaya verin: gələn mart ayında təchizatçı sertifikasiyasını dəyişir — işi kim görür, kimin son tarixi ilə və mən bunu necə bilirəm? Cavablar oxşar olmayacaq və aralarındakı fərq əslində seçdiyiniz şeydir.

İşləyən storefront-u təkliflə müqayisə etmək iki sənədi müqayisə etməkdən daha dürüst sınaqdır. Ona görə də nəyəsə bağlanmadan öncə nəyin hazırlandığını görmək istəyirsinizsə, sihirbazda bir sayt başladın — kart istəmir və verdiyi subdomen öz domeninizi qoşandan sonra da daimi qalır.