Wie ich Front Desk Control gebaut habe

Ich habe Front Desk Control nicht gebaut, weil Dokumente fehlten.

Ich habe angefangen, weil die Dokumente da waren, die Information, die ich bei der Arbeit brauchte, aber verstreut war.

In den bisherigen Essays dieser Reihe habe ich oft „das habe ich nicht“ und „ich werde es nicht erfinden“ geschrieben. Dieser Essay ist anders. Hier habe ich ein echtes Projekt, das ich Schritt für Schritt entwickelt habe und das sich prüfen lässt. Aber auch hier werde ich klar trennen, was ich zeigen kann und was ich nicht behaupten kann.

Was es ist

Front Desk Control ist ein Arbeitswerkzeug im Browser, das ich gebaut habe, um die Informationen und Abläufe von Front Office und Night Audit an einem Ort zu haben.

Ich wollte nicht einfach einen weiteren Ordner mit Dokumenten. Ich wollte eine Seite, auf der ich schnell finde, was zu tun ist, in welcher Reihenfolge, und wo ich Hilfe suche, wenn ich nicht sicher bin.

Im Projekt habe ich HTML-Seiten, Schritt-für-Schritt-Anleitungen, Checklisten und Screenshots genutzt, um die Abläufe visuell zu erklären. Die öffentliche Version ist hier offen, mit anonymisierten Inhalten.

Am Anfang war der Bedarf persönlich. Ich lernte neue Abläufe und wollte die Information ordnen, die ich während der Schicht brauchte.

Warum ich angefangen habe

Ich habe das Projekt im September 2026 entwickelt, in der Zeit, in der ich mich mit Einarbeitung und den Abläufen des Night Audit beschäftigt habe. Das genaue Datum der ersten Version habe ich nicht.

Das Problem war sehr konkret. Die Information, die ich brauchte, war da, aber verteilt auf Checklisten, Dokumente, Screenshots, Videos und Notizen. Die Checkliste sagte mir, was zu tun war, während ein anderes Dokument oder ein Kollege mir zeigte, wie. Um ein Verfahren zu verstehen, musste ich manchmal von einem Material zum nächsten wechseln.

Das schließt direkt an den ersten Essay der Reihe an, Die ersten 30 Tage. Zuerst habe ich versucht, den Betrieb zu verstehen. Dann habe ich begonnen, einen Weg zu bauen, damit die Information nicht verstreut bleibt. In Eine gute SOP ist kein Dokument habe ich geschrieben, warum. Hier möchte ich zeigen, wie.

Das Problem war nicht fehlende Information. Das Problem war, wie schnell ich sie finden und nutzen konnte.

Ich wollte mir nicht merken müssen, wo jedes Dokument liegt. Ich wollte wissen, wohin ich für die richtige Antwort gehe.

Wie ich es geordnet habe

Ich habe mich entschieden, es nicht als langes Handbuch zu ordnen, das man von vorn bis hinten liest. Ich habe es nach der Arbeit geordnet, die zu erledigen war.

Ich habe eigene Bereiche für Front Office und Night Audit angelegt, mit Anleitungen, Suche, Checklisten und Bildern, die die Schritte erklären.

Eine der wichtigsten Entscheidungen war, dass man sich den Namen des Originaldokuments nicht merken muss, um eine Antwort zu finden. Wer gerade ein Verfahren ausführt, sollte nach dem Verfahren suchen können, statt in Ordnern zu suchen, bis er das richtige PDF findet.

Nach dem Verfahren suchen, nicht nach dem Dokument.

Die Screenshots hatten eine besondere Rolle. Sie waren keine Dekoration. Sie mussten denselben Schritt zeigen, den der Text erklärte, lesbar sein und keine personenbezogenen Daten zeigen. Bei den Verbesserungen habe ich auch die Qualität der Bilder geprüft. Ich wollte einen Screenshot nicht ersetzen, nur weil ein anderer schöner aussah, wenn das neue Bild nicht genau dieselbe Handlung zeigte.

Was ich weggelassen habe

Die öffentliche Version durfte keine echten Gästedaten enthalten, keine Reservierungen, Zahlungsinformationen, Zugangsdaten oder vertraulichen Dokumente, und kein Material, das den internen Betrieb offenlegen könnte.

Für mich ist diese Trennung wesentlich.

Man kann die Methode zeigen, mit der man Information ordnet, ohne die sensible Information zu veröffentlichen, auf der die Arbeit beruht.

Was ich nicht behaupten kann

Ich habe keine verlässliche Zahl an Arbeitsstunden. Ich weiß, dass das Projekt im September 2026 in mehreren Phasen entstanden ist, mit laufenden Ergänzungen und Verbesserungen. Es war keine Seite, die ich einmal gebaut und nie wieder angefasst habe: Je mehr ich über die Abläufe lernte, desto mehr habe ich auch überarbeitet, wie die Anleitungen dargestellt waren. Aber ich werde nicht „eine Woche“ oder „40 Stunden“ schreiben, ohne einen Beleg dafür.

Meine eigene Nutzung während der Entwicklung ist belegt. Zur Zahl der Kollegen, die es nutzen, zu einem formalen Test im Team, zu konkretem Feedback oder zu gemessenen Verbesserungen der Arbeitszeit habe ich nichts.

Deshalb werde ich nicht schreiben, dass Front Desk Control die Einarbeitungszeit verkürzt, Fehler reduziert oder von der Abteilung übernommen wurde. Das wären Behauptungen über Ergebnisse, die wir nicht gemessen haben.

Was ich sagen kann: Das Projekt hat mir geholfen, die Information in eine klarere Struktur zu bringen und sie weiterzuentwickeln, während ich lernte. Es kann auch für jemanden in der Einarbeitung nützlich sein. Aber das ist eine Möglichkeit, kein Ergebnis.

Was ich heute anders machen würde

Heute würde ich noch früher mit der Struktur der Information beginnen, bevor ich mich um das Aussehen der Seite kümmere. Ich würde zuerst festlegen, welche Fragen in einer Schicht am häufigsten auftauchen und welche Verfahren am wichtigsten sind. Dann würde ich die Antworten um diese Bedürfnisse herum bauen.

Ich würde auch drei Kategorien klarer trennen:

• Bestätigt: Das Verfahren ist geprüft und dokumentiert.
• In Prüfung: Das Material ist da, muss aber in der Praxis geprüft werden.
• Unfertig: Die Anleitung reicht noch nicht, um den Ablauf sicher auszuführen.

Das stelle ich als Verbesserung vor, die ich heute empfehlen würde, nicht als Funktion, die ich im Projekt vollständig umgesetzt hätte.

Und ich würde mich auf Tests mit anderen Nutzern konzentrieren, bevor ich das Werkzeug für den breiteren Einsatz bereit nenne. Denn dass ich eine Anleitung verstehe, heißt nicht, dass jemand, der sie zum ersten Mal sieht, sie genauso versteht. Es ist dasselbe Prinzip wie in „Schau, wie ich es mache“ ist keine Einarbeitung, nur auf das Werkzeug angewandt statt auf den Menschen.

Wie man aus einem SOP-Ordner ein Arbeitswerkzeug macht

Sie müssen keine Anwendung bauen. Die Methode funktioniert auch für ein einzelnes Dokument, eine Intranetseite oder eine Tabelle. Fünf Schritte:

1. Die Arbeit bestimmen. Welchen Prozess wollen Sie leichter machen? Fangen Sie mit einem an, nicht mit allen.
2. Die Quellen sammeln. Wo liegt die Information heute? Checklisten, Dokumente, Videos, Notizen, Kollegen.
3. Einen klaren Weg bauen. Wie kann jemand das Verfahren finden und ihm folgen, ohne den Namen des Originaldokuments zu kennen?
4. Information prüfen und schützen. Was ist bestätigt, was ist noch in Prüfung, und was muss anonymisiert werden?
5. In der Praxis testen. Versteht es jemand anderes ohne Ihre Erklärung?

Bei der Entwicklung habe ich verstanden, dass die größte Herausforderung nicht darin lag, eine schöne Seite zu bauen. Sie lag darin, die Information so zu ordnen, dass sie genutzt, geprüft und verbessert werden kann.

Eine SOP wird erst dann wirklich nützlich, wenn der Mensch, der sie braucht, sie im richtigen Moment finden, verstehen und anwenden kann.