Konzept, Herleitung und Designentscheidungen · Stand Mai 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 dem Server. Kein OpenAI, kein Anthropic, keine externen Dienste. Modell fĂŒr Text: qwen3:14b. 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.
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 einen Lazy Notiz-Felder (!N{Inhalt}) fĂŒr interne Anmerkungen. Bei Icinga-Update-Tickets wird "Updates installiert" + 5 Minuten automatisch vorausgefĂŒllt.
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 Tickets (gecacht, kein erneuter LLM-Aufruf beim Ăffnen). Ăhnliche bereits gelöste Tickets werden per Embedding-Vergleich gesucht und angezeigt.
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?"
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.
FĂŒr Projekte mit fester PrĂŒfliste (z.B. Carbonio Setup) gibt es Checklisten-Vorlagen. Diese werden nicht direkt in OTRS gespeichert â das TicketChecklist-Plugin von OTRS hat keine API. Stattdessen generiert Lizzy ein SQL-INSERT-Snippet das der Administrator direkt in die OTRS-Datenbank einspielt. Ein Zwischenschritt, bis eine direktere Integration möglich ist.
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.
Das TicketChecklist-Plugin hat keine REST-API. Lizzy generiert SQL-Snippets die manuell eingespielt werden mĂŒssen. Das ist ein Workaround â die langfristige Lösung wĂ€re ein direkter DB-Connect oder eine Erweiterung des Plugins. Aktuell akzeptable Lösung fĂŒr seltene AnwendungsfĂ€lle.
Die gesamte Frontend-Logik liegt in einer einzigen Datei mit 3700+ Zeilen. Das ist wartbar solange man das Projekt kennt â fĂŒr einen Neuen ohne EinfĂŒhrung schwer. Geplant ist ein schrittweiser Modul-Split (tickets.js, dispatch.js, ki.js etc.) beim nĂ€chsten gröĂeren Feature.
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.