Helpdesk-App ohne Code bauen: Tickets sauber verwalten

Helpdesk-App ohne Code bauen

Eine Helpdesk-App entsteht bei Zugo aus einer Beschreibung in Alltagssprache: Wer meldet ein Problem, welche Angaben braucht ein Ticket, welche Status durchläuft es, wer bearbeitet es. Daraus wird ein lauffähiges Projekt. Der erste Build kostet 6 Credits und dauert etwa eine Minute, jede spätere Änderung 3.

Dieser Text klärt zuerst die unangenehme Frage, ob ein Eigenbau überhaupt sinnvoll ist, und geht danach durch Datenmodell, Prompt, Rollen, Kosten und Grenzen.

Wann lohnt sich eine eigene Helpdesk-App?

Ein Eigenbau lohnt sich in zwei Situationen. Erstens, wenn Ihr Ablauf nicht in fremde Formulare passt: Anlagenbau mit Seriennummer und Standort, Hausverwaltung mit Objekt und Wohnung, Softwarehaus mit Kundennummer und Vertragsstufe. Zweitens, wenn Sie wenige Bearbeiter haben und pro Platz zahlen müssten, ohne den Funktionsumfang zu nutzen.

Fertige Systeme wie Zendesk oder Freshdesk sind an anderen Stellen klar stärker, und das sollte man nüchtern sagen. Sie nehmen Tickets direkt per E-Mail entgegen, binden Telefonanlagen an, führen Wissensdatenbanken mit Suche, liefern fertige Berichte und haben eine Rechteverwaltung, die auch bei vierzig Mitarbeitern trägt. Wer diese Dinge braucht, sollte kaufen statt bauen.

Der Eigenbau spielt seine Stärke dort aus, wo Sie ein enges, klares Problem haben: ein Meldeformular für Ihre Kunden, eine Liste für Ihr Team, ein Statusfeld und eine Antwort. Genau dafür sind fertige Systeme oft zu groß, und genau das steht in wenigen Stunden.

Welche Felder braucht ein Ticket wirklich?

Das Datenmodell entscheidet über den späteren Aufwand. Zu viele Pflichtfelder senken die Zahl der Meldungen, zu wenige führen zu Rückfragen, die den Vorteil sofort auffressen.

Zwei Erfahrungswerte dazu. Die Priorität sollte der Bearbeiter setzen, nicht der Melder, denn sonst ist jedes zweite Ticket dringend. Und der Verlauf gehört als eigene Tabelle angelegt, nicht als wachsendes Textfeld, sonst lässt sich später nicht mehr auswerten, wie lange eine erste Antwort gedauert hat.

Wie sieht ein Prompt für die erste Fassung aus?

Konkrete Angaben entscheiden über das Ergebnis. „Bau mir einen Helpdesk" ergibt eine Attrappe mit erfundenen Beispieltickets. Der folgende Prompt ergibt etwas Benutzbares.

Erstelle eine Web-App für die Bearbeitung von Support-Tickets.
Bildschirme: Ticket melden (öffentlich), Ticketliste (nur für angemeldete Bearbeiter),
Ticketdetail mit Verlauf, Auswertung.
Ticket: Titel, Beschreibung, Kategorie (Technik, Rechnung, Sonstiges), Kontakt-E-Mail,
Anhang, Status (neu, in Arbeit, wartet auf Rückmeldung, gelöst, geschlossen),
Priorität (niedrig, normal, hoch), zuständige Person, Erstellungszeitpunkt.
Verlauf: mehrere Einträge je Ticket mit Autor, Text, Zeitstempel und dem Merkmal
intern oder für den Melder sichtbar.
Ticketliste: Filter nach Status und Zuständigkeit, Sortierung nach Alter,
offene Tickets über 48 Stunden farblich hervorheben.
Anmeldung per E-Mail, Melder brauchen kein Konto.
Ton: sachlich und knapp. Farben: helles Grau, ein Akzent für offene Vorgänge.

Der wichtigste Satz ist der über interne Notizen. Ein Verlauf, in dem alles öffentlich ist, wird nach der ersten unglücklichen Formulierung nicht mehr benutzt, und dann steht die Absprache wieder im Chat statt im Ticket.

Wer darf was sehen?

Diese Frage sollten Sie vor dem Build beantworten, weil sie den Aufbau bestimmt. Üblich sind drei Ebenen, und mehr braucht es selten.

Der Melder sieht ausschließlich sein eigenes Ticket, und zwar über einen langen, zufälligen Link aus der Bestätigungsmail. Das erspart ihm ein Konto, was die Zahl der Meldungen spürbar erhöht.

Der Bearbeiter meldet sich an und sieht alle Tickets, kann Status ändern, antworten und interne Notizen schreiben. Die Anmeldung läuft über Supabase, das gleichzeitig Datenbank, Login und Dateiablage für die Anhänge bereitstellt.

Die Leitung sieht zusätzlich die Auswertung: offene Vorgänge, Alter des ältesten Tickets, Verteilung nach Kategorie. Bauen Sie diese Ebene zuletzt. Solange es unter fünfzig Tickets sind, ersetzt ein Blick in die gefilterte Liste jede Statistik. Wer statt Störungen lieber Wünsche und Ideen sammeln möchte, ist mit Feedback-Board ohne Code erstellen besser bedient.

Was kostet der Aufbau in Credits?

Abgerechnet wird pro Aktion, nicht pro Bearbeiterplatz und Monat. Das ist der wirtschaftliche Kern des Eigenbaus.

Die vier Bildschirme oben ergeben 12 Credits für die ersten drei und 3 für den vierten, zusammen 15 für den ersten Aufbau. Rechnen Sie zehn bis zwölf Änderungen dazu, bis Rollen, Filter und E-Mail-Texte sitzen. Die einsatzbereite Fassung liegt damit bei etwa fünfzig verbrauchten Credits.

Die Tarife: Free gibt 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business 99 $ im Monat mit 800 Credits. Zweihundert Credits entsprechen etwa 16 mehrseitigen Plattformen oder 33 Builds oder 66 Änderungen. Für ein Team, das die App nach dem Aufbau nur noch gelegentlich anpasst, ist Pro reichlich bemessen.

Wie kommen E-Mails ins Spiel?

Hier liegt der wichtigste Unterschied zu fertigen Systemen, und er sollte vor dem Start klar sein.

Ausgehende E-Mails funktionieren über Resend: Eingangsbestätigung an den Melder, Benachrichtigung an das Team, Nachricht bei Statuswechsel, Hinweis auf eine neue Antwort. Wie die Anbindung abläuft, steht in KI-App-Builder mit Resend.

Eingehende E-Mails sind der andere Fall. Ein Postfach zu überwachen und jede Mail automatisch in ein Ticket zu verwandeln, samt Zuordnung von Antworten zum richtigen Vorgang, gehört zu den Stärken gekaufter Systeme. In einem Eigenbau ist das ein umfangreiches Vorhaben und selten die Mühe wert.

Der praktikable Weg: Sie richten das Meldeformular als einzigen offiziellen Kanal ein und lassen auf die Support-Adresse eine automatische Antwort mit dem Link zum Formular laufen. Das wirkt zunächst unhöflich, sortiert aber innerhalb von zwei Wochen den gesamten Zulauf, und danach ist die Liste vollständig statt halb.

Wo hört ein Builder bei einem Helpdesk auf?

Drei ehrliche Grenzen.

Telefonanbindung, Chat-Widget mit Live-Weiterleitung und automatische Sprachverteilung sind eigene Produkte. Sie werden angebunden, nicht nachgebaut, und bei einem wirklich komplexen Produkt ersetzt ein Builder kein Entwicklungsteam.

Sehr spezifische Fachlogik wie Eskalationsregeln über mehrere Stufen mit Zeitfenstern, Feiertagskalender und Vertretungsplan entsteht über viele Änderungen. Das ist machbar, aber es ist Arbeit in Etappen und nicht das Ergebnis eines einzelnen Prompts.

Und die Sandbox-Prüfung vor der Auslieferung stellt sicher, dass die App startet. Ob Ihre Rechteregeln stimmen, prüft sie nicht. Legen Sie vor dem Echtbetrieb ein Testticket an und öffnen Sie den Melder-Link in einem privaten Fenster, um zu sehen, was ein Kunde wirklich zu Gesicht bekommt.

Wie fange ich an?

Schreiben Sie zuerst auf, welche fünf Meldungen bei Ihnen am häufigsten vorkommen. Daraus ergeben sich Kategorien und Pflichtfelder fast von selbst, und das ist die halbe Arbeit am Datenmodell.

Bauen Sie danach zuerst Formular und Liste. Auswertung und interne Notizen kommen als spätere Änderungen dazu, wenn die ersten echten Tickets zeigen, was fehlt. Wenn aus dem Helpdesk später eine Kundenakte mit Historie werden soll, hilft CRM ohne Programmieren erstellen beim nächsten Schritt.

Veröffentlicht läuft das Projekt unter einer Adresse wie support-mueller.zugo.run, eine eigene Domain lässt sich jederzeit verbinden. Starten Sie den ersten Build auf zugo.dev und legen Sie sofort drei echte Tickets an. Nichts zeigt schneller, welche Felder überflüssig sind und welche fehlen.