Internes Helpdesk-System — schlank, schnell, an die echten Abläufe angepasst
Ein kleines IT-Team mit fünf Mitarbeitern wollte raus aus der Mischung aus Outlook-Ordnern, Excel-Listen und Jira. Lösung: eine eigene Webanwendung, die nur das kann, was sie wirklich braucht — Mail wird zu Ticket, Aufgaben werden zeitlich erfasst, am Monatsende fällt eine sauberere Auswertung raus.
Wie das angefangen hat.
Der Kunde betreibt selbst IT-Dienstleistungen für etwa 30 mittelständische Unternehmen. Das Team ist klein, die Aufgabenlandschaft groß: Tickets kommen per Mail, gelegentlich per Telefon, manchmal auch über das Kontaktformular der eigenen Website. Verwaltet wurde das vorher in Outlook („Wichtig"-Ordner pro Kunde) und einer Excel-Tabelle, in der Stunden eingetragen wurden, wenn man dran dachte.
Beim ersten Vorgespräch hat mir der Geschäftsführer den Stand sehr präzise zusammengefasst: „Wir wissen am Monatsende nicht, wie viel Arbeit wirklich für welchen Kunden angefallen ist. Wir verlieren Zeit, weil zwei von uns parallel an demselben Problem sitzen. Und wir haben drei Mal in den letzten zwei Jahren eine Mail übersehen, die uns Geld gekostet hat."
Was wirklich auf dem Tisch lag.
Standard-Lösungen wären Jira Service Management, Zammad oder Freshdesk gewesen. Wir haben das geprüft. Drei Punkte haben gegen Standard gesprochen:
- Die Stundenabrechnung pro Kunde mit individuellen Sätzen, Pauschalverträgen und „Service-Token" war in keinem System sauber abbildbar — überall hätte es Workarounds gebraucht.
- Die internen Kategorisierungen und Eskalationsregeln waren über Jahre gewachsen und hätten in einem Standard-Tool nicht abgebildet werden können, ohne dass das Team sie „verbiegen" muss.
- Das Team wollte explizit nichts in der Cloud, weil ein Teil der Kunden öffentliche Verwaltung ist — Daten bleiben on-prem, Punkt.
Damit war klar: das wird Eigenentwicklung. Mit klarem Versprechen, dass es keine Featuritis gibt — nur das, was nachweislich gebraucht wird.
Wie ich's angegangen bin.
-
01
Anforderungs-Workshop mit dem ganzen Team
Statt vom Geschäftsführer alleine das Lastenheft schreiben zu lassen, haben wir einen halben Tag gemeinsam gesessen — Geschäftsführer, drei Techniker, eine Sekretärin. Alle haben aufgemalt, wie ein typisches Ticket bei ihnen durchläuft. Dabei kamen drei Sachen ans Licht, die im Lastenheft nicht standen, aber täglich Reibung erzeugen.
-
02
Mail-zu-Ticket über IMAP-IDLE
Ein dauerhaft mit dem Mailserver verbundener Worker (Laravel-Queue + IMAP-IDLE) erkennt eingehende Mails in Echtzeit. Anhand der Empfänger-Adresse, der Mail-Domäne und einer kleinen Regel-Engine wird das Ticket automatisch dem richtigen Kunden zugeordnet. Reply-To-Antworten landen am bestehenden Ticket, kein Neuauflauf.
-
03
Zeiterfassung als zentraler Bestandteil, nicht als Add-on
Jedes Ticket hat einen großen, gut sichtbaren „Stoppuhr"-Knopf. Beim Start läuft die Zeit, beim Schließen der Aufgabe wird der Eintrag direkt persistiert — mit kurzem Notiz-Feld. Mehrere parallele Stoppuhren sind möglich, ein Wechsel pausiert die alte automatisch. Das ist die Funktion, die laut Team den größten Effekt auf die Erfassungsqualität hatte.
-
04
Kunden-Konfiguration mit Vertragsmodellen
Pro Kunde kann hinterlegt werden: Stundensatz, Pauschalverträge mit Restguthaben, Service-Token-Pools, SLA-Eskalationsregeln. Wenn ein Ticket reinkommt, sieht der Techniker direkt: „dieser Kunde hat noch 4 Stunden im Monat frei, danach wird es verrechnet."
-
05
Auswertung als Dashboard und PDF-Export
Am Monatsende klickt der Geschäftsführer auf einen Button, bekommt ein PDF pro Kunde mit allen Tickets, geleisteten Zeiten und der Differenz zur Pauschale. Das, was vorher zwei Tage Excel-Arbeit war, dauert jetzt drei Minuten. Das Tool exportiert auch direkt ein Sage-kompatibles CSV für die Buchhaltung.
-
06
Hosting on-prem, mit Backup-Off-Site
Die Anwendung läuft auf einer eigenen VM beim Kunden, hinter dessen Firewall. Backups werden verschlüsselt zu einem zweiten Standort gespiegelt — Restic, mit Wiederherstellungs-Test alle drei Monate. Die Mitarbeiter erreichen die Anwendung über das interne Netz oder via VPN.
Was am Ende rauskam.
Nach drei Monaten Produktivbetrieb hat der Geschäftsführer mir ein einseitiges Statement geschickt, das ich gefragt habe, ob ich es zitieren darf. Sinngemäß: „Die monatliche Abrechnung dauert jetzt eine Stunde statt zwei Tage. Wir haben in diesem Quartal über 40 Stunden zusätzlich verrechenbar gemacht, die wir vorher nicht erfasst hatten. Das System hat sich nach 4 Monaten amortisiert."
Das ist die Sorte Aussage, die ich gerne weitergebe — nicht weil sie nett klingt, sondern weil sie zeigt, wann sich Eigenentwicklung lohnt: wenn ein Standard die Realität verbiegt, statt sie abzubilden.
Womit's gebaut wurde.
- Laravel 11 als Backend mit Livewire-Inseln und einer kleinen REST-API für die Vue-Frontend-Bereiche.
- Vue 3 + Pinia für das interaktive Ticket-Board, Stoppuhr-Komponente und das Live-Dashboard.
- MySQL mit Migrationen pro Feature, Redis als Cache und Queue-Backend.
- IMAP-IDLE-Worker auf Basis eines kleinen PHP-Daemons mit Supervisord-Überwachung — Reconnect-sicher, Logs sauber.
- PDF-Generation mit DomPDF und vorbereitetem Briefkopf-Template, Sage-kompatibler CSV-Export für die Buchhaltung.
- Restic + Borg als doppelter Backup-Pfad — eine off-site, eine vor Ort.
Was ich daraus mitnehme.
Eigenentwicklung ist nicht günstig. Aber wenn das Geschäftsmodell vom Standard abweicht — und das ist bei vielen Mittelständlern der Fall — dann lohnt sich der einmalige Aufwand schnell, weil das Tool danach wirklich hilft, statt einen Workaround pro Tag zu kosten. Drei bis sechs Monate Amortisation sind realistisch, wenn das Lastenheft ehrlich gemacht wird.
Wenn dein Team gerade an einem ähnlichen Punkt steht — „Outlook reicht nicht mehr, Jira ist zu viel" — sprechen wir gerne mal über deine Realität. Manchmal ist die Antwort tatsächlich „nimm Zammad", manchmal ist sie eine eigene Lösung. Beides ist okay.
Lass uns zwanzig Minuten drüber reden.
Du erklärst, was du brauchst — ich melde mich mit einer ehrlichen Einschätzung. Kein Pitch, kein Ticket-System.