The small list beside the system: the tools you build yourself

A small tool can solve a big problem. But to become part of the work, it has to be more than the project of the person who built it.

Imagine a new employee at reception, in the middle of a process they have seen only once. The instruction exists. But it is somewhere between an SOP, a video, a few photographs and what a colleague explained to them two nights earlier. The process waits, and they search.

This is not a scene I have documented as an incident. It is my experience of the first weeks at the hotel, in September 2026, written as a picture. And it is the reason I began to build a tool of my own.

What I have and what I do not

What I have: Front Desk Control, which I developed in September 2026 to organise the work in Front Office and Night Audit: SOP instructions, checklists, information search and visual explanations with screenshots of the processes. Work on structures for Shift Handover and the night reports, on organising the Breakfast Forecast processes, and on checklists and step-by-step instructions. Several versions and improvements of Front Desk Control. And my own personal use of it.

What I do not have: whether colleagues use it regularly. An official approval from management or from IT, a formal test with colleagues, or a company decision to use it. How every part works technically without internet, and whether all the data stays only on the device. A case in which an outdated procedure in the tool caused an error. And someone who updates it when I am away.

In the essay in which I described Front Desk Control, I presented it as work in progress. This essay does not repeat that story. It asks something else: what happens to a tool like that once it exists, and when it stops being only yours.

Why the small lists appear

I did not build it because information was missing. I built it because the information was scattered: SOP documents, explanations from colleagues, photographs, videos, checklists. I often had to search through several materials to understand how a process was carried out. The problem was not that the instruction did not exist. It was that I could not find it at the moment I needed it.

I was not trying to replace the hotel system. I wanted a place where I could find the instructions faster.

I believe most of the small lists beside the official system appear this way. Not from distrust of the system, but from a gap between the system and the work. An Excel sheet, a printed page beside the screen, a page built in the evening. Each of them is, in a way, a report nobody asked for: here the information does not reach where it should.

When an employee builds a tool to make the work easier, they may be showing a gap in the way the organisation distributes information.

In When a new system arrives I wrote that a document outside the system is not automatically a bad habit. This essay goes one step further: sometimes it is the best signal an organisation has of what it is missing.

Useful does not mean authorised

But the signal has another side too. A personal tool does not become part of the official system just because it is useful.

There is an important difference between a personal tool for organising my own knowledge and an authorised application that the whole team uses in operational work. The first is my notes, in a tidier form. The second is something for which someone other than me takes responsibility: for its accuracy, for the data it handles, for what happens when it is wrong.

I do not have an official approval for Front Desk Control as a hotel tool, and I will not present it as one. It is a tool that helped me. If it were to become a team tool, it would have to pass through things a personal project does not pass through by itself.

A useful tool becomes a team tool only when it is accurate, up to date, authorised for the use it is given, and safe for the information it handles.

The data that does not go in

In the public version of Front Desk Control I required that no real guest data, reservations, payment information, credentials or confidential documents be included, and that the screenshots used for demonstration be anonymised.

I do not know exactly how every part of it works technically without internet, and I will not claim that a tool is fully offline or safe just because it opens in a browser. That is one of the easiest things to assume and one of the hardest to prove.

So my principle is simple: real and confidential hotel information does not go into a personal tool without authorisation and without verifying how it is stored. A tool you build yourself can hold the method. The real data belongs to the system that is authorised to hold it.

The tool that depends on one person

Front Desk Control has gone through several versions. I have worked to update the instructions according to confirmed processes, to check the screenshots so that they show the right step, to separate the confirmed procedures from those that still need verification, and to keep the structure intact through the improvements.

But there is a limit I see clearly. There is no system in which someone else takes responsibility for updating it when I am away. If only I understand and update the tool, it remains dependent on me.

It is the same thing I wrote in The tour the driver does not understand about the experienced driver, only here it is me. Knowledge that stays in one head does not become less fragile because it is written on a page that only one person keeps. And an outdated instruction in a tool that looks orderly is more dangerous than a missing instruction, because nobody looks it up twice.

Five conditions before you share it

Today I would separate personal development from official use more clearly. For every tool created for work, I would require:

1. A defined purpose and clear limits of use. What it does, and what it does not do.
2. Verification of the content against the official SOPs. With the procedures that are still being verified marked as such.
3. Approval before use with real data or by a team.
4. Someone responsible for updates and version control. Someone other than me.
5. Testing by other users before anyone says the tool is ready for shared use.

And I would not measure success only by the fact that the tool works technically. I would want to know whether it really helps employees, whether the information is accurate, and whether it can be maintained without me too. For none of these do I yet have a measured answer for Front Desk Control. That is the work that remains.

Before you share your tool

The card below is for every tool you have built for yourself and think could serve others too: the purpose and the limits, verification against the SOPs, the data that does not go in, the approval, who updates it when you are away, and who else has tried it. Fill it in before you hand it over, not after it has spread. Shift Handover is an example of a tool that holds the method and nobody else's data: handovers stay in your browser, and nothing is sent or uploaded.

A small tool can solve a big problem. But to become part of the work, it has to be more than the project of the person who built it.