Wie ein strukturiertes Ticketsystem für Hausverwalter aussieht
Ein Ticket ist ein einfacher Datensatz. Es ist zugleich das wichtigste strukturelle Grundelement moderner Betriebsarbeit, vom Kundendienst einer Fluggesellschaft über das Vorfallmanagement im Krankenhaus bis zur Gebäudeinstandhaltung.
Dieser Artikel erklärt, was ein Ticket ist, was das System rund um Tickets nützlich macht und was sich ändert, wenn Sie Ihre Hausverwaltung darauf umstellen.
Ein Ticket ist nur ein Datensatz mit vier Eigenschaften
Lässt man den Fachjargon weg, ist ein Ticket ein Stück Arbeit mit vier angehängten Metadaten:
- Eine Kennung, meist eine Nummer wie
#0042. Damit Sie sich eindeutig darauf beziehen können. - Ein Status, also wo es im Arbeitsablauf steht. Neu, In Bearbeitung, Warten auf Bestätigung, Geschlossen.
- Ein Verantwortlicher, die Person, die es aktuell voranbringen muss.
- Eine Historie, jede Änderung, die jemand vorgenommen hat, mit Zeitstempeln.
Das ist alles. Alles andere (Kategorien, Prioritäten, Anhänge, Kommentare) ist optionales Beiwerk. Die vier Eigenschaften oben machen aus einer Beschwerde eine nachverfolgte Aufgabe statt einer vergessenen Nachricht.
Vergleichen Sie das mit einer Chat-Nachricht. Eine Chat-Nachricht hat Inhalt. Mehr nicht. Sie hat keine Kennung (außer ihrer Position im Verlauf), keinen Status, keinen Verantwortlichen, keine Historie. Deshalb lässt sich darauf kein Arbeitsablauf aufbauen.
Warum jede der vier Eigenschaften für sich zählt
Kennung
Wenn zwei Personen über eine Meldung sprechen, müssen sie wissen, dass sie über dieselbe Meldung reden. In einem Chat macht man das durch Zitieren: „die Sache mit dem Aufzug von gestern“ oder „das Leck in 4B, bei dem der Klempner meinte, es sei die Dichtung“. Sobald Ihr Betrieb mehr als fünf gleichzeitige Meldungen hat, wird das mehrdeutig.
Eine Ticketnummer (#0042, #0089) löst das ein für alle Mal. Jeder Bewohner, Verwalter oder Handwerker kann sich anhand der Nummer eindeutig auf ein Ticket beziehen. Das klingt banal. Es beseitigt rund 15 % der gesamten Verwirrung in einem typischen Verwaltungsablauf.
Status
Beim Status passiert die eigentliche Magie. Der Status verwandelt ein formloses Gespräch in einen Zustandsautomaten:
Der Bewohner muss nicht fragen „Gibt es etwas Neues?“. Er sieht den Status. Der Verwalter muss sich nicht merken, welche Meldungen beim Klempner hängen. Er filtert nach Status. Der Eigentümer muss keine 200 Nachrichten lesen, um zu wissen, wie viele Meldungen diesen Monat offen sind. Er zählt.
Beim Status wohnt auch die Automatisierung. Ändert sich der Status, passiert etwas: Benachrichtigungen werden ausgelöst, Bewohner werden informiert, Handwerker werden zugewiesen. In einem Chat ist das unmöglich, weil ein Chat kein Konzept von Zuständen kennt.
Verantwortlicher
Jedes Ticket hat in jedem Moment seines Lebenszyklus genau eine Person, die es voranbringen muss. Reicht der Bewohner es ein, ist der Verantwortliche der Verwalter des Objekts (oder ein zugewiesener Handwerker). Weist der Verwalter es einem Handwerker zu, wird der Handwerker zum Verantwortlichen. Markiert der Handwerker es als erledigt, wird der Bewohner zum Verantwortlichen. Er muss bestätigen oder wieder öffnen.
Das ist die eine Eigenschaft, die die „Tragik der Allmende“ eines Gruppenchats durchbricht, in dem alle die Meldung sehen und niemand sie bearbeitet.
Historie
Ein vollständiges Protokoll jeder Statusänderung, jeder Zuweisung, jedes Kommentars. Aus drei Gründen entscheidend:
- Nachvollziehbarkeit. Wenn die Zeit der Eigentümerversammlung kommt, können Sie einen genauen Zeitverlauf vorlegen, wie jede Meldung bearbeitet wurde.
- Mustererkennung. Nach einem halben Jahr stellen Sie fest, dass 40 % Ihrer Sanitärmeldungen aus demselben Objekt kommen, was auf ein bauliches Problem hindeutet, um das sich der Eigentümer kümmern muss.
- Einarbeitung. Kommt ein neuer Verwalter dazu, kann er die Historie jedes Objekts zurückscrollen und verstehen, was los ist.
Was „das System rund um Tickets“ hinzufügt
Ein Ticket für sich ist ein Datensatz. Ein Ticketsystem fügt den Arbeitsablauf drumherum hinzu:
- Weiterleitung. Wenn ein Ticket erstellt wird, an wen geht es? Die meisten Ticketsysteme nutzen Regeln: „Kategorie = Sanitär → Klempner X zuweisen“. Der Verwalter entscheidet nicht.
- Benachrichtigungen. Wenn sich der Status ändert, wer wird informiert? Der Verantwortliche, der Melder, manchmal ein Beobachter.
- Filtern. „Zeig mir alle neuen Tickets in Objekt 12, niemandem zugewiesen, älter als 24 Stunden.“ Zwei Klicks.
- Sammelaktionen. „Schließe 30 Tickets, die seit mehr als zwei Wochen auf Bestätigung warten.“ Eine Aktion.
Diese Vorgänge gibt es in einem chatbasierten Ablauf nicht. In WhatsApp lässt sich nicht „alle offenen Meldungen über vier Objekte hinweg filtern“, weil nichts in WhatsApp weiß, was eine „offene Meldung“ ist.
Der minimal sinnvolle Ticket-Ablauf für ein Objekt
Sie brauchen keine Enterprise-Plattform mit 200 Funktionen. Der minimal nützliche Ticket-Ablauf für die Hausverwaltung hat:
- Titel + Beschreibung + optionale Kategorie + optionales Foto. Die Meldung selbst.
- Statusfeld mit höchstens 5 Werten. Neu, In Bearbeitung, Warten auf Bestätigung, Geschlossen, Wieder geöffnet. Alles darüber hinaus ist übertrieben.
- Zuweisung an eine von drei Rollen. Verwalter, Handwerker, Bewohner.
- Push-Benachrichtigungen bei Zuweisung und Statusänderung. Damit niemand die App öffnen muss, um zu wissen, dass etwas passiert ist.
- Trennung nach Objekt. Jedes Ticket gehört zu einem Objekt, jeder Nutzer sieht nur die Objekte, in denen er Mitglied ist.
Das ist der gesamte Kern. Wenn ein Werkzeug Ihnen das bietet, in einer Oberfläche, die Bewohner ohne Schulung bedienen können, haben Sie, was Sie brauchen.
Die Einwände, die immer kommen
„Meine Bewohner werden das nie nutzen.“
Etwa 70 % werden es tun. Die anderen 30 % schreiben einem Bewohner, der es nutzt, und der meldet das Anliegen weiter. Sie brauchen keine 100-prozentige Nutzung, um den betrieblichen Nutzen zu erzielen. Sie brauchen genug Nutzung, damit der Eingang zur maßgeblichen Quelle wird.
„Wir haben das mit E-Mail versucht und es hat nicht funktioniert.“
E-Mail ist kein Ticketsystem. E-Mail hat keinen Status, keinen gemeinsamen Posteingang, keine Zuweisung, keinen Filter, keine Weiterleitung. E-Mail wie ein Ticketsystem zu behandeln scheitert, weil sie keines ist.
„Dafür haben wir schon eine Excel-Tabelle.“
Eine Excel-Tabelle ist einem Ticketsystem näher als ein Gruppenchat. Sie hat Kennungen und eine Art Statusspalte. Sie hat trotzdem keine Benachrichtigungen, keine Zusammenarbeit in Echtzeit, keine Oberfläche für Bewohner und keine Automatisierung. Sie ist eine Aufzeichnung von Arbeit. Sie ist kein Arbeitsablauf.
Der Wandel in der Denkweise
Das Schwierigste am Umstieg auf ein Ticketsystem ist der gedankliche Wandel von „Ich bin das System“ zu „das System ist das System, und ich beaufsichtige es“. Verwalter, die das verinnerlichen, skalieren auf mehr als 10 Objekte. Verwalter, die es nicht tun, bleiben der menschliche Verteiler, bis sie ausbrennen.
Die erste Woche fühlt sich seltsam an, weil Sie nicht ständig antworten. Dann merken Sie, dass die Objekte reibungslos laufen, ohne dass Sie in Echtzeit eingreifen, und der Grund ist, dass der Arbeitsablauf selbst die Arbeit erledigt, die früher in Ihrem Kopf steckte.
Darum geht es im Kern.
Ersetzen Sie Ihren Gruppenchat in drei Minuten.
Kostenlos für ein Objekt. Keine Kreditkarte. Kein 30-minütiges Onboarding-Gespräch.
Kvaro kostenlos testen