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.