Sådan bygger du en hjemmeside til hotelbooking: værelser, priser, tilgængelighed og betalinger

En hjemmeside til hotelbooking lader gæster vælge datoer, se hvilke værelser der er ledige for hver nat af deres ophold, se den samlede pris og betale eller stille et depositum — uden at nogen skal sende e-mails frem og tilbage. For at bygge en sådan skal du have værelsestyper med et antal værelser, en model for tilgængelighed pr. nat, priser der kan ændre sig efter dato, et bookingflow, der kontrollerer tilgængeligheden igen, når det gemmes, og en administrationsvisning til receptionen. Det svære er ikke de flotte sider. Det er at sikre, at et værelse aldrig sælges to gange, især hvis du også sælger via bookingplatforme.

Hvad siden skal kunne

Sider

• Offentlig: forside, værelser (fotos, senge, størrelse, faciliteter, maks. antal gæster), en søgning på datoer og gæster, resultater med samlet pris pr. værelsestype, en bookingformular, betaling og en bekræftelsesside med et link til at administrere bookingen.
• Støttende: placering og vejvisning, politikker (check-in-tider, annullering, børn, kæledyr), ofte stillede spørgsmål, kontakt.
• Privat (personale): dagens ankomster og afrejser, et kalendergitter over værelser pr. nat, bookingliste, blokerede datoer, priser og værelsesindstillinger.

Data

Gem check-in og check-out som datoer, ikke tidspunkter, og behandl check-out som eksklusiv: Et ophold fra den 10. til den 12. bruger nætterne for den 10. og 11. At få dette forkert er den hyppigste fejl i tilgængeligheden.

Rettigheder

Gæster ser priser og om en værelsestype er ledig — aldrig hvem andre der bor der. Receptionspersonale ser bookinger og gæstedetaljer; kun ejeren ændrer priser og politikker. Det kræver et personalelogin med mindst to roller.

Beslutninger og afvejninger

Anmod om booking eller øjeblikkelig booking

Anmod om booking — gæsten sender datoer og oplysninger, og du bekræfter via e-mail — er langt enklere og fint til et lille gæstehus. Øjeblikkelig booking kræver tæt tilgængelighed og betalingshåndtering, men konverterer bedre. Mange ejendomme starter med anmodninger og skifter senere.

Sælg værelsestyper eller bestemte værelser

Gæster booker typisk en værelsetype ("Dobbeltværelse med havudsigt"), og personalet tildeler det egentlige værelse senere. At sælge bestemte værelser er enklere at bygge, men gør det sværere at fylde kalenderen.

Priser

Start med én pris pr. værelsestype pr. nat, med valgfrie tilsidesættelser for datointervaller (højsæson, helligdage) og et mindste ophold. Lad dynamisk prissætning, rabatkoder og pakker vente.

Betalinger

Muligheder, i stigende rækkefølge af kompleksitet: betal ved ankomst; et depositum via et hostet betalingsvindue som Stripe Checkout; fuld forudbetaling for en pris uden refusion; eller at gemme et kort til senere opkrævning. Betalingsregler, moms og turistafgifter varierer fra land til land — tjek de lokale regler eller spørg en rådgiver. Vores betalingsguide dækker mekanikken.

Andre kanaler

Hvis værelser også er opført på online rejsebureauer eller platforme for feriebolig, skal du holde kalenderne i takt. Mange af disse platforme kan eksportere og importere kalendere som iCal-links; synkronisering på den måde er almindelig for små ejendomme, men sker med forsinkelse, ikke øjeblikkeligt. En channel manager er det professionelle svar.

En første prompt, der virker

Byg en side til direkte booking for Harbour House, et gæstehus med 9 værelser i Tobermory, Skotland. Værelsestyper: Dobbeltværelse (4 værelser, 2 gæster, £120/nat), Tosengsværelse (3 værelser, 2 gæster, £115), Familieværelse (2 værelser, 2 voksne + 2 børn, £165). Gæster søger efter check-in-dato, check-out-dato og antal gæster og ser kun værelsestyper med et ledigt værelse for hver nat af opholdet, med samlet pris. Check-out er eksklusiv. Mindste ophold 2 nætter i juli og august. Bookingformularen indsamler navn, e-mail, telefon og ankomsttidspunkt; gem den som "afventer", og kontrollér tilgængeligheden igen på serveren, før den gemmes. Personaleområde med login: dagens ankomster og afrejser, et kalendergitter over værelser pr. nat, bookingliste med status og en måde at blokere datoer på. Vis check-in kl. 15–20, check-out kl. 10 og annulleringspolitikken (gratis indtil 7 dage før) på hver bookingside. Rolig kystdesign, mobilfirst.

Byggetrin

1. Modellér værelser og nætter først. Værelsestyper, værelser, priser og tilgængelighedstjekket. Test det, før der laves noget design.
2. Søgning og resultater. Datovælger, antal gæster, samlet pris for opholdet, tydelige "udsolgt"-tilstande.
3. Bookingflow. Formular → kontrol af tilgængelighed på serveren → afventende booking → bekræftelsesside med et administrationslink.
4. Personaleområde med login: ankomster, afrejser, kalendergitter, blokering af datoer.
5. Bekræftelse pr. e-mail via din egen udbyder, med datoer, total, adresse og politik. Se afsendelse af e-mails.
6. Depositum i Stripes testtilstand, og bekræft kun bookingen, når betalingen lykkes. En betalings-webhook kræver, at din app er publiceret på en offentlig URL.
7. Kalendersynkronisering med andre kanaler, hvis du bruger dem, plus en daglig manuel kontrol i starten.
8. Test kanttilfældene: to browsere, der booker det sidste værelse, et ophold der krydser en prisændring, en annullering der frigør nætter, enkeltnætter i en periode med mindste ophold.
9. Publicér og foretag selv en rigtig booking, før du slukker din gamle proces.

Almindelige fejl

• At tjekke tilgængelighed kun i browseren. To gæster vil før eller siden booke det sidste værelse på samme tid.
• At tælle check-out-natten som optaget (eller ikke tælle check-in-natten). Skriv en test for et ophold på to nætter.
• Én flad pris. De fleste ejendomme har brug for mindst sæsonbaserede tilsidesættelser.
• At skjule totalen indtil det sidste trin. Vis den fulde pris for opholdet, inklusive gebyrer du kender til, i resultaterne.
• Politikker gemt i sidefoden. Vis annulleringsvilkårene ved siden af betalingsknappen.
• At behandle iCal-synkronisering som øjeblikkelig. Det er den ikke; luk datoer manuelt, når du næsten er fuld.

Hvornår et færdigt produkt er det bedre valg

Hvis du driver mere end en håndfuld værelser, sælger via flere online rejsebureauer eller har brug for husholdning, fakturering og rapportering, er et ejendomsadministrationssystem med indbygget bookingmotor og channel manager som regel det rigtige valg. Disse produkter findes for at løse overbooking på tværs af kanaler, og det er dyrt at reproducere godt.

En brugerdefineret side giver mening for små ejendomme, der mest tager direkte bookinger, for usædvanligt udbud (glamping-pladser, hytter med fælles faciliteter, værelser solgt med aktiviteter), eller når du vil have dit eget design og din egen gæsteoplevelse uden et månedligt gebyr pr. værelse. Nogle ejere kombinerer en brugerdefineret hjemmeside med en hostet bookingmotor indlejret på den — ofte det bedste af begge dele.

Byg det med Mythex

På Mythex beskriver du ejendommen i chatten, gennemgår siden i en live-forhåndsvisning (inklusive en ramme i telefonstørrelse), og publicerer, når den virker. Bookinger, værelser og priser ligger i en Postgres-database, som agenten tilføjer, når appen skal gemme data; den sover, når den er inaktiv, og vågner ved næste forespørgsel. Personalelogin, e-mailbekræftelser og depositummer er koblet til dine egne udbydere og nøgler — Mythex har ingen indbygget løsning til slutbrugerlogin, e-mail eller betalinger — så læs Stripe-opskriften, før du tilføjer depositum. Brug /test, så agenten gennemgår søgning og booking, og checkpoints til at rulle en ændring tilbage, der ødelægger tilgængeligheden.

Som startprompt kan du kigge på bygger til hotelbookingsystem, bygger til gæstehusbookingsystem eller skabelonen glamping-bookingside. Til bookinger pr. time eller tid i stedet for nætter, se guiden til bookingapps.

Spørgsmål