Planlæg en bookinghjemmeside ud fra de beslutninger, der betyder noget

Kalenderen er den nemme del af en bookinghjemmeside. Det svære er de beslutninger, der skal træffes, før nogen vælger et plugin: hvordan en booking bliver bekræftet, hvilket system der må sige, at en dato er ledig, hvordan depositum og afbestilling fungerer, og hvad der sker i virksomheden, efter kunden har trykket på knappen.

Jeg har brugt en stor del af min karriere på netop de beslutninger. Jeg byggede og vedligeholdt PHP-bookingmotoren bag Thailand-villas.com fra 2001, til platformen blev solgt i 2022, og fra 2011 klik.villas, et administrationssystem til villaudlejning med integrationer til Booking.com, Agoda og Rentals United. Guiden her er bygget op om de spørgsmål, de systemer tvang os til at svare på.

Forespørgsel eller bekræftet booking?

Den første beslutning former resten: Sender kunden en forespørgsel, som nogen bekræfter, eller bekræfter hjemmesiden reservationen med det samme?

En forespørgsel giver plads. En person kan tjekke ledigheden, særlige ønsker kan afklares, og prisen kan justeres, før der er lovet noget. Prisen er tid. Kunden venter, sammenligner andre muligheder imens og booker måske et andet sted, før svaret kommer.

Direkte bekræftelse fjerner ventetiden, men flytter alle regler ind i systemet. Minimumsophold, skiftedage, sæsonpriser, ekstra gæster og blokerede datoer skal alle være korrekte i data, fordi ingen kontrollerer dem, før kunden får sin bekræftelse.

Thailand-villas.com kørte på forespørgsler det meste af tiden. En gæst sendte en forespørgsel, vi sendte den videre til villaens ejer og gav ejerens svar videre til gæsten. Det var langsomt, men indtil vi selv kunne se ejernes reservationer, var det kun ejeren, der kunne bekræfte datoerne. Da ejernes reservationer blev synlige i klik.villas, kunne forløbet automatiseres.

Mange virksomheder ender med begge dele: direkte booking, hvor reglerne er enkle og data er pålidelige, og en forespørgsel til resten. Det er en fin løsning, så længe hjemmesiden gør det tydeligt, hvilken af dem kunden bruger, og hvad der sker bagefter.

Beslut, hvilket system der ejer ledigheden

Så snart en bolig, et lokale eller en ydelse sælges flere steder, skal ledigheden have én ejer. Hvis både hjemmesiden, en channel manager og to bookingplatforme kan tage imod en booking på de samme datoer, skal ét af systemerne være det, der gælder, og de andre skal følge det.

klik.villas havde netop det problem. Systemet forbandt reservationer med eksterne kanaler som Booking.com, Agoda og Rentals United, og integrationerne skulle kunne håndtere dataformater og regler for ledighed, der blev ændret i den anden ende. Det er ikke nok at modtage en booking. Systemet skal også hurtigt blokere datoerne alle andre steder og opdage, når en kanal ikke tog imod opdateringen.

Skriv ned, før der bygges:

• Hvor ledigheden redigeres, og af hvem
• Hvilke kanaler der får opdateringer, og hvor hurtigt
• Hvad der sker, når en opdatering fejler eller kommer to gange
• Hvem der løser konflikten, når to reservationer gør krav på de samme datoer

Kalendere, der styres i andre værktøjer, er det svage punkt. Mange af ejendommene i klik.villas delte deres ledighed som iCalendar-feeds, der kun hentes med mellemrum, så mellem to synkroniseringer kunne en dato se ledig ud, selvom den allerede var reserveret et andet sted. Vi fandt også synkroniseringer, der erstattede eksisterende poster i stedet for at flette dem sammen, og indførte en synkroniseringslog og en reservekalender for at kunne spore og rette op. Hvis en kanal tilbyder et rigtigt API, så brug det; er du nødt til at bruge iCal, så synkronisér ofte og log hver ændring.

De tekniske mønstre bag listen, blandt andet idempotens, gentagne forsøg og afstemning, er gennemgået i driftssikre API-integrationer. Beslutningen kommer først: én ejer, skrevet ned.

Depositum, restbetaling og afbestilling hører med til reservationen

En booking er sjældent én betaling. Det kan være et depositum nu, en restbetaling før ankomst, et sikkerhedsdepositum, en refusion efter afbestilling eller en flytning af datoer, der flytter penge fra ét ophold til et andet. Hver af dem er en tilstand, reservationen kan være i, og systemet skal vide, hvilken tilstand den er i.

Beskriv tilstandene i almindeligt sprog, før der vælges værktøjer. For eksempel: forespurgt, bekræftet med depositum, fuldt betalt, afbestilt med refusion, afbestilt uden refusion. Beslut derefter, hvilke hændelser der flytter en booking fra én tilstand til den næste, og hvilke af dem der sker automatisk.

Brug en etableret betalingsudbyder til selve betalingen i stedet for at håndtere kortoplysninger på hjemmesiden. Hjemmesidens opgave er at registrere, hvad udbyderen melder tilbage, og handle pålideligt på det, også når bekræftelsen kommer for sent eller mere end én gang.

Betalingsformen skifter sandsynligvis i løbet af hjemmesidens levetid. På Thailand-villas.com betalte gæsterne i de første år for det meste via bankoverførsel, fordi der var få muligheder for onlinebetaling til den type forretning; efter sammenlægningen med Rentivo i 2016 gik betalingerne over til VacayPay. Hold derfor reservationens tilstande adskilt fra betalingsmetoden, så et skift af udbyder ikke betyder, at bookingforløbet skal bygges om.

Reservationen slutter ikke ved bekræftelsen

Et bookingsystem er også et administrationssystem. Når et ophold eller en aftale er bekræftet, skal nogen forberede den, rapportere på den og bogføre den.

klik.villas opstod netop i det hul. Udlejningsvirksomheder styrede reservationer, lejeindtægter, udgifter, vedligeholdelse og rapportering til ejerne i regneark, hvilket gav dobbeltarbejde og stor risiko for data, der ikke stemte. Systemet samlede opgaverne ét sted, bygget op om den måde villaudlejning faktisk fungerer på, frem for et hotelsystem tilpasset en anden type forretning.

Selv en langt mindre bookinghjemmeside har gavn af at stille de samme spørgsmål tidligt:

• Hvem skal vide besked om en ny booking, og hvordan får de den?
• Hvad skal medarbejderne kunne se på dagen?
• Hvilke tal har ejeren eller revisoren brug for hver måned?
• Hvad bliver stadig kopieret manuelt mellem værktøjer?

Alt, der stadig kopieres manuelt efter lanceringen, er et sted, hvor bookingdata før eller siden kommer til at modsige sig selv.

Bookingsiderne skal kunne findes

En bookingmotor er kun nyttig, hvis de rigtige besøgende når frem til den. På Thailand-villas.com fungerede bookingmotoren ikke som en isoleret funktion: oplysninger om boligerne, indhold om destinationerne, navigation, interne links og selve bookingtrinnet skulle arbejde sammen, fordi hjemmesiden konkurrerede om synlighed med langt større bookingplatforme.

Strukturen skulle også ændres, efterhånden som søgemaskinerne ændrede sig. Efter Googles Panda-opdatering i 2011 holdt vi op med at gentage villaindholdet på destinationssiderne, og senere samlede vi siderne på ét domæne med 301-redirects efter samme fremgangsmåde som i SEO-tjeklisten til migrering af en hjemmeside. En bookinghjemmeside, der lever af søgetrafik, må regne med at tage sidestrukturen op igen, når søgemaskinerne ændrer sig.

Det taler for en fast sidestruktur, så hver ny bolig, ydelse eller lokation bliver tilføjet på samme måde:

• Overblik og vigtigste oplysninger
• Ledighed eller forespørgsel
• Priser eller en ærlig forklaring på, hvordan prisen fastsættes
• Adresse og adgangsforhold
• Vilkår for depositum og afbestilling
• Relaterede boliger, ydelser eller steder
• En kontaktmulighed til de spørgsmål, siden ikke besvarer

En ensartet struktur gør hjemmesiden lettere at udvide og forhindrer, at den langsomt fyldes med tynde, næsten ens sider. De dele af en oversigt, kunden bruger til at indsnævre valget, er beskrevet i søgning og filtrering på hjemmesiden.

Standardværktøj eller specialudviklet bookingmotor

Et hostet bookingværktøj eller et plugin er ofte det rigtige svar. Hvis virksomheden booker tider eller et lille antal enheder, med enkle regler og én salgskanal, vil et godt standardværktøj være billigere og mere driftssikkert end specialudviklet kode.

Specialudvikling bliver relevant, når bookingmodellen ikke passer til værktøjets antagelser: usædvanlige regler for ledighed, flere kanaler, der skal holdes synkroniseret, depositum og rapportering efter virksomhedens egne vilkår, eller bookingdata, der skal videre til administration og rapportering. klik.villas blev bygget, fordi villaudlejning havde brug for sin egen datamodel frem for et tilpasset hotelsystem.

Mellem de to findes der ofte en mellemvej: et hostet bookingsystem til selve reservationen og specialudviklet integration omkring det til hjemmesiden, beskeder og rapportering.

Skriv bookingprocessen ned først

Før du sammenligner værktøjer, så beskriv én rigtig booking fra første kontakt til sidste betaling og månedens rapport, inklusive de besværlige tilfælde: en afbestilling, en flytning af datoer, en betaling der kommer for sent. Den beskrivelse afgør det meste af den tekniske plan.

Hvis du allerede tager imod reservationer, og forløbet føles skrøbeligt, eller du planlægger et og vil have et andet blik på modellen, kan du sende mig processen, som den fungerer i dag.