An SOP that is only read can look very professional. It can have nice pages, a lot of text and every possible detail. But when the pressure of the shift begins, nobody has time to read a manual.
I have seen this in logistics and in the hotel alike.
In logistics I worked on standardising the processes tied to the flow of the shift: loading, discipline on the ramp, handling problem orders, checking damage and incomplete orders, following the temperature processes, and how problems are escalated during the operation. The idea was always the same: when you have many people, many orders and time pressure, you cannot rely only on memory, or on the fact that an experienced employee "knows how it's done".
In the hotel I have worked much more directly with checklists and SOPs for Front Office and Night Audit processes: checking reservations and statuses, closing the day, the reports, the shift handover, and the processes that have to be verified before the work counts as finished.
An SOP does not start in Word
It starts with the real work.
First I want to understand what result has to come out at the end of the process. Then I look at what really happens in the shift, where the mistakes happen, what gets forgotten most often and which steps depend on each other. Only after that do I turn the process into a structure.
I try to remove everything the person does not need at the moment they are working. If a document has a lot of theory but does not help you when you have several things to solve at once, for me it is not a good SOP.
Another important part is the order. The person has to understand not only what to do, but also what must have been checked before they carry on.
Before I consider a process finished, I compare it with the real work again and correct it when I see that the document and reality do not match.
I do not have a formal process in which every SOP I have created was tested by a set group of people before it was used, and I would not claim something I have not done. But the principle I use is simple: the SOP has to be understandable even for someone who does not carry the process in their head the way the person who wrote it does.
The problem I have seen most often
I do not have a clear case where I can say I created an SOP, put it in place and it failed in practice. What I have seen often is something else: documents that exist, but that in the real work are too long, scattered across several places, or do not help the employee at exactly the moment they need the information.
That is one of the reasons why, later on, I started to think more about how a procedure is presented, not only about what is written inside it.
How an SOP stays alive
An SOP cannot be treated as a document that is written once and then forgotten.
The process changes. Systems change. The team changes. A screen in the software can change. A responsibility can move to another department. And sometimes the work itself shows you that a step that looked logical in the document is not so practical in the shift.
That is why, for me, an SOP has to be updated every time the reality it describes changes. The person who knows the process has to flag the change, and the version the team uses has to be corrected, so that two different ways of working do not keep circulating.
One of the biggest problems I have seen with operational documentation is when the "official" version says one thing while the people on shift have learned another way. At that moment the SOP has stopped being a standard.
The SOP that is read and the SOP that is used
An SOP that is really used has to answer three questions quickly:
Where am I in the process?
What do I need to check now?
How do I know I can carry on?
That is why I like checklists, splitting the process into sections, and visual instructions where they are needed.
The person doing the work should not have to search for the information. The information should be where they expect it.
From documents to a working tool
Front Desk Control came out of this problem.
In Front Office and Night Audit work, information can be scattered across many places: checklists, separate documents, instructions, screenshots and notes created at different moments. When you are learning a new hotel or a new system, the problem is not always a lack of information. Sometimes the problem is that you have a lot of information and cannot find the piece you need at the right moment.
So I gathered these processes into a single digital structure, a single page. Not as a manual to read from start to finish, but as a working tool. The processes are split by function. You can find the SOP you need, see the matching instruction and use the visual references without searching through many different documents.
An important part for me was also the quality of these materials. I reviewed the images and screenshots used in the instructions, and kept only the ones that clearly show the same step of the process and are actually readable.
For me, Front Desk Control is not interesting only as a website. It is a way of solving a problem I have seen myself in operations: the knowledge exists, but it is not always where the employee needs it.
And this is exactly where the meaning of an SOP changes. A document tells you how the work should be done. A good SOP helps you do the work correctly at exactly the moment you need it.
The best test of an SOP, in my view, is not whether the author understands it. The author always does, because they wrote it. The test is whether someone else can use it under pressure and get the same result.