Slik bygger du et nettsted for hotellbestilling: rom, priser, tilgjengelighet og betalinger

Et nettsted for hotellbestilling lar gjester velge datoer, se hvilke rom som er ledige for hver natt i oppholdet, se totalprisen, og betale eller legge inn et depositum – uten at noen sender e-post frem og tilbake. For å bygge et trenger du romtyper med antall rom, en modell for tilgjengelighet per natt, priser som kan endre seg etter dato, en bestillingsflyt som sjekker tilgjengeligheten på nytt når den lagrer, og en adminvisning for resepsjonen. Det vanskelige er ikke de pene sidene. Det er å sørge for at et rom aldri selges to ganger, særlig hvis du også selger på bookingplattformer.

Hva nettstedet trenger

Sider

• Offentlig: hjem, rom (bilder, senger, størrelse, fasiliteter, maks gjester), et søk på dato og gjester, resultater med totalpris per romtype, et bestillingsskjema, betaling og en bekreftelsesside med en lenke for å administrere bestillingen.
• Støttesider: beliggenhet og veibeskrivelse, retningslinjer (innsjekkingstider, avbestilling, barn, kjæledyr), vanlige spørsmål, kontakt.
• Privat (ansatte): ankomster og avreiser for i dag, en kalenderoversikt over rom natt for natt, bestillingsliste, blokkerte datoer, priser og romoppsett.

Data

Lagre innsjekking og utsjekking som datoer, ikke klokkeslett, og behandle utsjekking som eksklusiv: et opphold fra den 10. til den 12. bruker nettene til den 10. og 11. Hvis dette blir feil, oppstår den vanligste tilgjengelighetsfeilen.

Tilganger

Gjester ser priser og om en romtype er ledig – aldri hvem andre som bor der. Resepsjonsansatte ser bestillinger og gjesteopplysninger; bare eieren endrer priser og retningslinjer. Det krever en ansattinnlogging med minst to roller.

Valg og avveininger

Be om bestilling eller direktebestilling

Be om bestilling – gjesten sender datoer og opplysninger, du bekrefter på e-post – er langt enklere og fungerer fint for et lite gjestehus. Direktebestilling krever helt sikker tilgjengelighet og betalingshåndtering, men konverterer bedre. Mange eiendommer starter med forespørsler og bytter senere.

Selg romtyper eller bestemte rom

Gjester bestiller vanligvis en romtype («dobbeltrom med havutsikt»), og de ansatte tildeler det faktiske rommet senere. Å selge bestemte rom er enklere å bygge, men gjør kalenderen vanskeligere å fylle.

Priser

Start med én pris per romtype per natt, med valgfrie unntak for datointervaller (høysesong, helligdager) og et minimumsopphold. La dynamisk prising, rabattkoder og pakker vente.

Betaling

Alternativer, i stigende kompleksitet: betaling ved ankomst; et depositum via en ferdig betalingsside, for eksempel Stripe Checkout; full forhåndsbetaling for en ikke-refunderbar pris; eller å lagre et kort for senere belastning. Betalingsregler, avgifter og turistavgifter varierer fra land til land – sjekk lokale regler eller spør en rådgiver. Veiledningen om betalinger dekker mekanikken.

Andre kanaler

Hvis rom også er annonsert på reisebyråer på nett eller plattformer for utleie av feriehjem, må du holde kalendere i takt. Mange av disse plattformene kan eksportere og importere kalendere som iCal-lenker; å synkronisere på den måten er vanlig for små eiendommer, men det skjer med en forsinkelse, ikke øyeblikkelig. En kanalhåndterer er det profesjonelle svaret.

En første prompt som fungerer

Bygg et nettsted for direktebestilling for Harbour House, et gjestehus med 9 rom i Tobermory, Skottland. Romtyper: Dobbeltrom (4 rom, 2 gjester, £120/natt), Tvillingrom (3 rom, 2 gjester, £115), Familierom (2 rom, 2 voksne + 2 barn, £165). Gjester søker på innsjekkingsdato, utsjekkingsdato og antall gjester, og ser bare romtyper med et ledig rom for hver natt i oppholdet, med totalpris. Utsjekking er eksklusiv. Minimumsopphold 2 netter i juli og august. Bestillingsskjemaet samler inn navn, e-post, telefon og ankomsttidspunkt; lagre det som «ventende» og sjekk tilgjengeligheten på nytt på serveren før lagring. Ansattområde med innlogging: dagens ankomster og avreiser, en kalenderoversikt over rom natt for natt, bestillingsliste med status, og en måte å blokkere datoer på. Vis innsjekking 15–20, utsjekking 10 og avbestillingsreglene (gratis til 7 dager før) på hver bestillingsside. Rolig kystdesign, mobilfokusert.

Byggetrinn

1. Modeller rom og netter først. Romtyper, rom, priser og tilgjengelighetssjekken. Test den før noe designarbeid.
2. Søk og resultater. Datovelger, antall gjester, totalpris for oppholdet, tydelige «utsolgt»-tilstander.
3. Bestillingsflyt. Skjema → ny tilgjengelighetssjekk på serveren → ventende bestilling → bekreftelsesside med en administrasjonslenke.
4. Ansattområde med innlogging: ankomster, avreiser, kalenderoversikt, blokkering av datoer.
5. E-postbekreftelse via din egen leverandør, med datoer, totalsum, adresse og regler. Se sende e-post.
6. Depositum i Stripes testmodus, og bekreft bestillingen bare når betalingen går gjennom. En betalingswebhook krever at appen din er publisert på en offentlig adresse.
7. Kalendersynkronisering med andre kanaler hvis du bruker dem, pluss en daglig manuell kontroll i starten.
8. Test kanttilfellene: to nettleservinduer som booker det siste rommet, et opphold som krysser en prisendring, en avbestilling som frigjør netter, enkeltnetter i en periode med minimumsopphold.
9. Publiser og gjør en ekte bestilling selv før du slutter med den gamle prosessen.

Vanlige feil

• Å sjekke tilgjengelighet bare i nettleseren. To gjester vil til slutt booke det siste rommet samtidig.
• Å telle utsjekkingsnatten som opptatt (eller ikke telle innsjekkingsnatten). Skriv en test for et opphold på to netter.
• Én flat pris. De fleste eiendommer trenger i det minste sesongbaserte unntak.
• Å skjule totalsummen til siste steg. Vis hele prisen for oppholdet, inkludert gebyrer du kjenner til, i resultatene.
• Retningslinjer gjemt i bunnteksten. Vis avbestillingsvilkårene ved siden av betalingsknappen.
• Å behandle iCal-synkronisering som øyeblikkelig. Det er den ikke; steng datoer for hånd når du er nesten fullbooket.

Når et ferdig produkt er det bedre valget

Hvis du driver mer enn en håndfull rom, selger gjennom flere reisebyråer på nett, eller trenger housekeeping, fakturering og rapportering, er et eiendomsadministrasjonssystem med innebygd bestillingsmotor og kanalhåndterer vanligvis det riktige valget. Disse produktene finnes for å løse dobbeltbooking på tvers av kanaler, og det er dyrt å gjenskape godt.

Et eget nettsted gir mening for små eiendommer som for det meste tar direktebestillinger, for uvanlig varelager (glamping-plasser, hytter med felles fasiliteter, rom solgt med aktiviteter), eller når du vil ha din egen design og gjesteopplevelse uten en månedlig avgift per rom. Noen eiere kombinerer et eget nettsted med en hostet bestillingsmotor innbygd på det – ofte det beste fra begge verdener.

Bygge det med Mythex

På Mythex beskriver du eiendommen i chatten, går gjennom nettstedet i en levende forhåndsvisning (også i telefonstørrelse), og publiserer når det fungerer. Bestillinger, rom og priser ligger i en Postgres-database som agenten legger til når appen må lagre data; den sover når den er inaktiv og våkner ved neste forespørsel. Ansattinnlogging, e-postbekreftelser og depositum er koblet til dine egne leverandører og nøkler – Mythex har ingen innebygd innlogging, e-post eller betalingsprodukt for sluttbrukere – så les Stripe-oppskriften før du legger til depositum. Bruk /test for å la agenten gå gjennom søk og bestilling, og sjekkpunkter for å rulle tilbake en endring som ødelegger tilgjengeligheten.

Som startprompt, se bygger for hotellbestilling, bygger for bestilling på gjestehus eller malen for glamping-bestillingsside. For timebasert eller avtalebasert booking i stedet for netter, se veiledningen for bookingapper.

Spørsmål