Konzept, Herleitung und Designentscheidungen · Stand Juni 2026
Dieses Dokument ist die fortgeschriebene Version des v1-Konzepts (April 2026). Es beschreibt den aktuellen Stand und die Entscheidungen die zur heutigen Architektur gefĂŒhrt haben.
Es geht nicht darum, die letzte Minute aus jedem Mitarbeiter herauszuholen. Es geht darum, Frust zu vermeiden â auf beiden Seiten.
Mitarbeiter die nicht wissen welches Ticket als nĂ€chstes dran ist, die mitten in einer Aufgabe unterbrochen werden weil unklar ist wer wofĂŒr zustĂ€ndig ist, die Hilfe brauchen aber nicht wissen wie sie sie koordinieren sollen â das kostet Energie, die dann fĂŒr die eigentliche Arbeit fehlt.
Kunden die lange warten, keine RĂŒckmeldung bekommen oder das GefĂŒhl haben ihr Anliegen geht unter â das kostet Vertrauen.
Wenn beides besser lĂ€uft â das Team arbeitet strukturierter, Kunden bekommen schnellere und verlĂ€sslichere Antworten â dann ist das der eigentliche Gewinn. Dass dabei auch die Effizienz steigt und am Ende mehr Spielraum bleibt, ist eine Konsequenz davon, nicht das Ziel.
Das Dashboard ist ein Werkzeug fĂŒr das Team, nicht zur Kontrolle des Teams.
OTRS 5 ist das eingesetzte Ticketsystem. Es bietet keine Ansicht, die zeigt, wer gerade woran arbeitet, wie hoch die Auslastung des Teams ist, oder in welcher Reihenfolge Tickets abgearbeitet werden sollen. Das System verwaltet Tickets â aber kein Dispatching.
Das Dashboard entstand aus dem Wunsch, genau diese LĂŒcke zu schlieĂen: Wer macht was, in welcher Reihenfolge, und wieviel KapazitĂ€t ist noch frei?
v1 (April 2026) war ein Browser-Prototyp in einer einzigen HTML-Datei mit localStorage. Er hat bewiesen, welche Features sinnvoll sind und wie der Workflow funktioniert. v2 (Lizzy, ab Mai 2026) ist die produktive Server-Version â alle Mitarbeiter sehen denselben Zustand, OTRS wird auch beschrieben, und KI unterstĂŒtzt aktiv beim Dispatching.
Der Stack ist bewusst gewĂ€hlt. PHP lĂ€uft direkt unter Apache ohne separate Prozesse, MySQL ist fĂŒr das Team vertraut. Kein Build-Schritt, kein Node.js, keine Containerisierung. Das Ziel war eine Architektur die jemand mit Standard-Hosting-Erfahrung warten kann.
Das gröĂte Limit von v1 war der browserspezifische Zustand â zwei Personen sahen zwei unabhĂ€ngige Welten. Lizzy hat eine zentrale MariaDB auf einem separaten Server (ĂŒberlebt Server-Neuaufbau). Alle Dispatch-ZustĂ€nde, Zeitfenster, SchĂ€tzungen und KI-Caches liegen dort. Alle Mitarbeiter sehen denselben Stand.
v1 hat OTRS nur gelesen. Lizzy schreibt aktiv zurĂŒck: Tickets zuweisen (Owner Ă€ndern), Tickets schlieĂen, interne Notizen posten, Zeiteinheiten buchen. Das erforderte einen eigenen OTRS-API-User mit entsprechenden Rechten. Alle Aktionen laufen ĂŒber den GenericTicketConnector.
Ein Python-Daemon (otrs_sync.py) synchronisiert OTRS jede Minute in einen lokalen Cache. Der Browser fragt nie direkt OTRS â er liest aus dem lokalen Cache. Das hĂ€lt OTRS-Last niedrig und Antwortzeiten schnell. Der Kompromiss: Ănderungen aus OTRS sind erst nach bis zu 60 Sekunden sichtbar. Aktionen aus dem Dashboard (Zuweisen, SchlieĂen) aktualisieren den Cache sofort lokal.
Alle KI-Funktionen laufen ĂŒber Ollama lokal auf einem eigenen GPU-Server (AMD/ROCm). Kein OpenAI, kein Anthropic, keine externen Dienste. Modell fĂŒr Text: qwen3-14b-40k â ein qwen3:14b mit auf 40.960 Token erweitertem Kontextfenster, damit auch lange Ticket-VerlĂ€ufe vollstĂ€ndig analysiert werden können. Modell fĂŒr Embeddings: nomic-embed-text. Das war eine bewusste Entscheidung: Ticket-Inhalte verlassen das Netzwerk nicht. Konsequenz: Die QualitĂ€t ist etwas schlechter als GPT-4, dafĂŒr kein Datenschutzproblem und keine laufenden API-Kosten.
Jeder Push auf einen Branch mit offenem Pull Request löst automatisch ein Deployment aus. Gitea Actions baut ein Artifact, lĂ€dt es in die Package Registry und ruft per Webhook einen CI/CD-Controller auf, der das Artifact auf dem Dev-Server auspackt und setup.sh ausfĂŒhrt. Kein manuelles Eingreifen nötig.
Der zentrale Gedanke aus v1 ist unverÀndert: Ein Mitarbeiter kann immer nur eine Sache gleichzeitig tun. Das Dashboard macht das sichtbar und planbar.
Jeder aktive Mitarbeiter hat eine Karte mit seinem aktuellen Ticket ("Aktuell in Bearbeitung") und seiner Queue (priorisierte Liste, Drag & Drop). Der Dispatcher weist Tickets per Drag zu. Tickets können auch zwischen Mitarbeitern gezogen werden. Sortierung: Anwesend â Helpdesk â Pause â Vor Ort â Abwesend â Urlaub.
Neben der tagesaktuellen Queue gibt es Zeitfenster: geplante Arbeitsblöcke pro Mitarbeiter und Tag. Der Dispatcher plant dort Tickets mit ZeitschĂ€tzung ein. Vor dem Einplanen muss eine SchĂ€tzung gesetzt sein â sonst Fehlermeldung ("Bitte erst SchĂ€tzung setzen"). KapazitĂ€tsprĂŒfung: Wenn die Summe der SchĂ€tzungen die Fensterdauer ĂŒberschreitet, wird gewarnt. Die 300-Minuten-Annahme aus v1 ist damit teilweise abgelöst â durch echte Zeitfenster statt eines pauschalen Limits.
Neben der Dispatcher-gesteuerten Zuweisung gibt es den Ticket-Pool-Ansatz: Mitarbeiter wĂ€hlen selbst aus einem Pool offener Tickets. Das passt zu Teams die eigenverantwortlich arbeiten und keinen dedizierten Dispatcher haben. Im Lizzy-Modell ist das eine ergĂ€nzende Option â die KI-VorschlĂ€ge dienen als Orientierung, der Mitarbeiter trifft die endgĂŒltige Wahl. Ticket Pool und Dispatcher-Zuweisung schlieĂen sich nicht aus; manche Tickets werden aktiv zugewiesen, andere landen im Pool fĂŒr Selbstselektion.
Wenn ein Ticket geschlossen wird, können Zeiteinheiten (Minuten) und ein Abrechnungstext erfasst werden. Der Abrechnungstext (Lazy Text) wird als !B{Inhalt} in die OTRS-Notiz geschrieben â ein Format das das interne Abrechnungssystem von inmedias.it erkennt und extrahiert. ZusĂ€tzlich gibt es ein Lazy Notiz-Feld (!N{Inhalt}) fĂŒr interne Anmerkungen. Bei Icinga-Update-Tickets wird "Updates installiert" + 5 Minuten automatisch vorausgefĂŒllt.
Der Abrechnungstext kann per Knopf (⊠aus Kommentar) vom LLM aus einer formlosen internen Notiz erzeugt werden: ein sachlich-neutraler Satz, einheitliche Begriffe (Glossar), Wertungen entfernt. Ist die Notiz zu knapp (z.B. nur "Kommunikation"), zieht das LLM den Ticket-Verlauf als Kontext heran und prĂ€zisiert â aber strikt nur, was belegt ist (kein Erfinden auf einer Rechnung). Der Mitarbeiter sieht den Vorschlag und kann ihn vor dem Speichern anpassen. Das Format !B{âŠ} wird dabei gegen Sonderzeichen abgesichert, damit der Export-Parser nicht bricht.
Lizzy unterstĂŒtzt zwei grundlegend verschiedene Arbeitsweisen. Ein Mitarbeiter kann einen oder beide Modi verwenden.
Zeigt was gerade jetzt passiert. Der Dispatcher sieht in Echtzeit: wer arbeitet an welchem Ticket, wer ist anwesend, wie viele Tickets warten in jeder Queue.
Explizite Tages- und Wochenplanung. Tickets werden festen Zeitblöcken zugeordnet â der Mitarbeiter sieht in seiner Ansicht genau sein Zeitfenster fĂŒr den Tag.
Die Modi schlieĂen sich nicht aus. Der Dispatcher nutzt typischerweise den Live-Modus fĂŒr die tagesaktuelle Steuerung; die Zeitfenster-Planung dient dem Vorausplanen von Kundenterminen und gröĂeren Aufgaben.
Nicht alle Tickets sind gleich dringend. Lizzy kennt mehrere Dringlichkeitssignale und kombiniert sie fĂŒr den Dispatcher sichtbar.
Tickets mit hoher OTRS-PrioritÀt oder Icinga-Severity CRITICAL werden farbig hervorgehoben (rot). Monitor-Tickets werden im Dashboard mit einem eigenen Status-Panel dargestellt.
Manche Tickets haben einen fixen AuĂendiensttermin oder Kundentermin. Diese sollen â wenn die Kalender-Integration umgesetzt ist â automatisch als Zeitblock im Zeitfenster erscheinen, sodass der Mitarbeiter und der Dispatcher sehen: "Dieses Ticket ist am Dienstag 14 Uhr, nicht verschiebbar." Aktuell ist das ein manueller Schritt (Zeitfenster hĂ€ndisch anlegen). Die VerknĂŒpfung Ticket â Kalender-Eintrag ist eine der offenen Fragen.
Der KI-Score berĂŒcksichtigt bereits die Summe der Minuten-SchĂ€tzungen in einer Queue. Das ist kein formales SLA â aber ein FrĂŒhwarnsignal: Wenn ein Mitarbeiter 400 Minuten SchĂ€tzungen hat und nur ein 3h-Fenster, sieht der Dispatcher das sofort als KapazitĂ€tsproblem.
Die KI in Lizzy ist kein Ersatz fĂŒr menschliches Urteilsvermögen â sie ist ein Vorschlag der ĂŒberstimmt werden kann und soll. Jede Zuweisung die der Dispatcher anders trifft als vorgeschlagen, wird gespeichert und flieĂt in kĂŒnftige VorschlĂ€ge ein.
FĂŒr jedes nicht zugeordnete Ticket berechnet Lizzy einen Score pro Mitarbeiter:
Danach bewertet ein lokales LLM (qwen3:14b) die Top-Kandidaten textlich und ergĂ€nzt FAQ-VorschlĂ€ge per Embedding-Ăhnlichkeit.
Das LLM erstellt im Hintergrund Zusammenfassungen aller offenen Tickets (gecacht, kein erneuter LLM-Aufruf beim Ăffnen): ein kurzes Problem-ResĂŒmee, ein Lösungsansatz und Schlagworte. Seit Juni 2026 flieĂt der gesamte Ticket-Verlauf ein (vorher nur die erste Nachricht) â möglich geworden durch das 40k-Kontextfenster. Ăhnliche bereits gelöste Tickets werden per Embedding-Vergleich gesucht und angezeigt.
Auf Knopfdruck entwirft das LLM eine Kundenantwort im pro Kunde konfigurierten Stil (formell / technisch / informell). Es nutzt dabei den Ticket-Verlauf, das Kundenprofil und Ă€hnliche gelöste Tickets als Kontext. Der Entwurf ist ein Vorschlag â der Mitarbeiter formuliert final selbst.
FĂŒr die Kunden-TĂ€tigkeitsberichte fasst das LLM zusammen, woran in einem Zeitraum gearbeitet wurde, und erkennt auf Wunsch die wiederkehrenden Probleme je Kategorie (Themen-Tiefenanalyse). Grundlage sind die bereinigten Ticket-VerlĂ€ufe; die Ergebnisse werden 24 h gecacht.
FAQs aus OTRS werden importiert, per LLM zusammengefasst und mit nomic-embed-text eingebettet. Bei jedem Zuweisung-Vorschlag werden semantisch Ă€hnliche FAQs mitgeliefert. Mitarbeiter können FAQs als hilfreich/nicht hilfreich bewerten â das beeinflusst kĂŒnftige VorschlĂ€ge.
Das LLM generiert aus der Ticket-Historie und EintrĂ€gen aus dem internen Wiki (MediaWiki, Kunde:-Namespace) automatisch ein Profil pro Firma. Dieses Profil flieĂt in den Zuweisung-Prompt ein: "Was macht dieser Kunde, welche Systeme hat er, welche Erfahrungen haben wir mit ihm?"
Alle folgenden Funktionen nutzen dasselbe lokale Modell. Damit es tagsĂŒber nicht blockiert, laufen die meisten Auswertungen vorberechnet im Hintergrund (Cron/Daemon) und werden gecacht â der Klick im Dashboard liefert dann sofort das Ergebnis statt auf das LLM zu warten.
| Funktion | Was das LLM tut | Auslöser |
|---|---|---|
| Zuweisungs-Vorschlag | bewertet Top-Kandidaten textlich, schĂ€tzt Aufwand, ergĂ€nzt FAQ | Klick + Prewarm (1Ă/min) |
| Ticket-Zusammenfassung | Problem + Lösungsansatz + Schlagworte aus dem ganzen Verlauf | Prewarm + Nacht-Batch |
| Antwort-Entwurf | Kundenantwort im konfigurierten Stil | Klick (â) |
| Abrechnungstext | formlose Notiz â neutraler Abrechnungssatz, bei Bedarf mit Verlauf prĂ€zisiert | Klick (⊠aus Kommentar) |
| Kunden-Bericht & Themen | TĂ€tigkeits-Zusammenfassung + wiederkehrende Probleme je Kategorie | Klick (Statistik) |
| Kunden-Profil | Firmenprofil aus Ticket-Historie + Wiki | Admin, pro Kunde |
| FAQ- & Wiki-Aufbereitung | FAQ/Wiki-Seiten zusammenfassen + verschlagworten | Admin / Cron |
| Anonymisierung | erkennt Personennamen fĂŒr die Maskierung im Bericht | Klick (Bericht) |
| Abrechnungs-Korpus | analysiert historische !B{âŠ}-Texte (Auswertung, read-only) | manuell |
Embeddings (nomic-embed-text) sind ein zweiter, eigener Einsatz: Tickets und FAQs werden als Vektoren gespeichert, um per Ăhnlichkeit "passt zu diesem Fall" zu finden â nĂ€chtlich vorberechnet.
Die KI-Funktionen sind kein loser Haufen einzelner Aufrufe â sie bauen aufeinander auf. Im Kern steht der zwischengespeicherte Ticket-Verlauf als gemeinsame Datenquelle, dazu zwei RĂŒckkopplungen aus dem Verhalten des Teams.
Ein Daemon legt die Ticket-Texte aus OTRS lokal ab. Auf dieser einen Quelle setzen Zusammenfassung, Antwort-Entwurf, Abrechnungstext und Themen-Analyse auf â niemand holt die Texte doppelt aus OTRS.
Die Zusammenfassung eines Tickets wird beim Zuweisungs-Vorschlag und beim Antwort-Entwurf als Kontext fĂŒr âĂ€hnliche gelöste FĂ€lle" wiederverwendet. Das Kundenprofil flieĂt in Zuweisung und Antwort-Entwurf ein. Der Abrechnungstext greift bei knappen Notizen auf Verlauf bzw. Zusammenfassung zurĂŒck. So zahlt jede einmal erzeugte KI-Ausgabe auf mehrere Funktionen ein.
Tickets und FAQs liegen zusĂ€tzlich als Vektoren vor. DarĂŒber findet der Vorschlag Ă€hnliche frĂŒhere Tickets und passende FAQs â unabhĂ€ngig von exakter Wortwahl.
Zwei Lernschleifen korrigieren die VorschlĂ€ge: Jede Dispatcher-Zuweisung, die vom Vorschlag abweicht, flieĂt als Follow-Rate zurĂŒck ins Scoring. Jede FAQ-Bewertung (đ/đ) wird kontextgebunden gespeichert und hebt/senkt die FAQ bei Ă€hnlichen FĂ€llen.
Ein Playbook beschreibt einen wiederkehrenden Prozess als Folge von Schritten â zum Beispiel "Onboarding Neukunde" mit 5 Tickets von ErstgesprĂ€ch bis Abnahme. Mit einem Klick (und Eingabe des Kundennamens) werden alle Tickets auf einmal in OTRS angelegt, fertig betextet, der richtigen Queue zugewiesen. Variablen wie {kunde} werden ersetzt.
Jeder Schritt kann einem festen Mitarbeiter vorbelegt werden (Owner Default). Das ermöglicht komplexe wiederkehrende Aufgaben die immer gleich verteilt werden â z.B. "Carbonio-Schritt 1 geht immer an Technik-Queue, Schritt 5 (Abnahme) geht immer an jhs". Der Dispatcher kann beim Auslösen noch ĂŒbersteuern, hat aber sofort eine sinnvolle Vorbelegung.
FĂŒr Projekte mit fester PrĂŒfliste (z.B. Carbonio Setup mit 20 Punkten) gibt es Checklisten-Vorlagen. Das TicketChecklist-Plugin von OTRS hat keine REST-API â Lizzy schreibt die EintrĂ€ge daher direkt in die OTRS-Datenbank (Tabelle ps_ticketchecklist). Da Lizzy Zugriff auf dieselbe Datenbank hat, ist das die vollstĂ€ndige Lösung â kein manueller Schritt, kein Workaround.
Das Prinzip aus v1 gilt: Supporter mĂŒssen nicht entscheiden, sie arbeiten was oben liegt. Die kognitive Last des Priorisierens liegt beim Dispatcher.
Die 300-Minuten-Annahme aus v1 (38h/Woche, abzĂŒglich Overhead) ist weiterhin der Orientierungswert â es gibt keine automatische Kalender-Integration. Reale KapazitĂ€t ergibt sich aus:
Offene Frage (aus v1, noch ungelöst): Meetings und andere nicht-OTRS-Aufgaben erzeugen blinde Flecken. Ein Mitarbeiter der gerade in einem 2-Stunden-Meeting sitzt, erscheint im Dashboard als verfĂŒgbar. Eine Kalender-Integration wĂŒrde das lösen â ist aber noch nicht umgesetzt.
Aus v1 unverĂ€ndert offen. Einkauf, Terminvorbereitung, interne Abstimmungen â diese Aufgaben erscheinen weder in OTRS noch im Dashboard. Die Entscheidung war: nicht zu erzwingen. Ein Mitarbeiter der "frei" erscheint aber gerade eine interne Aufgabe erledigt, ist eine bekannte und akzeptierte UnschĂ€rfe.
Kanboard war als geplante ErgĂ€nzung vorgesehen. Noch nicht integriert, kein konkreter Zeitplan. Solange interne Aufgaben klein und kurzlebig sind, wird das Dashboard als Dispatching-Tool fĂŒr OTRS-Tickets betrieben â bewusst ohne Anspruch auf vollstĂ€ndige Aufgaben-Erfassung.
Die Integration eines Kalenders (z.B. Carbonio) ist seit v1 als Idee vorhanden, aber noch nicht ausgearbeitet. Offen sind mehrere Teilfragen:
Die Frontend-Logik lag ursprĂŒnglich in einer einzigen Datei mit 3700+ Zeilen. Inzwischen ist der Modul-Split erfolgt: gemeinsame Helfer und die Tab-Bereiche (Zeitfenster, Admin, Statistik, Vorlagen) liegen als eigene Module unter assets/js/lizzy/, dashboard.js ist auf ~1800 Zeilen als Orchestrator (Dispatch + Tickets + KI-Klicks) geschrumpft. Eine weitere Aufteilung von dashboard.js selbst bleibt fĂŒr den nĂ€chsten gröĂeren Umbau offen.
Eine einzelne HTML-Datei, localStorage, lokaler Python-Proxy. Konzept-Validierung. Hat bewiesen: welche Features sinnvoll sind, wie der Workflow funktioniert. Code bewusst weggeworfen, Konzept ĂŒbernommen.
PHP + MariaDB + Apache. Geteilter Zustand, OTRS-Schreibzugriff, KI-UnterstĂŒtzung, CI/CD. In produktivem Einsatz bei inmedias.it.
Aus v1 ĂŒbernommen: Konzept, Feature-Definitionen, Workflows. Nicht ĂŒbernommen: Code, Timer, Meeting-Verwaltung, Hilfe-Anfragen als Queue-Eintrag.