Wie plant dag drie?

Bekijk de vorm van een verblijf van vijf nachten vanaf de plek waar jouw software zit.

De boeking. De bevestiging. Het bericht voor aankomst. Het registratieformulier, het paspoort, de handtekening, de aankomst zelf. En dan, helemaal aan de andere kant, het vertrek, de factuur, het verzoek om een review. Aan beide uiteinden is het druk. Voor elk van die momenten bestaat een leverancier, en de meeste accommodaties betalen er twee.

Kijk nu naar het midden. Dinsdag, woensdag, donderdag.

Dat is het grootste deel van het verblijf. Het is het deel dat je gast thuis aan anderen beschrijft. En vrijwel niemand in deze branche schrijft erover, laat staan dat er iets voor gebouwd wordt.

Wie plant dag drie?

Dag drie heeft geen eigenaar. Het is nadat de aankomstflow zichzelf heeft gefeliciteerd en ruim voordat iemand om een review vraagt. Er staat niets gepland. En precies daarom gebeurt er van alles.

Op dag drie wil een gast vier kleine dingen, en het zijn altijd dezelfde vier. Wat er vandaag is. Hoe laat het begint. De code voor iets. Eén goed restaurant.

Die vier vragen komen bij jouw balie binnen. Telefonisch, aan de balie, in een WhatsApp-gesprek om 21:00, en morgenochtend opnieuw van de gast uit de kamer ernaast. Je team beantwoordt ze, correct en geduldig, een paar honderd keer per seizoen. Dat is geen softwareprobleem in de zin dat software de vragen laat verdwijnen. Het is een softwareprobleem in de zin dat de antwoorden al bestaan en niemand ze heeft neergelegd waar de gast kijkt.

Eén lijst, drie keer bijgehouden

Dit is wat het midden van het verblijf echt oplevert, en het is veel simpeler dan het lijkt.

Een verblijf levert één lijst op. Wat deze gast heeft geboekt, op welke dag, hoe laat, en wat hij erbij heeft gevraagd. Twee keer ontbijt op dinsdag. De boot om 09:00 op donderdag. Late checkout op zondag. Lactose-intolerant.

De meeste accommodaties houden die lijst drie keer bij.

De gast heeft een versie, ergens tussen een bevestigingsmail en zijn eigen geheugen in. De receptie heeft een versie, in het reserveringsscherm. En degene die het ontbijt draait heeft een derde versie, met de hand geschreven of gistermiddag uitgeprint, omdat geen van de eerste twee de vorm van een dienst heeft.

Drie kopieën van één lijst zijn drie kansen om het mis te hebben. En die op papier is altijd de meest actuele, wat alles zegt over hoe bruikbaar de eerste twee waren.

De interessante vraag voor een softwarebedrijf is niet hoe je een mooiere versie van één van die drie maakt. Het is of je ermee wegkomt om er maar één bij te houden.

Wat de gast opent

Het reisschema is die lijst, samengesteld per gast en per dag. In het product zijn de eenheden itinerary items, en een item is één van vier dingen: een Experience, een Amenity, een Guidebook of een agenda-item. Het staat op een specifieke dag, op een specifieke dag en tijd, of op het hele verblijf.

De gast opent het op jouw eigen domein, vanuit een link op het kanaal dat hij toch al gebruikt. Er valt niets te installeren.

Het laat zien wat er geboekt is, wat er vandaag is en wat er daarna komt, met de antwoorden uit de reisgidsen eronder: huisregels, hoe de apparaten werken, de buurt. Dat zijn de antwoorden die de receptie de hele dag herhaalt.

Het past zich aan op gast, verblijfsdag en taal. Dat is de hele personalisatie, en we zeggen dat liever hardop dan dat we het woord werk laten doen dat het niet verdiend heeft. Een Nederlands gezin op nacht vier en een Spaans stel op nacht één zien niet hetzelfde scherm, omdat de dag en de taal verschillen. Volgorde, timing en taal passen zich aan. Er wordt niets gescoord over de gast. Er wordt niets voorspeld. Het draait in 100+ talen.

Gebruiken gasten een hotel-app eigenlijk wel?

Dit is het eerlijke tegenargument en het verdient een echt antwoord in plaats van een slide.

Gasten gebruiken geen hotel-app die vraagt om een download, een account en een wachtwoord, en daarna een pdf met de ontbijttijden laat zien. Dat is geen scepsis over gasten. Dat is een correcte inschatting van een slechte ruil: vijf dagen gebruik in ruil voor zoeken in een store, installeren en weer verwijderen.

Gebruik ontstaat door één ding. De snelste route zijn naar wat de gast binnen tien minuten wil. De deurcode. De ontbijttijd. Het plan voor vanavond.

LabNul50 heeft zijn 24/7 telefonische concierge precies op dat gedrag opgeheven, en 25.000+ deuren die gasten zelf openden zijn het bewijs dat een gast iets wél opent als dat de kortste weg is naar wat hij nodig heeft. Niemand opende het uit loyaliteit. Ze openden het omdat het alternatief was het nummer opzoeken.

Waar de lijst vandaan komt, zonder dat iemand hem typt

Een lijst die iemand met de hand moet bijhouden, klopt woensdag al niet meer. Daarom wordt het reisschema samengesteld in plaats van geschreven.

Uit de bestellingen van de gast zelf. Zodra de bestelling van een gast is bevestigd, worden de items eruit aangemaakt met het bestelde aantal erbij. Twee keer ontbijt is twee. Een gevulde koelkast met vier bier, vijf cola en drie zakken chips is twaalf. Alles met een prijs per dag verdeelt zich over de dagen van het verblijf; alles met een prijs per nacht krijgt de datum van de ochtend erna, precies zoals het scherm van de gast het ook noemt. Vier nachten ontbijt zijn vier items op vier ochtenden, en niet één regel op de dag waarop je het goedkeurde. Annuleert een gast, dan wordt elk item dat die bestelling heeft aangemaakt mee geannuleerd.

Uit je propertysysteem. Zit er ontbijt, diner, halfpension of een arrangement in je tarief, dan kunnen die add-ons rechtstreeks vanuit het systeem van record op het reisschema van de gast landen. Je kiest zelf welke meesynchroniseren en waar ze terechtkomen: elke ochtend, elke nacht, of op de dag van aankomst. Haal je de add-on van het tarief, dan verdwijnt hij van het reisschema. Dit is vandaag live voor Cloudbeds en StayNTouch, met een nachtelijke controle die ook komende reserveringen bijwerkt en niet alleen de nieuwe.

Van je eigen team. Een medewerker voegt met de hand een item toe waar dat nodig is, en elk item draagt een zichtbaarheid: extern of intern. Externe items zijn van de gast. Interne items zijn van jou, komen nooit op het scherm van de gast, en worden ook voor de AI-assistent weggefilterd, die dezelfde regel toepast en niet een tweede.

Je boeking blijft in je propertysysteem. Dat blijft het systeem van record. Wij lezen eruit en schrijven de lijst van de gast.

De dienst: één dag, elke kamer

De tweede weergave is degene die je dienstdoend manager open laat staan.

Het dagbord is één dag over de hele accommodatie. Elke kamer met een gast erin is een regel. Elke regel zet de items met een tijd van die reservering als blokken langs de werkdag, met de items die de hele dag gelden ernaast vastgezet. Ga een dag vooruit of achteruit en lees de accommodatie zoals die er echt uit gaat zien.

Je filtert met woorden uit de hotellerie en niet uit de software: aankomsten, doorblijvers, vertrekken, elk met een teller van hoeveel regels erbij horen, en alle drie standaard aan zodat het bord compleet is totdat je het zelf versmalt. Filter verder op status van het item, op soort item, of op het wel of niet tonen van interne items. Het filteren gebeurt op het bord dat je al open hebt, dus er laadt niets opnieuw. Klik op een regel op een tijdstip en je bent een item aan het toevoegen op dat tijdstip, met de tijd al ingevuld.

Twee details die het waard zijn om te weten, omdat ze bij de versie van iedereen misgaan. Het daagtype wordt afgeleid in de eigen tijdzone van elke kamer, zodat een late avondaankomst op de juiste borddag belandt en niet op die van gisteren. En een boeking van dezelfde dag telt zowel als aankomst als als vertrek, zodat hij bij beide filters overleeft in plaats van ertussendoor te vallen.

Wat het niet is: het is geen takenmodule en het wijst geen werk toe aan iemand. Het laat het verblijf zien. Wie wat doet, is een ander stuk product en een ander gesprek.

De vloer: één item, elke gast

De derde weergave is degene die het papier vervangt.

Een manifest is de lijst van iedereen die één bepaald item op één bepaalde dag heeft geboekt. De branche heeft daar al een woord voor, dus gebruiken we dat woord in plaats van er een te verzinnen.

Kies ontbijt, kies morgen, en je hebt hem: elke gast die het besteld heeft, de kamer, het aantal couverts, wat ze erbij hebben gevraagd, en de notitie die ze hebben achtergelaten. Bestellingen én couverts staan erop, want achttien bestellingen kunnen zesendertig couverts zijn en de keuken heeft dat tweede getal nodig, niet het eerste. De opties staan bovenaan uitgesplitst, zodat een dienst weet hoeveel er van elk zijn voordat die begint.

Vink elke regel af zodra hij de deur uit gaat. De vinkjes zijn gedeeld, dus twee mensen die dezelfde dienst draaien zien dezelfde lijst, en elk vinkje legt vast wie het zette en wanneer. Nieuwe bestellingen voor die dag verschijnen zodra gasten ze plaatsen. Annuleringen vallen eraf. Aan het eind van de dag sluit het en houdt het de vinkjes die het had.

En wil de vloer liever papier, print het dan als A4 met een vinkvakje per regel.

Drie weergaven, één dataset

Dit is het deel dat een eigenschap van het datamodel is en geen feature, en daarom is het precies het deel dat het waard is om over te praten.

Dit zijn geen drie producten met drie databases. Het dagbord is één dag over elke kamer, gegroepeerd per reservering. Een manifest is dezelfde dag en dezelfde query, negentig graden gedraaid: één item, over elke gast. Het scherm van de gast is diezelfde data een derde keer, gefilterd op één reservering en op de items die als extern gemarkeerd staan.

Een manifest is bovendien een definitie en geen momentopname. Het slaat alleen op welk item het is, welke dag, en hoe het gesorteerd wordt. De regels worden live opgehaald elke keer dat iemand het opent, en ze worden nooit opgeslagen. Daarom verschijnen bestellingen die na het aanmaken binnenkomen er wél op en vallen annuleringen eraf, zonder dat er iets opnieuw gegenereerd wordt. Er wordt niets opnieuw gegenereerd omdat er nooit iets gegenereerd is.

Verander het onderliggende item en alle drie de weergaven kloppen al, want er valt niets te exporteren, niets te synchroniseren en niets bij te werken. Het geprinte vel achter in huis komt uit dezelfde regel die de gast op zijn telefoon leest.

De beperkingen, hardop

Vier stuks, want je komt er in de tweede week toch achter en het is beter dat je ze nu hoort.

Live betekent elke vijftien seconden verversen. Een manifest haalt op; het wordt niet gepusht. We gaan het geen realtime noemen. Voor een ontbijtdienst is vijftien seconden het juiste antwoord, en een push-versie is een latere beslissing en geen geheim.

Een geprint vel is een momentopname van het moment waarop je het printte. Bestellingen die daarna binnenkomen staan er niet op. Het vel zegt dat zelf, in plaats van het iemand tijdens de dienst te laten ontdekken.

De AI leest het reisschema. De AI schrijft er niet in. Een gast kan vragen wat er morgen gepland staat, hoe laat de boottocht begint, wat hij heeft opgeslagen, of de spa-afspraak bevestigd is, en het antwoord komt uit de echte lijst, inclusief een expliciete "er staat nog niets gepland" als er niets staat, zodat er geen dag verzonnen wordt. De AI voegt niets toe, haalt niets weg, verzet niets en slaat niets op namens een gast. Dat is een beslissing die we nog niet genomen hebben, en geen feature waar we geheimzinnig over doen.

De daggrens is niet in alle drie de weergaven gelijk. Het scherm van de gast en het dagbord bepalen een dag in de eigen tijdzone van de kamer, want dat is de dag die de gast beleeft. Een manifest bepaalt hem in de tijdzone van je workspace, want één manifest kan meerdere kamers beslaan. Heb je één accommodatie, dan merk je het nooit. Heb je er meerdere over de grens, dan weet je nu welke welke is.

Er zijn ook dingen die bewust nog niet gebouwd zijn: geen knop om alles in één keer af te vinken, geen CSV-export, geen sjablonen of herhaling voor manifests, en geen capaciteitslimiet op een dienst. Elk daarvan is overwogen en uit de eerste versie gelaten.

De aanbevelingen zijn niet te koop

Nog één ding, en het is een redactionele beslissing en geen technische.

De lokale aanbevelingen naast het reisschema zijn degene die jij hebt gekozen. Wij pakken er geen commissie op, er zit geen betaalde plaatsing in die lijst, en er is geen manier waarop een restaurant zich op het scherm van jouw gast kan inkopen. Die gaat er ook niet komen.

Dat is een commercieel argument en geen moreel. Een lijst die te koop is, draagt geen informatie in zijn volgorde, dus hij is voor een gast niets waard. En komt een gast terug van een tegenvallende plek, dan geeft hij niet de lijst de schuld. Hij geeft de accommodatie de schuld die hem erheen stuurde. Jij draagt de reputatieschade van een aanbeveling die je niet hebt gedaan en waar je niet voor betaald bent.

Jij bent degene die weet welke van de twee tenten op dat plein de goede is. Die kennis is het product, en die is van jou.

Iedereen claimt de aankomst

Aan beide uiteinden van het verblijf is het druk, omdat beide uiteinden makkelijk te zien zijn. Een boeking is een gebeurtenis. Een aankomst is een gebeurtenis. Een verzoek om een review is een taak met een datum.

Het midden is geen gebeurtenis. Het zijn drie dagen met kleine, steeds terugkerende vragen waar gewoon een antwoord op is, en daar wordt je reputatie echt gemaakt.

Eén lijst. De gast leest hem, de dienst werkt hem af, de vloer vinkt hem af. Niemand typt iets over.

Wat er bovenop die lijst komt, en wat je doet met de momenten die hij openlegt, is voor de volgende keer.

Beide nieuwe schermen staan stap voor stap in de handleiding, inclusief de rechten die ervoor nodig zijn en wat het geprinte vel wel en niet meeneemt: het dagbord en manifests. De handleiding is in het Engels.

Bekijk het reisschema, het dagbord en manifests, of lees hoe het kader eromheen is gebouwd in The Guided Stay. HolidayHero draait op het propertysysteem dat je al hebt, bij 3.500+ accommodaties van losse villa's tot de 250+ chalets van OVO Network. De prijzen zijn gepubliceerd, vanaf €6,50 per unit per maand zonder opstartkosten.