Watch what a guest does with a guidebook. They open it the evening they book, skim the first page, and close it. They open it in the taxi from the airport, hunting for the door code. They open it on the second morning to find out whether the coffee machine takes pods or ground coffee. They open it on the last night to check whether they are supposed to strip the beds.
Four opens. Maybe six. Every one is a search for a single fact by someone who is tired, or in a hurry, or standing outside in the rain.
The forty-page PDF most hosts send is built for none of those moments. It opens with a welcome letter, a photograph of the living room, and a paragraph about how much the owners love the area. The door code is on page nine. The bin day is not in there at all.
Two Documents Wearing One Cover
A guidebook is two documents that got bound together, and most of the problems with guidebooks come from writing them as if they were one.
The first is operational: door, WiFi, heating, hot water, appliances, parking, bins, noise rules, checkout steps. It is infrastructure. No guest enjoys reading it. They need one line of it available at the exact moment something has gone wrong or is about to.
The second is editorial: where to eat, what is worth the trip, what to skip. It is a point of view. Nobody strictly needs it, and a good one is the difference between a stay and a trip.
They fail for opposite reasons. The operational half fails by being incomplete: it is right about nine things and silent about the tenth, and the tenth is the one that produces a message at 22:40. The bathroom light switch that is outside the bathroom. The hot water that takes ninety seconds to arrive. The bin collection that is Tuesday morning, not Wednesday.
The editorial half fails by being generic. It lists the four restaurants that appear on the first page of any search for the neighbourhood. A guest can produce that list on their phone in eleven seconds. A recommendation they could have found themselves is not a recommendation; it is padding.
Fixing one does nothing for the other. Adding a fifth restaurant does not tell anyone which supermarket is open on Sunday. Writing a better bin section does not make your restaurant list worth reading. Treat them as two jobs.
The Contents List, Ordered by How Often It Is Opened
Order the document by demand, not by narrative. Here is the operational spine, roughly in the order a real guest reaches for it.
| Section | The question it answers | When it gets opened |
|---|---|---|
| WiFi | Network name, password, and what to do when it does not connect | Within ten minutes of arrival, then again on every new device |
| Door and access | Code or key location, the exact entry sequence, what to do when it fails | Before arrival, and standing at the door |
| Checkout | Time, what to do with keys, bins, dishwasher, windows, heating | The final morning, and often the night before |
| Heating, AC and hot water | How to change the temperature, and what the delay is | The first evening, and the first cold or hot night |
| Appliance quirks | The shower, the oven, the induction hob, the washing machine cycle | Day two onwards |
| Parking | Where, whether a permit is needed, and what happens on street-cleaning day | Before arrival if driving, and every time the car moves |
| Bins and recycling | Which bin, where it lives, and which morning it goes out | Mid-stay, and at checkout |
| House rules and noise | What the rules are, the hours, and why they exist | Read once, if at all; referenced when you need to enforce |
| Arrival logistics | Which airport bus, which exit, which entrance of the building | Before arrival, once |
| Local essentials | Supermarket, pharmacy, cash machine, opening hours | Day one, then forgotten |
| Local recommendations | Where to eat tonight, what is worth the trip | The first evening, and whenever plans are unformed |
| Emergency and contact | Who to call, for what, and the local emergency number | Rarely, and urgently |
Two things follow from this ordering. WiFi and the door are not a subsection of a chapter called "Practical Information": they are the first screen, and the WiFi entry needs the failure path as well as the password, which is most of what guests actually ask about the WiFi. And the emergency section is last precisely because it is rare, but it has to be findable in one action rather than by scrolling, because the person looking for it is not in a state to scroll.
The Operational Half Fails by Omission
Every host writes the obvious nine. What follows is the tenth: the omissions that generate messages after a guidebook has been written, sent and considered finished.
Bin day. Not "bins are in the courtyard": which morning, which bin, and whether the guest is expected to do it at all. A guest who leaves a full bin on a Saturday is not being rude; nobody told them the collection was Thursday.
The quirk of the shower. Every property has one. The mixer that has to go past the stiff point before hot water arrives. The second valve behind the screen. The ninety seconds of cold. This single line prevents more messages than any other line in the document.
Which supermarket is open on Sunday. Or the public holiday, or after 20:00. In most of Europe this is the difference between a guest eating dinner and a guest messaging you about it. Name the shop, give the hours, and give the fallback.
What the noise rules are and why. "Quiet hours 22:00 to 08:00" is a rule. "The building's quiet hours are 22:00 to 08:00, the walls are thin, and the neighbour on the other side works early shifts" is a reason, and reasons are what people follow. The stakes for the host are covered in what a noise complaint from a neighbour actually costs you, a licence, usually, long before a review.
The entry sequence, not the entry code. Which street door, whether it needs a firm pull, whether the lift needs a fob, which floor the flat is actually on when the building counts from zero.
The dead spot. If mobile coverage fails in the back bedroom, say so. Guests assume a fault and message about it.
The window or door that sticks. Two lines here prevents a guest forcing something and a maintenance call the following week.
What is not there. No dishwasher, no oven, no air conditioning, one towel per guest. A gap the guest discovers themselves reads as a failure. A gap they were told about reads as a fact.
Test the operational half the way you would test a runbook: not by reading it, but by asking whether each of the last ten guest messages is answered by one line of it. If a message did not have an answer in the document, the answer goes in the document. That feedback loop is the whole method behind a house manual that reduces guest messages instead of adding to them, and the guidebook is the same discipline in a guest-facing coat.
The Editorial Half Fails by Being Generic
The test for a recommendation is simple: could the guest have found it without you, in under a minute, on their phone? If yes, it costs you credibility to include it, because the guest now reads your whole list as search results with a personal touch.
What survives the test tends to be one of four things. The place that is good but invisible: no frontage, no reviews in English, the one you send friends to. The specific order: not "great tapas", but which three dishes, and that they stop serving the good one after 21:00. The timing: the market that is worth it on Saturday and pointless on Tuesday, the viewpoint that is unbearable at noon. And the negative recommendation: the famous thing that is not worth the queue, the street where every terrace is a tourist trap. Guests remember the negative ones most, because nobody else is willing to make them.
Write in the first person and commit. "We eat here most Fridays; ask for the back room" outperforms a paragraph of adjectives. Four or five places you genuinely stand behind beat thirty you assembled once.
This is also the half with an economic argument behind it, because a recommendation a guest acts on is a recommendation a local business can see and value: the structure for that is in the guidebook as an untapped revenue stream, and the wider model in how hosts earn referral income from local recommendations. None of it works if the list is the same list as everyone else's, because nothing in it is attributable to you.
What to Cut
The welcome letter. One sentence at the top, not a page. Warmth belongs in your messages, where it is read.
Photographs of the property. The guest is standing in it.
The history of the neighbourhood. If a guest wants this, they have the internet.
The full list of every attraction in the city. The tourist board does it better.
Anything you cannot keep current. A restaurant that closed two years ago damages every other entry on the page. If you cannot maintain a section, cut it: an out-of-date line is worse than a missing one, because the guest acts on it.
Rules stated three times. Once, with the reason, in the place a guest would look.
A guidebook that has been cut well is short enough that the operational spine fits on two screens, and the editorial half reads like a person wrote it in an afternoon because they cared.
A Reference Is Not a Response
Here is the limit that no amount of good writing gets past: a guidebook is a reference, and a guest with a problem at 23:00 does not read references.
At 23:00 the guest does not search a PDF for "hot water". They type "the shower is cold" into whatever channel they already have open, which is the one they used to arrange check-in. The guidebook can be perfect and still be bypassed, because the question is arriving as a conversation, not as a lookup.
The usual response is to write the answer twice: once in the guidebook, once in a set of canned replies or an assistant's knowledge base. That is where the drift starts. The lockbox code changes in March. It gets updated in the messaging templates because that is where it is used daily, and not in the PDF, because nobody opens the PDF. Six weeks later a guest reads the old code, tries it four times, and messages you at midnight from the street.
The design that holds is one body of knowledge with two surfaces: the same facts rendered as a browsable document for the guest who wants to look something up, and as answers for the guest who asks in a message. One place to edit. The question that got asked and was not covered goes back into the same source, so the document gets better every time it fails.
That is the real argument for the guidebook and the messaging layer being the same system rather than two copies maintained by the same tired person.
What a Guidebook Will Not Fix
Be sceptical of the claim that a better guidebook reduces guest messages to near zero. It does not, and the reasons are structural.
Most guests will not read it. They will read the four lines they need and never see the rest. Sections you are proud of will go unopened for a year. That is not a failure of writing; it is what a reference document is for.
A guidebook cannot make a decision. "Can we check out at 13:00?" is not a documentation problem. It depends on the next booking and the cleaner's route, and someone or something with access to both has to answer it.
A guidebook cannot troubleshoot. It can hold the three most likely fixes for a cold shower. It cannot ask which one the guest already tried, and it cannot notice that the answer stopped working after the boiler was replaced.
Translation is not neutral. A guidebook auto-translated into eight languages will be right about the door code and subtly wrong about the shower, because the sentence that made the quirk clear was the one carrying the idiom. Have the operational lines checked by a speaker for the languages your guests actually arrive in.
A guidebook gets stale silently. There is no error message when a restaurant closes or a bus route moves. The only reliable maintenance signal is the guest question it should have answered and did not, which means you have to be capturing those questions somewhere.
And about Welco specifically: it generates a guidebook as a web link and a PDF in the guest's language, and it answers guest questions from the same loaded knowledge, but it does not know your bin day, your shower quirk or your Sunday supermarket until you put them in. The document is only as good as what you load, and no tool gets you out of the hour it takes to write the tenth thing down. Welco also stops at the conversation: it is not a lock, a channel manager or a cleaning scheduler, and it will not fix a property where the real problem is that the hot water does not work.
The Operational Picture
Split the document in two before you write a word of it. The operational half is judged on whether it is complete, so test it against your last ten guest messages. The editorial half is judged on whether a guest could have found it without you, so cut anything that fails that test and commit to what is left.
Welco is a WhatsApp AI assistant for vacation rental hosts: it answers verified guests from the house rules, check-in steps, appliance notes and local recommendations you load, in 30+ languages, and it generates the guidebook from that same source, so the document a guest browses and the answer a guest gets at 23:00 come from one place rather than two copies drifting apart. Questions it could not answer are saved once you answer them, which is the maintenance loop most guidebooks never get. Access today is by demo request, if you want to see what that looks like against your own property.