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.
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 einen Lazy Notiz-Felder (!N{Inhalt}) fĂŒr interne Anmerkungen. Bei Icinga-Update-Tickets wird "Updates installiert" + 5 Minuten automatisch vorausgefĂŒllt.
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 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.
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 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.