White label eller egen bookingmotor?

Tilbuddet ligger i indbakken, og det ser til at kunne overleves. En udvikler du stoler på har prissat en bookingmotor — søgning, resultatliste, checkout, en adminskærm, tre måneder — og tallet er ikke absurd. Du har ønsket dig dit eget system i to år. Det er her valget mellem white label eller egen bookingmotor reelt bliver truffet, og det bliver næsten altid truffet på det forkerte grundlag: prisen på måned et i stedet for formen på år to.
Tilbuddet er ærligt. Det dækker bare den del af arbejdet, du kan se.
Hvad et udviklingstilbud faktisk prissætter
Næsten hvert budget, du får i hånden, prissætter overflader: en søgeformular, en resultatliste, en side med passageroplysninger, et betalingstrin, en bookingtabel i administrationen. Arbejdet er virkeligt, og et kompetent team løser det fint. Det er også den halvdel, der er en handelsvare — halvdelen, hvor to bureauer, der sælger samme rute, aldrig konkurrerer. Ingen har valgt et rejsebureau, fordi dets tilgængelighedsskærm havde bedre linjeafstand.
Den anden halvdel sidder på den side af forbindelsen, du ikke kan se fra en browser. Det er der, årene forsvinder.
Prisen er antallet af integrationer, ikke brugerfladen
Bed en leverandør om adgang, og du får ikke en API-nøgle med returposten. Du får et testmiljø, en certificeringsproces, loginoplysninger udstedt per juridisk enhed, et regeldokument og en kontaktperson, der svarer efter sin egen kalender. Så møder du netop den leverandørs dialekt: statiske priser et sted og live tilgængelighed et andet, allotment med release period lige ved siden af free-sale, en cut-off din motor skal respektere, fare rules der afgør, om en ombooking koster, og et ancillaries-katalog, der ikke passer på nogen andens. Gang det så med antallet af leverandører, dine kunder forventer, du fører.
Én integration er et projekt. Seks er en afdeling, og den bliver aldrig færdig, for ingen af de seks har lovet at holde op med at ændre sig.
Den samme fælde ligger bag hver skærm, tilbuddet faktisk nævner. Søgning ser ud som én funktion, indtil du fører to flyselskaber, der returnerer samme rejse til forskellig pris, og du skal afgøre i kode, hvilken kunden ser. En refusion ser ud som en knap, indtil fare rule siger gebyr, leverandøren siger voucher og kunden siger kort. Markups ser ud som et tal på en indstillingsside, indtil den dag du vil have én regel for erhvervskunder, en anden for en underagent i Aarhus og en tredje for gadesalg på samme billetpris.
Det regnestykke er det, et byggetilbud udelader, og det er ikke en afrundingsfejl mod brugerfladen — det er produktet. På en white label-platform er arbejdet allerede gjort og allerede bemandet: leverandørindhold når en butik gennem supplier groups i stedet for gennem aftaler, du underskriver én ad gangen, og et site slår fly, hoteller, pakkerejser eller attraktioner til efter, hvad det faktisk sælger.
Sammenligningen, der holder ind i år to
Læs tabellen som driftsansvarlig, ikke som indkøber. Spørgsmålet i hver række er det samme: hvem hænger på den?
| Byg det selv | White label | |
|---|---|---|
| Tid til første rigtige booking | En udviklingscyklus, derefter certificering hos hver leverandør | Samme dag, på et subdomæne hos platformen — tilmeldingsguiden opretter det uden at bede om kort |
| Leverandørforbindelser | Dine at skaffe, certificere og vedligeholde, én ad gangen | Inkluderet; du slår dem til, du sælger |
| Sprog og valutaer ved start | Det du fik specificeret og betalt for | 40 sprog, højre-mod-venstre inkluderet; hvert site vælger sin egen standardvaluta og listen, det tilbyder |
| En leverandør ændrer sit API | Din backlog, på deres deadline | Platformens problem, løst én gang for alle tenants |
| Ticketing fejler kl. 02:00 | Dig, eller den udvikler der tager telefonen | Platformens vagt |
| Ændre hvordan sitet ser ud | En release | En indstilling — tema, farver, fonte og logo ændres i administrationen uden ny deployment |
| En arbejdsgang ingen andre sælger | Kan bygges, præcis som du driver den | Kun hvis platformen allerede modellerer den |
| Hvem ejer koden | Dig | Ikke dig — du ejer brandet, kunderne og de kommercielle vilkår |
To af rækkerne taler for at bygge. De er ikke trøstepræmier. Er det du sælger usædvanligt nok, vejer de tungere end alt ovenover.
Hvad det koster dig at vælge forkert
En egenbygget motor bryder sjældent sammen. Sammenbrud er synlige, dyre og til at overleve. Den dyre version er et system, der virker — og så langsomt holder op.
Udvikleren, der skrev det, går videre, og den næste prissætter hver lille ændring som en risiko, fordi ingen levende har læst koden. En leverandør udfaser en endpoint efter sin egen kalender, og bookinger begynder at fejle på en måde, dine kunder bemærker før din overvågning. En fare rule, der blev kodet rigtigt i år et, bliver aldrig revideret, og den ADM, der følger, debiteres dit IATA-nummer, ikke konsulentens. Betalingsoplysninger udløber. Certifikater udløber. Et framework to versioner bagud bliver en sikkerhedssamtale, du ikke havde afsat en uge til.
Intet af det kommer som en faktura, og derfor optræder det aldrig i den sammenligning, folk faktisk laver. Det kommer som opmærksomhed. En ejer, der bruger tirsdagen på et ødelagt PNR, sælger ikke på tirsdagen, og bureauer, der bliver stille efter et egetbyggeri, bliver sjældent stille, fordi softwaren fejlede — de bliver stille, fordi den, der før hentede forretning ind, nu vedligeholder systemet.
Når det reelt er rigtigt at bygge — og den vej, der er ingen af dem
Det sker, og tilfældene er konkrete nok til at holde op mod dig selv. Gå listen igennem, og vær ærlig ved hvert punkt.
- Softwaren er forskellen. Sælger du teknologi til andre rejsevirksomheder i stedet for at sælge rejser, kan du ikke outsource præcis det, du tager penge for.
- Du har allerede udviklere, og du har budgetteret den anden. Ikke den, der bygger — vedligeholderen, der overtager, når den første er væk. Et byggeri uden successionsplan er leje med ekstra trin.
- Du driver en arbejdsgang, ingen modellerer. En operatør, der holder sine egne senge og syr gruppe-PNR sammen med visummilepæle, gør ikke noget, en generisk motor nogensinde passer helt til.
Der er også en vej, der er ingen af dem: køb butikken, byg kun det stykke, der virkelig er dit. Platformen udstiller fly- og hotel-API'er til netop det, selvom adgang starter som en samtale frem for en selvbetjeningsnøgle. Prissæt hybriden, før du binder dig til hele byggeriet, for den del du egentlig ville styre, er oftest én arbejdsgang, ikke en hel motor. Og kører din model på underagenter, så prissæt også det ordentligt: kreditgrænser og settlement-fakturering er førsteklasses begreber her, ikke et regneark nogen afstemmer om søndagen.
Før du underskriver noget, så stil udvikleren og platformen samme spørgsmål: en leverandør ændrer sin certificering til marts — hvem gør arbejdet, på hvis deadline, og hvordan finder jeg ud af det? Svarene bliver ikke ens, og forskellen mellem dem er det, du reelt vælger imellem. At sammenligne en kørende butik med et tilbud er en ærligere prøve end at sammenligne to dokumenter, så vil du se, hvad der faktisk bliver oprettet, start et site i guiden — den beder ikke om kort, og subdomænet du får, beholder du permanent, også efter du har koblet dit eget domæne på.