CRM · Kundentickets
Dein Kunde macht das Ticket auf. Nicht du, nach seinem Anruf.
Der übliche Support läuft über ein Sammelpostfach: Der Kunde schreibt eine Mail, jemand liest sie, jemand antwortet, und was daraus wurde, weiß nur die Person, die dabei war. Hier hat der Auftraggeber einen eigenen Zugang — das Kundenportal —, macht dort sein Anliegen auf, sieht den Stand und liest die Antwort. Du bearbeitest dasselbe Ticket im CRM: mit internen Notizen, die intern bleiben, einem Bearbeiter und der Frist aus seinem Vertrag.
01 — Zwei Seiten, ein Ticket
Ein Datensatz, zwei Oberflächen — und keine Weiterleitung dazwischen.
Das Ticket gehört dir, der Kunde ist der Steller. Er sieht es im Hub, du siehst es im CRM. Es gibt keinen Abgleich, keinen Export, keine Mail, die jemand in ein System überträgt: Es ist dieselbe Zeile, nur aus zwei Richtungen gelesen. Was er ergänzt, steht bei dir. Was du antwortest, steht bei ihm. Der Stand ist immer derselbe.
Im Hub — sein Blick
- Aufmachen mit Betreff, Art des Anliegens und Dringlichkeit
- Die eigenen Tickets mit Stand, Bezug und letzter Aktivität
- Ergänzen, Dateien anhängen, „Erledigt“ melden — und wieder aufmachen
- Die zugesagten Fristen im Klartext, wenn ein Vertrag sie hergibt
Nummernkreis, Supportadresse und Portaladresse hängen an deiner Organisation. Deine Tickets zählen in deiner eigenen Reihe, die Benachrichtigung geht an deine Adresse, und der Link in der Mail führt in dein Portal — nicht in unseres.
02 — Was intern bleibt
Ein Haken vor dem Absenden. Mehr braucht es nicht.
Jeder Beitrag ist entweder eine Antwort an den Kunden oder eine Notiz für dich. Der Unterschied ist ein Kästchen — und er wird nicht nur beim Anzeigen beachtet, sondern schon beim Lesen: Die Kundentür liefert interne Beiträge gar nicht erst aus. Es gibt keinen Platzhalter, keine Lücke, und auch die Zählung stimmt: Wo ihr sieben Einträge seht, zählt sein Portal drei.
- Wer bei dir woran arbeitet, ist deine Sache. Die Zuweisung an einen Bearbeiter steht intern; dass sich etwas bewegt, sieht der Kunde am Stand
- Auch Systemzeilen unterliegen der Regel — scheitert eine Benachrichtigung, steht das als interner Hinweis im Ticket statt verschwiegen zu werden
- Anhänge folgen dem Beitrag, an dem sie hängen: ein Anhang an einer internen Notiz ist intern
- Eine Korrektur schreibt keine Geschichte um. Was einmal offen hinausging, bleibt im Verlauf offen stehen
03 — Der Bezug ist Pflicht
„Es geht nicht“ ist kein Ticket. „Es geht nicht am Portalsystem Frankfurt“ schon.
Jedes Kundenticket hängt an einem Projekt, einer Landschaft oder einer Installation — der Kunde wählt aus, was ihm gehört, und etwas anderes bekommt er gar nicht angeboten. Das ist kein Formalismus: Aus diesem Bezug ergibt sich, welcher Vertrag gilt, welche Frist läuft und welches System gemeint ist. Ohne ihn wäre das SLA eine Schätzung.
- Die Auswahl entsteht aus der Kette Zugang → Ansprechpartner → Kundenfirma → deren Projekte und Systeme
- Ein Zugang bei zwei deiner Kunden sieht beide — und hält sie auseinander
- Ein fremdes Ticket direkt aufzurufen beantwortet das Portal mit „Dieses Ticket gibt es hier nicht“, nicht mit einer Anmeldeaufforderung
04 — Der erste Blick
Ein Assistent, der lieber weitergibt als zu raten.
Wer will, lässt neue Tickets zuerst von einem Assistenten ansehen. Er liest nur deine eigenen Hilfeartikel — nicht unsere, nicht die einer anderen Agentur —, und er antwortet nur, wenn ein Artikel wirklich passt und für die automatische Beantwortung freigegeben ist. Sonst schreibt er eine interne Begründung, nennt die Artikel, die er angesehen hat, und gibt das Ticket an einen Menschen weiter.
- Abschaltbar je Organisation. Er greift nur, wenn du ihn einschaltest — die Vorgabe ist aus
- Seine Quellenangabe ist eine interne Notiz, keine Antwort an den Kunden
- Der Modellverbrauch wird dem gebucht, für den er gearbeitet hat — nicht dem Betreiber
- Die Hilfeartikel pflegst du im CRM; sie sind zugleich die Wissensbasis, aus der er zitiert
05 — Wer was darf
Der Kunde schließt. „Gelöst“ sagst du.
Ein Auftraggeber kann sein Ticket schließen, weil sich etwas erledigt hat, und es wieder aufmachen, wenn es doch nicht erledigt war. Was er nicht kann: es als gelöst melden, jemanden zuweisen oder intern schreiben. Diese Übergänge gehören der Seite, die antwortet — und der Versuch endet nicht in einer stillen Wirkungslosigkeit, sondern in einem Satz: „Diesen Übergang darf deine Rolle nicht gehen.“
06 — Was fehlt
Drei Dinge, die hier noch nicht gehen. Ungeschönt.
Die gerissene Frist wird gemessen, angehängt und gemailt. Sie zieht nichts nach sich: keine automatische Höherstufung, keine Kette an die Geschäftsführung. Das war eine bewusste Entscheidung, keine Lücke — aber es ist eine Entscheidung, die man kennen sollte.
Der Link führt in dein Portal, der Absender der Benachrichtigung ist noch der Betreiber. Das liegt an SPF und DKIM: Von deiner Domain zu senden, ohne dass du uns dafür freigibst, ginge im Zweifel im Spamordner unter. Eine saubere Lösung dafür ist offen.
Es gibt keine Sternchen nach dem Schließen und keinen Bericht über Reaktionszeiten im Monatsschnitt. Die Daten dafür liegen vor — die Auswertung ist nicht gebaut.
Weiter
Und ob das System überhaupt erreichbar ist, muss dir niemand melden.
Die Überwachung misst alle fünf Minuten — auch Systeme, die nicht bei uns laufen.