Writing an SOP a machine can retrieve.

Lede

Every hotel already has its procedures written down. That is not the problem. The problem is that the writing was done for an auditor, and the reading has to be done by someone holding a stack of towels.

The binder that nobody opens

The binder is real. It is usually in the housekeeping office, sometimes in a shared drive, occasionally in both, in which case the two versions disagree. It was written properly, by someone competent, often as part of a brand standard or an ownership change. It covers the work. And it is, for practical purposes, inert.

You can test this in any property in the time it takes to walk a corridor. Ask a supervisor a question the binder answers — what to do when a guest leaves prescription medication in a checked-out room, say — and watch where they go for the answer. They will not go to the binder. They will answer from memory, or ask a colleague, or ask a group chat. If they are new and have none of those, they will guess, and the guess will be reasonable and possibly wrong.

None of this is a failure of discipline. It is a failure of shape. The procedures exist as a document, and the work exists as a series of interruptions, and a document cannot be consulted during an interruption.

The three ways it fails

It is not where the work is. Housekeeping happens on a floor, in a corridor, in a room with a trolley in the doorway. The binder is in the office. Anything that requires walking back to the office to consult will be consulted only when the alternative is worse than walking.

It is not addressed to the moment. A binder is organised by topic, because topics are how you write a document: pest management, lost property, chemical handling. A person at work does not have a topic. They have a situation: there is something moving in the mattress seam of 214. Getting from that situation to “pest management, section four” requires the reader to already know the answer's category, which is most of what they were missing.

It cannot be cited. When the answer comes out of a colleague's memory it arrives with no provenance. There is no way to check it, no way to notice it has drifted from what the property actually decided, and no way to update everyone when the decision changes. A procedure that cannot be pointed at is not a procedure; it is a custom.

Writing for the question, not the topic

Retrieval changes what good writing looks like. If a system is going to find the right procedure from the words a person actually uses, then the procedure has to be written in those words, and it has to be small enough that finding it means finding an answer rather than a chapter.

A few rules that survive contact with real properties:

• One situation per document. If a procedure covers three unrelated situations, it will be retrieved for all three and be mostly wrong each time. Split it.
• Title it as the question, not the subject. “Guest reports insects in the room” beats “Pest management policy”. The first is what somebody types. The second is what somebody files.
• First line, first action. The person reading is standing up. Put the thing they do immediately at the top and the rationale underneath. Most procedure documents are written in the opposite order because that is how the writer thought about it.
• Use the property's own nouns. If the floor calls them garden villas and the rate sheet calls them junior suites, write both. If a chemical is known on the floor by its brand and not its class, include both. Retrieval works on the words people use, and the words people use are local.
• Put the exception where the exception happens. Exceptions buried in an appendix are exceptions that will be discovered by a guest complaint.
• Give every procedure an owner and a date. Not for the auditor. For the moment, some time from now, when somebody has to decide whether this still reflects what the hotel does.

Length is worth a word of its own. There is a strong instinct to write comprehensively, and it is the instinct to resist. A procedure that answers the situation in a paragraph and links to the long version is used. A procedure that answers it across several pages is skimmed until the skimming produces something plausible.

Citations, or it is just a rumour

An answer without a source is a rumour with good manners.

This matters more once a system is doing the retrieving, not less. If a housekeeper asks how to handle found medication and receives a confident paragraph with no indication of where it came from, she has to decide whether to trust it, and she has no basis on which to decide. She will either trust it blindly, which is worse than the group chat, or ignore it, which makes the whole exercise decorative.

The fix is unglamorous: the answer arrives with the procedure attached. She reads the paragraph, sees that it came from the housekeeping knowledge base, opens it if she wants the rest, and — this is the part that compounds — notices when the cited procedure is out of date, because now she can see it.

That last effect is the one nobody expects. Citations do not only make answers trustworthy. They make the knowledge base self-correcting, because every retrieval puts a document in front of somebody qualified to notice that it is wrong.

What to do with the binder you have

Do not migrate it wholesale. A binder moved into a system is a binder with a search box, and the search box will be used the way the binder was used, which is to say not at all.

The order that works:

Start with what was actually asked. Go through a month of the housekeeping group chat and write down every question a person asked another person. That list is your first set of documents, and it will be shorter than the binder and completely different from it. Those are the situations the property genuinely has.

Then split what you already have. Take the binder's sections and break them into situations, discarding the parts that describe organisational structure rather than action. Most brand-standard documents are half constitution and half procedure; only the second half is retrievable.

Then name the departments honestly. A hotel that pretends it has one operations department when it has nine will write procedures for a reader who does not exist. Treema ships with 14 department knowledge bases for exactly this reason: front office does not need housekeeping's chemical list, and housekeeping does not need the credit policy, and giving each department its own base is what stops every search returning the other department's answer.

Then treat the housekeeping base as a starting position rather than an inventory. It arrives holding 69 procedures. What a property actually runs on is always partly unwritten, and the unwritten part is precisely where the group chat lives. Closing that gap is the work, and it is never finished in one sitting.

A procedure is finished when a new starter can act on it without asking a question, and an experienced person reads it and does not wince.

None of this is about documentation for its own sake. A property with retrievable procedures does not have better paperwork. It has a shorter distance between a person not knowing something and that person doing the right thing, and in a hotel that distance is measured in guests.