Wie man ein Kundensupport-Portal mit Greta erstellt

Kurzfassung: Ein Kundensupport-Portal mit Greta lässt sich in 4–6 Tagen realisieren. Kernumfang: Ticket-Einreichung, Statusverfolgung für Kunden, Agenten-Posteingang, Wissensdatenbank mit Suche, Kunde-Agent-Messaging, SLA-Tracking. Ersetzt 50–500 $/Monat, die für Zendesk, Intercom oder Freshdesk ausgegeben werden – für Indie-SaaS, die eigene Infrastruktur und volle Anpassbarkeit wollen. Dieser Leitfaden behandelt das Datenmodell, die Build-Reihenfolge, die KI-gestützte Automatisierung, die tatsächlich hilft (Auto-Kategorisierung, vorgeschlagene Antworten, Wissensdatenbank-Suche), die Integration mit E-Mail und bestehenden Tools sowie die operative Disziplin, die darüber entscheidet, ob Ihr Support-Portal hilfreich ist oder ein weiteres vergessenes Tool wird.

Einführung

Kundensupport-Tools dominieren die SaaS-Tool-Stacks. Zendesk für 55–215 $/Nutzer/Monat. Intercom für 39–139 $/Nutzer/Monat plus KI-Funktionen. Freshdesk für 15–79 $/Nutzer/Monat. HelpScout für 20–50 $/Nutzer/Monat. Für Indie-SaaS mit 1–3 Support-Mitarbeitern bedeuten diese Tools erhebliche Kosten und eine Bindung an generische Workflows, die oft nicht dazu passen, wie der Gründer Support eigentlich abwickeln möchte.

Ein individuelles Kundensupport-Portal mit Greta zu bauen dauert 4–6 Tage für den technischen Kernbau. Sie erhalten Ticket-Einreichung, Statusverfolgung für Kunden, Agenten-Posteingang, Wissensdatenbank mit Suche, Kunde-Agent-Messaging, SLA-Tracking und KI-gestützte Automatisierung. Die Betriebskosten sinken auf 30–80 $/Monat für Hosting und KI-API-Kosten. Wichtiger noch: Der Workflow passt zu Ihrem tatsächlichen Support-Prozess, statt Ihren Prozess an Zendesk anzupassen.

Dieser Leitfaden behandelt den realistischen Build: das Datenmodell, die Build-Reihenfolge, die KI-Funktionen, die wirklich helfen, die E-Mail-Integration und die operative Disziplin, die darüber entscheidet, ob Ihr Portal ein echtes Support-System wird oder ein weiteres Tool, das in Vergessenheit gerät.

Bauen oder kaufen?

Gründe fürs Selberbauen

• Workflow-Passung — Generische Tools erzwingen generische Prozesse; individuelle Builds passen sich Ihrem an
• Kosten im Indie-Maßstab — 30–80 $/Monat statt 200–1.000 $/Monat für kommerzielle Tools
• Code-Eigentum — Echter Next.js/React-Code in GitHub; kein Plattform-Lock-in
• Integrationsfreiheit — Anbindung an Ihre bestehende Produktdatenbank für mehr Kontext
• KI-Anpassung — KI auf Ihrer spezifischen Wissensdatenbank trainieren
• Passende Kundenerfahrung — Das Portal fühlt sich wie ein Teil Ihres Produkts an, nicht wie eine Drittanbieter-Lösung

Gründe fürs Kaufen

• Ausgereifte Support-Workflows, die Sie nicht von Grund auf entwerfen möchten
• Omnichannel von Tag eins nötig (E-Mail + Chat + Telefon + Social)
• Enterprise-Compliance-Anforderungen (SOC 2, HIPAA usw.) mit Audit-Trails
• Team größer als 5 Agenten
• Erweiterte Reports und Analysen erforderlich

Ehrlich gesagt: Die meisten Indie-SaaS mit 0–50.000 $ MRR profitieren von individuellen Builds. Oberhalb von 50.000 $ MRR hängt die Entscheidung vom Support-Volumen und der Teamgröße ab. Oberhalb von 200.000 $ MRR mit 5+ Support-Agenten gewinnen kommerzielle Tools oft aufgrund der Skalenökonomie.

Kernumfang für v1

• Kunden-Ticket-Einreichung (Webformular, optional per E-Mail)
• Kundenportal mit Anzeige der eigenen Tickets und deren Status
• Agenten-Posteingang mit allen Tickets, Filter nach Status/Priorität/Kategorie
• Ticket-Detailansicht mit Konversationsverlauf
• Wissensdatenbank mit Artikel-CRUD und Suche
• Öffentliches Help-Center (Wissensdatenbank + Ticket-Einreichung)
• Kunde-Agent-Messaging innerhalb eines Tickets
• Ticket-Status-Workflow (offen → in Bearbeitung → gelöst → geschlossen)
• SLA-Timer basierend auf Priorität
• E-Mail-Benachrichtigungen (an Kunde und Agent)

Was in v1 wegzulassen ist

• Live-Chat (auf v1.1 verschieben; E-Mail-artiges Messaging reicht für v1)
• Multi-Channel-Aufnahme (E-Mail + Web in v1; Telefon/Social später)
• Teambasierte Zuweisung mit Round-Robin (in v1 einzelner Agent oder manuelle Zuweisung)
• Individuelle Ticket-Formulare pro Kategorie (ein einziges Formular in v1)
• Erweiterte Reports (nur Basis-Metriken in v1)
• Kundenzufriedenheits-Umfragen (auf v1.1 verschieben)
• Makros und Textbausteine (KI-Antwortvorschläge decken das meiste davon in v1 ab)
• Workflow-Automatisierungs-Engine (einfache Status-Flows in v1)

Das Datenmodell

• Customer (id, user_id, email, name, subscription_tier, lifetime_value)
• Ticket (id, customer_id, subject, description, status, priority, category, assigned_to, created_at, first_response_at, resolved_at)
• Message (id, ticket_id, sender_id, sender_type, body, created_at)
• Agent (id, name, email, role)
• Article (id, title, slug, body, category, tags, published_at, view_count)
• Category (id, name, parent_id, description)
• TicketTag (ticket_id, tag) — Many-to-many-Tags für Tickets
• SLAConfig (priority, first_response_minutes, resolution_minutes)

Die 4–6-Tage-Build-Reihenfolge

Tag 1: Grundgerüst, Kundenportal, Ticket-Einreichung

• Stunde 1: PRD (Workflow-Details, Prioritätsstufen, SLA-Ziele)
• Stunde 2–3: Datenmodell aufsetzen (Customer, Ticket, Message, Agent)
• Stunde 4–5: Layout des Kundenportals (Auth, Navigation)
• Stunde 6–8: Ticket-Einreichungsformular (Betreff, Beschreibung, Kategorie, Priorität, Anhänge)

Tag 2: Ticket-Ansicht auf Kundenseite

• Stunde 1–3: Kunden-Ticketliste mit Statusfilter
• Stunde 4–5: Ticket-Detailansicht mit Konversationsverlauf
• Stunde 6–7: Antwortfunktion für Kunden
• Stunde 8: Statusanzeigen und SLA-Sichtbarkeit

Tag 3: Agenten-Posteingang und Ticket-Management

• Stunde 1–3: UI für Agenten-Posteingang (alle Tickets, Filter, Sortierung)
• Stunde 4–5: Ticket-Detailansicht für Agenten mit vollständigem Kundenkontext
• Stunde 6–7: Status-Workflow-Steuerung (zuweisen, Priorität ändern, Status ändern)
• Stunde 8: Interne Notizen (nur für Agenten sichtbare Nachrichten am Ticket)

Tag 4: Wissensdatenbank

• Stunde 1–3: Artikel-CRUD für Admins (erstellen, bearbeiten, veröffentlichen, kategorisieren)
• Stunde 4–5: Öffentliches Help-Center (Artikel durchsuchen und suchen)
• Stunde 6–7: Suche über PostgreSQL-Volltextsuche oder Algolia
• Stunde 8: Artikelanzeige mit verwandten Artikeln

Tag 5: KI-Funktionen und E-Mail-Integration

• Stunde 1–3: KI-Auto-Kategorisierung bei Ticket-Einreichung
• Stunde 4–5: KI-Antwortvorschläge für Agenten unter Nutzung des Wissensdatenbank-Kontexts
• Stunde 6–7: E-Mail-Integration (eingehende Tickets per E-Mail; ausgehende Benachrichtigungen)
• Stunde 8: SLA-Timer-Logik und Alarm bei SLA-Verletzung

Tag 6: Feinschliff, Härtung, Soft-Launch

• Stunde 1–3: Einfaches Metrik-Dashboard (offene Tickets, durchschnittliche Antwortzeit, SLA-Compliance)
• Stunde 4–5: Empty States, Fehlerbehandlung, mobile Responsivität
• Stunde 6–7: RLS und Sicherheits-Review (Kunde sieht nur eigene Tickets; Agenten sehen alle)
• Stunde 8: Soft-Launch — Support-E-Mails auf das Portal umleiten

KI-Funktionen, die wirklich helfen

Auto-Kategorisierung

• Bei Ticket-Einreichung nach Kategorie klassifizieren (Abrechnung, Technik, Feature-Wunsch usw.)
• Ticket-Beschreibung mit Kategorienliste an das LLM übergeben
• Gibt die Kategorie zurück; wird im Ticket-Datensatz gespeichert
• Reduziert den manuellen Triage-Aufwand erheblich
• Kosten: ~0,001 $ pro Ticket; im Indie-Maßstab vernachlässigbar

Antwortvorschläge für Agenten

• Beim Öffnen eines Tickets ruft die KI per Embedding-Suche relevante Wissensdatenbank-Artikel ab
• Die KI generiert einen Antwortvorschlag unter Einbindung des Artikelinhalts
• Der Agent prüft, bearbeitet, sendet (KI-Antworten nicht automatisch versenden)
• Reduziert die Tippzeit deutlich; sorgt für konsistente Antworten im gesamten Team

Intelligente Artikelvorschläge für Kunden

• Bei Ticket-Einreichung die Wissensdatenbank nach passenden Artikeln durchsuchen
• "Das könnte Ihnen helfen" vor dem Absenden anzeigen
• Lenkt einen erheblichen Anteil der Tickets ab
• Kunde hilft sich selbst; Ticketvolumen sinkt

Ticket-Zusammenfassung

• Lange Ticket-Threads werden für neue Agenten, die den Fall übernehmen, zusammengefasst
• Besonders hilfreich bei Übergaben und Eskalationen
• Wird bei Bedarf generiert; nicht vorab berechnet

Sentiment-Erkennung

• Tickets mit frustrierter Kundensprache markieren
• Emotionale Eskalationen priorisieren
• Sparsam einsetzen — Falsch-Positive erzeugen Rauschen

E-Mail-Integrationsmuster

Eingehend: Ticket aus E-Mail

• support@ihrunternehmen.de eingerichtet und per Weiterleitung an einen Webhook geschickt (Resend Inbound, Postmark Inbound oder AWS SES nutzen)
• Der Webhook empfängt die E-Mail-Payload
• Absender, Betreff, Text parsen; neues Ticket erstellen oder an bestehenden Thread anhängen
• Abgleich per Ticket-ID in der Betreffzeile (für Antworten)
• Anhänge verarbeiten (in Supabase Storage speichern)

Ausgehend: Benachrichtigungen per E-Mail

• Kunde erhält eine E-Mail bei Statusänderung des Tickets
• Kunde erhält eine E-Mail, wenn ein Agent antwortet
• Agent erhält eine E-Mail bei Tickets mit hoher Priorität
• Reply-to-Adresse leitet über Parsing zurück zum Ticket

E-Mail-Thread-Management

• Ticket-ID in den Betreff aufnehmen (z. B. "[Ticket #1234] Ihr Betreff")
• Zitierten Antworttext entfernen, wenn er an den Thread angehängt wird
• E-Mail-Signaturen behandeln (nicht in der Ticket-Anzeige einbeziehen)

SLA-Tracking

• SLA-Ziele pro Priorität definieren (z. B. dringend: 1 Stunde bis zur ersten Antwort; normal: 24 Stunden)
• First-Response-SLA — Zeit von Ticket-Erstellung bis zur ersten Agentennachricht
• Resolution-SLA — Zeit von Ticket-Erstellung bis Status = gelöst
• SLA-Timer am Ticket für Agenten sichtbar anzeigen
• Alarm bei Verstoß (Slack, E-Mail an Manager)
• SLA-Timer pausieren, während auf Kundenantwort gewartet wird (Status = wartet auf Kunde)
• SLA-Compliance-Kennzahlen über die Zeit tracken

Kennzahlen, die zählen

Häufige Fehler beim Bau von Support-Portalen

• Die Wissensdatenbank auslassen — Die KB ist Ihre Ticket-Ablenkung. Bauen Sie sie ab Tag eins, auch mit nur 3 Artikeln.
• Chat in v1 bauen — Chat verändert das Betriebsmodell erheblich. E-Mail-artiges Messaging ist einfacher und wirkungsvoll.
• SLAs nicht tracken — Ohne Messung driften Antwortzeiten. Ab Tag 1 tracken.
• KI-Antworten automatisch senden — KI schlägt vor; Menschen senden. Auto-Senden erzeugt peinliche Grenzfälle.
• E-Mail-Integration ignorieren — Die meisten Kunden bevorzugen E-Mail gegenüber Portalen. E-Mail-Eingang ist nicht optional.
• Generische Ticket-Kategorien — Auf Ihr Produkt zugeschnittene Kategorien führen zu besserer Triage.
• Kundenkontext in der Agentenansicht auslassen — Abo-Stufe, jüngste Aktivität, Kontoalter anzeigen. Kontext = besserer Support.
• Support getrennt vom Produkt behandeln — Support offenbart Produktprobleme. Ticketdaten mit Produkt-Analytics verbinden.
• Support-Mitarbeiter einstellen, bevor gemessen wird — Ticketvolumen messen; Einstellungen am tatsächlichen Bedarf ausrichten.
• Das Portal überpolieren — Kunden interessiert Hilfe bekommen, nicht UI-Politur. Funktion vor Form.

Häufig gestellte Fragen

F1: Sollte ich das wirklich selbst bauen statt Zendesk zu nutzen? Hängt von Volumen und Teamgröße ab. Indie-SaaS mit 0–50.000 $ MRR und 1–2 Support-Mitarbeitern profitieren von individuellen Builds. Oberhalb von 50.000 $ MRR mit 3+ Support-Agenten ehrlich prüfen.

F2: Wie handhabe ich Anhänge in Tickets? Supabase Storage für Datei-Uploads. Dateitypen und Größenbeschränkungen serverseitig validieren. Anhänge inline anzeigen (Bilder) oder mit Download-Link (andere Dateien).

F3: Was ist mit Live-Chat? Auf v1.1 verschieben oder ganz weglassen. Live-Chat verändert das Betriebsmodell — erfordert Besetzung während der Geschäftszeiten. E-Mail-artiges Messaging über das Portal ist asynchron und funktioniert für die meisten Indie-SaaS gut.

F4: Können die KI-Funktionen mehrere Sprachen verarbeiten? Ja — LLMs sind mehrsprachig. Auto-Kategorisierung und Antwortvorschläge funktionieren sprachübergreifend. Wissensdatenbank-Artikel müssen übersetzt werden, wenn Sie mehrere Sprachen unterstützen.

F5: Was ist mit Telefon-Support? Die meisten Indie-SaaS verzichten auf Telefon-Support. Falls erforderlich, mit einem Dienst wie Twilio Voice integrieren oder bei kommerziellen Tools bleiben. Telefon bringt erheblichen operativen Mehraufwand.

F6: Wie gehe ich mit Eskalationen um? Eskalationskriterien definieren (Priorität, Alter, Kundenstufe). Den festgelegten Eskalationskontakt benachrichtigen (bei früher Phase oft der Gründer). Eskalationsrate als eigene Kennzahl tracken.

F7: Was, wenn Kunden das Portal nicht nutzen und einfach nur E-Mails schreiben? Auf das Portal-Webhook weitergeleitete Support-E-Mails erfassen alle E-Mails als Tickets. Kunden müssen nichts vom Portal wissen; das Portal ist Ihr Back-Office-Tool.

Fazit

• Kundensupport-Portal mit Greta: 4–6 Tage für den Kernbau. Ersetzt 50–500 $/Monat an kommerziellem Tooling für Indie-SaaS-Teams.
• Kernumfang: Ticket-Einreichung, Statusverfolgung, Agenten-Posteingang, Wissensdatenbank, Kunde-Agent-Messaging, SLA-Tracking, KI-Funktionen (Auto-Kategorisierung, Antwortvorschläge, Artikelvorschläge).
• KI-Funktionen helfen wirklich. Auto-Kategorisierung spart Triage-Zeit. Antwortvorschläge beschleunigen die Bearbeitung. Intelligente Artikelvorschläge lenken Tickets ab. Kosten: Cent-Beträge pro Ticket im Indie-Maßstab.
• E-Mail-Integration ist nicht optional. Die meisten Kunden bevorzugen E-Mail. Eingehendes Parsing über Resend/Postmark/SES; ausgehende Benachrichtigungen über Resend. E-Mail und Portal existieren nebeneinander.

Wenn Sie ein Indie-SaaS-Gründer sind und Ihr Support derzeit in einem gemeinsamen Gmail-Postfach stattfindet, ist ein individuelles Support-Portal ein Build mit hohem ROI. Beginnen Sie mit 4–6 Tagen, um die Kernfunktionalität auszuliefern. Migrieren Sie die Support-E-Mail in Woche 2 auf das Portal-Webhook. Fügen Sie in Woche 3 KI-Funktionen hinzu. Bis Monat 2 arbeitet Ihr Team in einem System, das zu Ihrem Workflow passt – zu einem Bruchteil der kommerziellen Kosten. Die Investition amortisiert sich in 3–6 Monaten durch eingesparte Abogebühren; die Passgenauigkeit des Workflows zahlt sich dauerhaft in Support-Effizienz und Kundenzufriedenheit aus. Das individuelle Support-Portal ist einer der Builds mit dem höchsten internen ROI für Indie-SaaS in 2026 — gehen Sie es gezielt an.