Vom E-Mail zum Ticket: Ihre Regeln
Damit Gustav E-Mails so in Tickets verarbeitet, wie es für Ihre Hausverwaltung richtig ist, muss er zuerst lernen, wie Ihr Team arbeitet. Der erste Schritt ist dieses Formular: Es liefert uns eine in den Grundzügen richtige Beschreibung. Ihre Antworten müssen dabei weder perfekt noch vollständig sein — der Feinschliff kommt nach unserer Erfahrung erst in der zweiten Phase, wenn viele echte E-Mails durch das System gelaufen sind und wir Ihre Rückmeldungen dazu sammeln, was noch besser werden muss.
Überfliegen Sie das Formular am besten zuerst einmal ganz, um ein Gefühl dafür zu bekommen, was gefragt ist. Manche Fragen beantworten Sie aus dem Stand, für andere — vor allem die Regelliste in Abschnitt 1 — brauchen Sie vielleicht Kolleginnen und Kollegen. Das ist normal: Dieses Formular ist eher ein kleines Projekt über ein paar Tage als ein Fragebogen für zwischendurch.
Ihre Eingaben werden automatisch zwischengespeichert — aber nur in diesem Browser auf diesem Gerät. Kommen Sie später am selben Computer im selben Browser zurück, ist alles noch da. Auf einem anderen Gerät oder in einem anderen Browser beginnen Sie von vorne. Am besten füllt deshalb eine Person das Formular aus und holt fehlende Angaben bei Kolleginnen und Kollegen ein.
Viele Antworten sind bereits vorausgefüllt oder als (Standard) gekennzeichnet. Das ist unser Vorschlag, mit dem wir starten, wenn Sie nichts anderes angeben — ändern Sie einfach alles, was bei Ihnen anders läuft.
1. Ihre Regeln: Thema → Ticket-Schablone → Zuständigkeit
Der wichtigste Teil: Regeln dieser Art machen rund 40 % aller Nachjustierungen nach dem Start aus. Es lohnt sich hier etwas Zeit zu investieren, um gut zu starten. Keine Sorge man kann es auch wieder ändern oder erweitern. Falls Sie bereits eine Liste mit diesen Informationen haben, laden Sie sie einfach hoch — dann müssen Sie hier nichts abtippen.
Die letzte Regel sollte Ihre allgemeine Auffangregel (für den Rest) sein: Welche Schablone und welche Zuständigkeit gelten für alle Anliegen, die zu keinem der genannten Themen passen? (z. B. alles andere; Ticket-Schablone Allgemeine Anfrage; Kundenservice)
Ihre Regeln — pro Zeile eine Regel: Thema; Ticket-Schablone (Nummer, falls bekannt); Zuständige
Hat die Schablone eine eigene Zuweisungslogik, die gelten soll, lassen Sie „Zuständige“ einfach weg — wir übernehmen die Zuständigkeit dann aus der Schablone.
Vorhandene Regelliste hochladen
Besondere Themenbereiche (kurz: E-Mail Arten)
Manche Themenbereiche, die via E-Mail eintreffen, kommen so häufig, dass sich ein eigenes Ticket-Muster (immer der selbe Aufbau, zB bei SEPA: IBAN, Kontoinhaber, etc.) oder ein eigener Antworttext lohnt. Beschreiben Sie jeden solchen Fall in einem eigenen Feld: die Situation, das gewünschte Vorgehen mit dem Ticket, und ob und wie geantwortet wird. Sobald ein Feld Text enthält, erscheint darunter das nächste.
Bitte höchstens drei solcher E-Mail-Arten. Sie können diesen Teil vorerst auch leer lassen — wir kommen später gemeinsam darauf zurück.
Hier finden Sie Beispiele (die sie aufklappen können, um mehr zu sehen)
_dummy_col_beispiel_notdienst
Situation: Außerhalb der Bürozeiten nimmt ein externer Notdienst die Anrufe entgegen und schickt uns pro Anruf ein Formular-E-Mail mit den Feldern Anrufer, Rückrufnummer, Adresse, Problem und Weitere Informationen.
Gewünschtes Vorgehen: Jede Meldung wird ein eigenes Ticket. Titel von Fall und Ticket beginnen immer mit "Notdienst: " und dann einer kurzen Beschreibung. An diesem Präfix erkennt das Team die Notfälle und filtert danach; bitte Schreibweise nicht variieren. Schablone und Zuständigkeit wie bei einer normalen Schadensmeldung laut Regelliste. Beschreibt das Feld "Weitere Informationen" ein anderes Problem als das Feld "Problem", zählt die ausführlichere Beschreibung.
Betreff: Notdienst: Wasserschaden im Bad, Musterstraße 5 Top 7
Detailtext:
Anrufer: Maria Huber (Mieterin, Top 7)
Rückrufnummer: 0664 1234567
Problem: Wasser tritt aus der Decke im Bad
Weitere Informationen: Nachbar darüber nicht erreichbar; Anruferin hat den Hauptabsperrhahn nicht gefunden
Gemeldet: 14.08.2026, 22:15 Uhr über den Notdienst
Antwort an den Absender: keine. Der Absender ist das Call-Center, nicht die Bewohnerin.
Situation: Eigentümer oder Mieter schicken ein SEPA-Lastschriftmandat (neues Konto, geänderte IBAN, Widerruf), meist als unterschriebenes Formular im Anhang, manchmal nur als E-Mail mit IBAN im Text. Gemeint sind nur dauerhafte Abbuchungsmandate für wiederkehrende Zahlungen (Vorschreibungen, Miete, Betriebskosten). Eine IBAN für eine einmalige Überweisung ist kein SEPA-Fall.
Gewünschtes Vorgehen: Gültig ist nur ein vollständig ausgefülltes und unterschriebenes Formular; ein formloses E-Mail genügt nicht. Vollständiges Formular: Ticket an die Buchhaltung, Betreff "SEPA Bankdatenänderung - [Kontoinhaber] - [Objekt]". Fehlt etwas (Unterschrift, IBAN, Kundennummer): Ticket an die zuständige Hausverwaltung, Betreff "SEPA Formular - Nachbesserung - [Name]". Der Detailtext hat immer denselben Aufbau; fehlende Angaben werden mit "nicht angegeben" gefüllt:
Kontoinhaber: [Name(n)]
Kundennummer: [XXXXX-XXXXX-X]
IBAN: [vollständige IBAN]
BIC: [BIC]
Bankinstitut: [Bank]
Zweck: [Miete / Kaution / Betriebskosten]
Tag des Einzugs: [Tag]
Objekt: [Adresse]
Alle Kundennummern: ja / nein
Ersetzt bestehendes Konto: ja / nein
Antwort an den Absender: Bei vollständigem Formular eine Eingangsbestätigung an den Kontoinhaber (nie an eine Bank), mit maskierter IBAN und dem Hinweis auf Daueraufträge. Wortlaut:
"Sehr geehrte/r ..., wir bestätigen Ihnen den Eingang Ihres SEPA-Lastschriftmandats für das Konto mit der IBAN AT78 **** **** **** 4390. Das Mandat wurde zur Bearbeitung an die Buchhaltung weitergeleitet. Die monatlichen Vorschreibungen werden ab dem kommenden Monat automatisch von Ihrem angegebenen Konto abgebucht. Um Doppelzahlungen zu vermeiden, deaktivieren Sie bitte etwaig vorhandene Daueraufträge bei Ihrer Bank. Es sind keine weiteren Schritte Ihrerseits erforderlich."
Bei Mängeln stattdessen eine Bitte um Nachbesserung:
"Vielen Dank für Ihre Nachricht bezüglich Ihres SEPA-Lastschriftmandats. Für die Bearbeitung benötigen wir zwingend ein vollständig ausgefülltes und unterschriebenes SEPA-Lastschriftmandat. Leider haben wir folgenden Mangel festgestellt: [Mängel]. Bitte senden Sie uns das Formular vollständig ausgefüllt und unterschrieben zurück."
_dummy_col_beispiel_kuendigung
Situation: Mieterinnen und Mieter kündigen ihr Mietverhältnis per E-Mail, oft mit der Frage nach dem Kündigungstermin oder nach der Kaution.
Gewünschtes Vorgehen: Immer ein eigener Fall, auch wenn die E-Mail noch andere Themen enthält. Schablone "Bestandnehmerwechsel", Zuständigkeit Team Vergabe (die Schablone hat keine eigene Zuweisung). Kündigungsfristen und Endtermine werden nicht berechnet und nicht genannt; das prüft die Vergabe anhand des Vertrags. Eine Frage nach dem Saldo oder der Kaution bleibt im selben Ticket.
Betreff: Kündigung Musterstraße 5 Top 14 - Thomas Berger
Detailtext:
Mieter: Thomas Berger, Top 14
Objekt: Musterstraße 5
Gewünschter Auszug laut E-Mail: 31.10.2026 (nicht geprüft)
Weitere Wünsche: Übergabetermin vormittags; fragt nach Rückzahlung der Kaution
Kündigungsschreiben im Anhang: ja, unterschrieben
Antwort an den Absender: Eingangsbestätigung ohne Fristangabe und ohne Zusagen zu Kaution oder Terminen, z. B.:
"Vielen Dank für Ihre Nachricht. Wir haben Ihre Kündigung erhalten und an die zuständige Abteilung weitergeleitet. Sie erhalten von dort eine schriftliche Bestätigung mit dem Kündigungstermin."
2. Welche E-Mails sollen wir nicht bearbeiten?
Grundsätzlich wird jede E-Mail, die im überwachten Postfach ankommt, verarbeitet — außer die hier angehakten Arten. Die vorausgewählten Häkchen sind unser Standard; Sie können jedes davon ändern.
Diese E-Mail-Arten bitte nicht bearbeiten:
Was sollen wir sonst noch ausschließen?
Wenn wir weder Bestandnehmer noch Objekt erkennen können
Manche E-Mails nennen weder eine Person noch eine Adresse, die wir in D+ wiederfinden. Wir legen das Ticket trotzdem an — bewusst ohne Objektzuordnung — und weisen es einer festen Person zu, die es sichtet und richtigstellt. So geht kein Anliegen verloren, und die Zuordnung wird nachgeholt, statt zu fehlen. Ein Zurücklegen der E-Mail in den Posteingang gibt es nicht.
Ausnahmen tragen Sie bitte hier ein.
3. Tickets im ERP (d+ OM)
Das Ticket in Ihrem ERP ist das Ergebnis, das am Ende jedes Falls steht — deshalb ein paar Fragen dazu, wie es aussehen soll. Gustav schreibt das Ticket automatisch und verknüpft es in D+ mit Objekt, Einheit und Bewohner. Name, Top-Nummer und Adresse müssen deshalb nicht im Betreff oder Detailtext wiederholt werden, dürfen es aber, wenn Sie das bevorzugen.
Wie soll der Betreff (Titel) des Tickets aufgebaut sein?
Der Betreff ist die Kurzzeile, unter der das Ticket in D+ in Listen und Suchergebnissen erscheint. Unten steht unser Standardaufbau; ändern Sie, was bei Ihnen anders sein soll.
Bitte bedenken Sie dabei, dass den Ticketbetreff ein Mensch liest, es soll schnell ersichtlich sein, um was es geht (zusätzliche Beschlagwortungen zum Thema oder Angaben zu Objekt, Einheit, Person erschweren erfahrungsgemäß den Lesefluss).
Wie soll der Detailtext des Tickets aufgebaut sein?
Der Detailtext ist der Fließtext des Tickets — das, was die zuständige Person liest, bevor sie handelt. Unten steht unser Standardaufbau; ändern Sie, was bei Ihnen anders sein soll.
Eine E-Mail enthält nicht immer genau ein Anliegen. Schreibt jemand „der Aufzug steht, und übrigens tropft es im Keller“, können daraus ein Fall oder zwei werden — mit zwei Tickets und zwei Zuständigen. Der Absender bekommt trotzdem nur eine Eingangsbestätigung, die beide Anliegen nennt.
Unser Standard: eine E-Mail = ein Fall. Ein Fall entspricht einem Anliegen, so wie es eine Sachbearbeiterin als ein Ticket führen würde — nicht einem Thema oder einem Satz. Wir teilen nur auf, wenn einer dieser Gründe vorliegt: (1) Die Anliegen gehören in getrennte Bereiche der Verwaltung (z. B. Buchhaltung, Technik, Recht). (2) Eines betrifft eine einzelne Einheit, das andere Allgemeinflächen. (3) Ein echter Notfall steht neben einem Routinethema. Mehr als zwei Fälle entstehen aus einer E-Mail nie.
Dieser Standard nimmt bewusst lieber zu wenige als zu viele Tickets in Kauf: Nach unserer Erfahrung macht eine E-Mail, die in viele Tickets zerfällt, mehr Arbeit und mehr Verwirrung als ein Ticket, das ein Thema zu viel enthält.
Viele Teams ergänzen den Standard um Regeln aus ihrer eigenen Organisation, zum Beispiel: „Kündigungen gehen immer an das Team Vergabe — daher immer als eigener Fall“ oder „Buchhaltungsthemen wie die Auszahlung eines Guthabens gehen immer an die Buchhaltung — daher immer trennen“.
Ein gelungenes Beispiel-Ticket aus Ihrem System
Ein Screenshot oder ein Export genügt — Sie müssen nichts abtippen. Aus einem echten Ticket, das Ihnen gut gefällt, lesen wir Aufbau, Tonfall und Detailtiefe direkt ab.
Welcher D+-Benutzername soll als Erfasser stehen?
Auf jedem Ticket steht ein Erfasser. Standard ist das technische CK-Benutzerkonto in Ihrem D+, üblicherweise CaptKnowledge — so ist auf einen Blick erkennbar, welche Tickets Gustav angelegt hat. Sie können stattdessen einen festen anderen Benutzernamen eintragen. Nicht möglich ist ein wechselnder Erfasser, etwa „immer der Zuständige laut Schablone“.
4. Bestätigungsmail und Synchronisierung
Hat Gustav ein Anliegen erfasst, kann er dem Absender eine kurze Eingangsbestätigung schicken. Sie geht immer als Antwort an die Absenderadresse der ursprünglichen E-Mail; Grußformel und Signatur Ihres Teams werden automatisch angehängt. Im Feld unten steht unser Standardtext — ändern Sie ihn so, wie er zu Ihnen passt.
Text der Eingangsbestätigung
Der Text ist bewusst kurz und neutral: keine Zusagen zu Terminen, Kosten oder Zuständigkeiten. „[Anrede]“ und „[Ihr Anliegen]“ werden je E-Mail konkret ausgefüllt, z. B. „Ihre Schadensmeldung zum tropfenden Wasserhahn in der Küche“.
Soll die Bestätigung einen Hinweis enthalten, dass man darauf nicht antworten kann?
Die Zeile „Eine Rückantwort auf diese Nachricht ist nicht möglich.“ steht dann als letzte Zeile vor Grußformel und KI-Hinweis. Bitte bedenken Sie dabei: Bewohnerinnen und Bewohner antworten häufig kurz auf die Bestätigung, und genau diese Antworten ordnen wir am zuverlässigsten dem richtigen Fall zu. Ein Rückantwort-Verbot nimmt uns dieses Signal und macht die Fallzuordnung schlechter.
Wer versendet die Eingangsbestätigung?
Gustav selbst verschickt nie eine E-Mail — das Versenden macht immer das System, nach den hier eingestellten Regeln. Ein Entwurf, der auf die Ticketnummer wartet, kann in dieser Zeit von Ihrem Team verworfen werden; danach geht er automatisch hinaus. Ein Ablauf, bei dem eine Mitarbeiterin die fertige Bestätigung selbst abschickt, ist derzeit nicht vorgesehen.
Soll die Bestätigung die D+-Ticketnummer enthalten?
D+ vergibt die Ticketnummer erst einige Minuten nach dem Anlegen, weil das Ticket zuerst zwischen D+ und OSC synchronisiert wird. Soll die Nummer in der Bestätigung stehen, wartet Gustav darauf — die Bestätigung geht dann mit rund 20 Minuten Verzögerung hinaus statt sofort. Bleibt die Nummer ausnahmsweise länger als 90 Minuten aus, geht die Bestätigung mit dem Hinweis „Ihre Support-Ticketnummer wird derzeit vergeben; das zuständige Team teilt sie Ihnen bei Rückfragen gerne mit.“ hinaus.
Zusatzzeile am Ende der Eingangsbestätigung lautet dann: „Ihre Support-Ticketnummer(n): TI-026396 — bitte geben Sie diese bei Rückfragen an.“
Wie sollen Fallstatus (CK) und Ticketstatus (D+) zusammenspielen?
Jeder Fall in CK ist mit einem D+ Ticket verbunden. Beide haben einen Status (z. B. offen, erledigt) — die Frage ist, ob und in welche Richtung Statusänderungen übernommen werden. Zum Start empfehlen wir „Nur D+ → CK“: solange die eigentliche Arbeit im D+-Ticket passiert, würde ein in CK erledigter Fall ein noch offenes d+-Ticket schließen, obwohl es niemand bearbeitet hat.
5. Besondere Anlagen und Immobilien-Komplexe
Ihre Objekte, Einheiten und Mandanten kennen wir bereits aus D+ — dazu müssen Sie nichts angeben. Was in D+ oft nicht steht: Eigennamen. Große Wohnanlagen, Hochhäuser, Einkaufszentren oder Prestigeprojekte laufen bei Bewohnerinnen, Bewohnern und im Team häufig unter einem Projektnamen, den der D+ Objektname nicht verrät. Nennt jemand in einer E-Mail nur diesen Namen, müssen wir wissen, welche Objekte gemeint sind.
Gibt es bei Ihnen Anlagen oder Komplexe mit eigenem Namen?
Sonstiges, das wir wissen sollten