Baue an einem Tag ein internes Ticket-Triage-Tool mit klarem Datenmodell, Status-Workflow, SLA-Zeiten und Eskalationsbenachrichtigungen — ideal umzusetzen mit visueller Business-Process-Logik.
Wenn Tickets per E-Mail, Chat, Webformular oder schnellen Hinweisen in internen Messengern hereinkommen, taucht dieselbe Anfrage zweimal auf — oder schlimmer: gar nicht. Leute forwarden Screenshots, kopieren Notizen in Tabellen und verlassen sich auf Erinnerung, um Besitz und Zuständigkeiten zu verfolgen. Dringende Anliegen versinken, und die lauteste Nachricht gewinnt.
Manuelle Triage bricht auch bei Übergaben zusammen. Eine Anfrage wird in einem Chat "zugewiesen", dann geht die zugewiesene Person offline und niemand weiß, wie es weitergeht. Stati bedeuten für verschiedene Menschen unterschiedliche Dinge, sodass Manager Dashboards nicht vertrauen können und Anfragende länger warten als nötig.
Verspätete Antworten entstehen meist nicht aus böser Absicht. Sie passieren, wenn es an Struktur fehlt: klare Zuständigkeit, eindeutige Fristen und ein klarer Eskalationspfad.
Ein internes Ticket-Triage-Tool löst das, indem es chaotische Eingänge in einen einfachen, sichtbaren Ablauf verwandelt. Für einen One-Day-Build ist das Ziel nicht ein vollständiges Helpdesk mit jeder Funktion — sondern ein verlässliches Grundgerüst, das später erweitert werden kann.
Am Ende des Tages sollte man vier Dinge erreichen:
Wenn du das in einer visuellen Plattform wie AppMaster abbildest, kannst du den Workflow als Business-Process-Logik modellieren statt Code zu schreiben und ihn dann anpassen, sobald die tatsächlichen Gewohnheiten deines Teams zeigen, was sich ändern muss.
Ein Triage-Tool ist am ersten Tag nur dann nützlich, wenn es drei Dinge zuverlässig tut: Tickets an einem Ort sammeln, einen Besitzer zuweisen und überfällige Arbeit sichtbar machen. Alles andere kann warten.
Wähle anfangs eine oder zwei Ticket-Quellen. E-Mail plus ein einfaches Webformular reichen für die erste Version oft aus. Chat kann später folgen, weil es Lärm (kurze Nachrichten, fehlende Details) hinzufügt und meist zusätzliche Regeln zum Gruppieren und Beschriften benötigt.
Lege fest, wer ein Ticket berührt und was für jede Gruppe "fertig" bedeutet. Halte die Teamstruktur klein und klar. Beispiel: Support kümmert sich um Intake und Basis-Fixes, Ops übernimmt Zugangs- und Account-Aufgaben, Engineering nimmt Bugs und Änderungen, die Code brauchen. Wenn ein Team einen Ticket-Typ nicht bearbeiten kann, sollte ihm dieser Typ nicht zugewiesen werden können.
Für einen realistischen One-Day-Umfang verpflichte dich zu diesen Ergebnissen: Tickets erstellen und anzeigen (Titel, Anfragender, Dringlichkeit, Kategorie), triagieren und zuweisen (Owner plus Team, mit klarem unassigned-Zustand), eine SLA-Uhr verfolgen (First response due und Resolution due), bei Überfälligkeit eskalieren (die richtige Person oder den richtigen Kanal benachrichtigen) und mit einer kurzen Ergebnisnotiz schließen.
Das passt gut zu AppMaster: ein einfaches Datenmodell, ein grundlegendes internes Dashboard und visuelle Business-Process-Logik für Zuweisung und Eskalationsbenachrichtigungen.
Metriken kannst du jetzt überspringen. Erfasse die Rohdaten (Timestamps, Statuswechsel, Assignee-Historie), ohne Berichte zu bauen. Später fügst du Dashboards für Trends wie Time to First Response oder Top-Kategorien hinzu — lass Analytics nicht das Werkzeug verzögern, das die Leute heute brauchen.
Ein guter Schnellcheck: Wenn eine neue Anfrage um 9:00 eintrifft und bis 11:00 niemand darauf schaut, sollte deine erste Version dieses Versäumnis sichtbar und schwer zu übersehen machen.
Ein Triage-Tool scheitert, wenn niemand klar verantwortlich ist. Nenne zuerst die wenigen Rollen, die du wirklich brauchst, und passe die Berechtigungen an die reale Support-Arbeit an.
Die meisten Teams kommen mit vier Rollen weit:
Sichtbarkeit ist die nächste Entscheidung. Wähle ein Modell und bleib dabei, sonst verlieren Leute das Vertrauen in das Tool.
Ein praktischer Ansatz: Requester sehen nur ihre Tickets; Agents sehen Tickets in ihrer Team-Queue; Team leads sehen alle Tickets ihrer Abteilung; Admins sehen alles. Falls Privatsphäre nötig ist, füge ein restricted-Flag hinzu, das nur Leads und Admins öffnen können.
Verantwortlichkeit entsteht durch wenige strikte Regeln, nicht durch eine riesige Berechtigungsmatrix. Beispiel: Nur Leads und Admins dürfen Besitz teamübergreifend ändern; nur der Assignee (oder ein Lead) kann ein Ticket auf Resolved setzen; Schließen erfordert eine Abschlussnotiz und eine Kategorie; Wiedereröffnen erfordert einen Grund.
Zuletzt: fordere eine Audit-Historie. Jede Änderung, die den Service beeinflusst, sollte protokolliert werden: Status, Assignee, Priorität, SLA-Tier und Eskalationen. Speichere, wer es getan hat, wann und welche alten und neuen Werte betroffen waren.
In AppMaster kannst du das mit eingebauter Auth plus einer visuellen Business-Process-Logik durchsetzen, die bei Schlüsseländerungen ein AuditEvent anlegt.
Ein schneller Test: Wenn ein Lead fragt: "Warum wurde dieses Ticket um 18:12 als resolved markiert?", sollte dein System das auf einem Bildschirm ohne Rätselraten beantworten können.
Ein Ticket-Triage-Tool lebt oder stirbt mit seinem Datenmodell. Sind die Tabellen sauber, bleiben Workflow und Dashboard einfach zu bauen (und später leicht änderbar).
Beginne mit fünf Bausteinen in deiner Datenbank (z. B. AppMaster Data Designer mit PostgreSQL):
on_call-Flag hinzu, damit dein Workflow schnell die richtige Person findet.current_assignee_id auf dem Ticket für schnelles Filtern, speichere aber auch jede Neu-Zuweisung mit assigned_by, assigned_to, reason und assigned_at.Ein paar Felder verhindern späteren Schmerz. Füge first_response_due_at und resolve_due_at hinzu (auch wenn du sie berechnest). Speichere last_customer_message_at und last_agent_message_at, damit du Stille entdecken kannst, ohne komplexe Abfragen zu bauen.
Mache Stati und Prioritäten zu Enums (oder Referenztabellen). Das hält Reports konsistent und vermeidet dass "High", "HIGH" und "Urgent!!!" zu drei verschiedenen Prioritäten werden.
Ein Triage-Tool bricht zusammen, wenn Leute nicht sagen können, was ein Status bedeutet. Halte die Menge klein und klar. Eine einfache Basis ist: New, Triaged, In Progress, Waiting, Resolved, Closed. Wenn dein Team über einen siebten Status streitet, ist das meist ein Namensproblem, nicht ein Workflow-Problem.
Stati funktionieren am besten, wenn jeder genau eine Frage beantwortet:
Übergänge entscheiden über Klarheit oder Chaos. Schreibe auf, was wohin wechseln darf und wer es darf. In AppMaster kannst du diese Regeln in visueller Business-Process-Logik erzwingen, sodass die UI nur gültige nächste Aktionen zeigt.
Praktische Regeln, die Chaos fernhalten:
Entscheide, was Timestamps erzeugt, denn das treibt Reports und SLAs an. First response time sollte gesetzt werden, wenn ein Mensch die erste öffentliche Antwort postet. Resolved time sollte beim Wechsel zu Resolved gesetzt werden. Closed time sollte beim Wechsel zu Closed gesetzt werden. Wenn ein Ticket wieder geöffnet wird, behalte die ursprünglichen Timestamps und füge reopened_at hinzu, damit du Wiederholungsfälle sehen kannst, ohne Geschichte zu überschreiben.
Ein SLA ist ein Versprechen mit einer Uhr. Halte es auf die Timer reduziert, die die meisten Teams wirklich nutzen: first response (Jemand bestätigt Empfang), next response (Das Gespräch bewegt sich weiter) und resolution (Das Problem ist gelöst).
Beginne damit, wie du die Regel auswählst. Ein einfacher Ansatz ist nach Priorität. Wenn du auch verschiedene Kundentiers unterstützt, füge eine zusätzliche Unterscheidung hinzu: customer type. So erhältst du vorhersehbare SLA-Regeln ohne einen Berg Ausnahmen.
Speichere SLA-Deadlines als Zeitstempel, nicht nur als Dauern. Behalte beides, wenn du willst, aber der Deadline-Zeitstempel macht Reporting und Eskalationen zuverlässig. Beispiel: Bei Erstellung eines P1-Tickets um 10:00 berechnest und speicherst du FirstResponseDueAt = 10:30, NextResponseDueAt = 12:00, ResolutionDueAt = 18:00.
Definiere, was die Uhr pausiert. Die meisten Teams pausieren next response und resolution, wenn das Ticket in "Waiting on customer" ist, pausieren aber nicht first response.
Sei eindeutig, welches Ereignis als SLA-Erfüllung zählt. Wähle für jeden Timer genau ein Ereignis und bleib dabei: ein Agent-Kommentar, ein Statuswechsel zu In Progress oder eine ausgehende Nachricht.
In AppMaster modellierst du das im Business Process Editor, indem du auf Ticket created, Comment added und Status changed triggerst, dann Deadlines neu berechnest und zurückschreibst.
Ein Ticket-Triage-Tool funktioniert am besten, wenn der Pfad vorhersehbar ist. Strebe einen "Happy Path" an, der die meisten Tickets abdeckt, und halte Ausnahmen sichtbar statt verborgen.
Wenn ein Ticket erstellt wird (aus Formular, E-Mail-Import oder intern), setze automatisch einige Felder, damit nichts halb leer beginnt. Speichere den initialen Status (meist New), eine Default-Priorität (z. B. Normal), den Requester und Timestamps wie created_at und last_activity_at.
Erfasse das Minimum fürs Triage: kurzen Titel, Beschreibung und eine Kategorie oder Service-Area. Fehlt etwas, markiere das Ticket als Incomplete, damit es nicht versehentlich zugewiesen wird.
Triage ist eine kurze Qualitätsprüfung. Bestätige erforderliche Felder, setze eine Kategorie und berechne SLA-Deadlines aus einfachen Regeln (z. B. Priorität + Kundentyp = first response due). In AppMaster kann das ein visueller Business Process sein, der Due-At-Felder schreibt und einen triage_event für das Audit anlegt.
Vor dem Weitergeben: Kurz prüfen, ob das wirklich unser Thema ist. Wenn nicht, route es in die richtige Queue und füge eine kurze Notiz hinzu, damit es nicht hin- und hergeschoben wird.
Zuweisung kann am ersten Tag manuell sein oder regelbasiert (Kategorie -> Team, dann geringste offene Anzahl). Sobald ein Assignee gesetzt ist, bleibt der Status bei Triaged und es wird eine klare Benachrichtigung gesendet, damit Ownership sichtbar ist.
Während der Arbeit sind Statuswechsel wie In Progress oder Waiting on Customer erlaubt. Jede öffentliche Antwort sollte next_response_due aktualisieren, und jeder Kommentar sollte last_activity_at aktualisieren. So bleiben SLA-Tracking und Eskalation zuverlässig.
Resolution erfordert eine kurze Zusammenfassung, einen Resolution-Code (fixed, won’t fix, duplicate) und resolved_at. Close kann nach einer Ruhephase automatisch erfolgen oder manuell nach Bestätigung — speichere aber immer closed_at, damit Reports konsistent bleiben.
Eskalationen scheitern aus zwei Gründen: Sie werden zu oft ausgelöst oder sie sagen dem Empfänger nicht, was als Nächstes zu tun ist. Ziel ist nicht mehr Alerts, sondern ein klares Signal zur richtigen Zeit.
Starte mit Triggern, die sich leicht erklären und testen lassen. Die meisten Teams brauchen nur wenige: SLA in Gefahr (z. B. 75 % der Frist vorbei), SLA gebrochen, kein Assignee nach kurzer Gnadenfrist (10–15 Minuten) und ein Ticket, das zu lange in Waiting steckt.
Leite jeden Trigger an die kleinste Gruppe, die ihn beheben kann. Benachrichtige zuerst den Assignee. Gibt es keinen Assignee, benachrichtige den Team lead oder die On-Call-Rotation. Den Requester benachrichtige nur, wenn du Input brauchst oder die versprochene Lösung veränderst.
Eine gute Eskalationsnachricht enthält Titel, Priorität, aktuellen Status, verbleibende Zeit (oder Überfälligkeit) und einen nächsten Schritt. Beispiel: "Ticket #1842 ist in 30 Minuten bei Breach. Status: In Progress. Owner: unassigned. Nächster Schritt: Owner zuweisen oder Priorität mit Notiz runterstufen."
Nutze Kanäle mit Intention. E-Mail ist OK für "at risk". SMS oder Telegram ist besser für "breached" oder "unassigned critical". In-App-Notifications eignen sich für leise Nudges im Dashboard.
Um Spam zu verhindern, füge einfache Drosselungsregeln hinzu: eine Warnung pro Stage plus eine Cooldown-Periode (z. B. 60 Minuten) bevor wiederholt wird. Ändert sich Status oder Owner, setze den Eskalationstimer zurück.
Protokolliere jede Benachrichtigung, damit du Vertrauensprobleme später debuggen kannst. Mindestens: wann gesendet, durch welchen Trigger, Kanal und Empfänger, und Sendestatus (sent, failed, bounced). Wenn du Bestätigungen (geklickt, geantwortet, als gesehen markiert) erfassen kannst, speichere auch das.
In AppMaster passt das sauber zu einer Notification-Tabelle plus einem Business Process, der Timer prüft, Empfänger auswählt (Assignee, Lead, On-Call) und über Email, SMS oder Telegram sendet sowie einen In-App-Eintrag schreibt.
Führe vor dem Screen-Bau ein hartes Szenario durch. Das zeigt schnell, ob Stati, Deadlines und Benachrichtigungen in der Realität Sinn ergeben.
Es ist 12:10 Uhr. Ein "Zahlung fehlgeschlagen"-Ticket kommt von einem Schlüsselkunden, im Betreff als dringend markiert, aber nicht zugewiesen. Dein Triage-System sollte es als zeitkritisch behandeln, auch wenn zur Mittagszeit niemand auf das Dashboard schaut.
Zuerst triagiert man: Category = Billing und Priority = Urgent. Sobald diese Felder gesetzt sind, berechnet das System die First-Response-Deadline (z. B. 15 Minuten) und speichert sie auf dem Ticket. Diese Deadline sollte in der Listenansicht sichtbar sein, nicht vergraben.
Dann springt Auto-Assignment an. Es wählt den On-Call-Agenten für Billing und sendet eine kurze Nachricht: "Urgent billing ticket assigned. First response due 12:25." In AppMaster passt das natürlich als visueller Business Process: Trigger on ticket creation (oder priority change), dann einige Decision-Blöcke.
Wenn bis 12:25 noch keine öffentliche Antwort da ist, eskaliere. Halte Eskalation simpel und konsistent: benachrichtige den Team lead, füge einen internen Kommentar mit dem verpassten First-Response-SLA hinzu und setze ein escalation_level-Feld (statt einen neuen Status zu erfinden, den Leute missbrauchen würden).
Um 12:40 antwortet der Agent und setzt das Ticket auf Waiting on Customer. Deine SLA sollte währenddessen pausieren. Wenn der Kunde um 14:05 antwortet, setzt die SLA an der Stelle fort, an der sie pausierte — nicht von Null. Dieser Test fängt die meisten Workflow-Fehler ab.
Mit einem Tag Bauzeit erstellst du Screens, die Rückfragen reduzieren: einen Platz für die Queue, einen Platz für Entscheidungen und einen Platz fürs Arbeiten.
Das ist der Home-Screen. Er sollte in 10 Sekunden beantworten, was jetzt Aufmerksamkeit braucht.
Füge Filter hinzu, die dem Triage-Alltag entsprechen: Status, Priorität, SLA-State (on track, at risk, breached), unassigned und Kategorie.
Halte jede Zeile kompakt: Titel, Requester, Priorität, aktueller Owner, SLA-Countdown und letzte Aktualisierung.
Die Detail-Seite sollte sich wie eine einzige Timeline anfühlen. Platziere die wichtigsten Aktionen oben: assign, change status, add comment, set priority. Zeige dann die komplette Historie (Statuswechsel, Zuweisungen, Kommentare) chronologisch.
Mach SLA sichtbar, ohne zu nerven. Ein einfacher Countdown-Label mit Farbe reicht. Ergänze eine klare Escalate-Aktion für Sonderfälle.
Beim Erstellen eines Tickets erfordere die Minimalfelder: Kategorie, kurze Zusammenfassung und Impact. Füge Schnellaktionen wie Assign to me und Mark duplicate hinzu. Wenn möglich, zeige einen vorgeschlagenen Assignee basierend auf Kategorie oder Workload.
Agents brauchen My tickets, Due soon und One-Click-Status-Updates. Leads brauchen Unassigned, At risk und Breached sowie eine Möglichkeit, Zuweisungen schnell neu zu balancieren.
Halte Admin schlank: Kategorien und SLA-Regeln (nach Kategorie und Priorität) verwalten sowie wer in der Rotation ist. In AppMaster sind diese Screens schnell mit UI-Buildern zusammenzubauen, während die Regeln in visueller Business-Process-Logik leben, damit du sie ändern kannst, ohne die App neu zu schreiben.
Die meisten Triage-Tools scheitern aus einfachen Gründen: Regeln sind schwammig und die UI fördert Workarounds statt klare Entscheidungen.
Die erste Falle ist Status-Sprawl. Teams fügen für jeden Randfall einen neuen Status hinzu ("Waiting for Vendor", "Waiting for Finance", "Blocked by Product") und bald versteht niemand mehr, was welcher Status bedeutet. Halte Stati wenige und definiere, was wahr sein muss, um voranzukommen (z. B. In Progress heißt: Ein Assignee ist gesetzt und die nächste Aktion ist bekannt).
SLA-Timing ist die zweite Falle. Eine Uhr, die nie pausiert, bestraft Agenten, wenn sie auf den Requester warten. Eine Uhr, die immer pausiert, macht SLAs bedeutungslos. Wähle explizite Pauseregeln, die sich in einem Satz erklären lassen, und binde sie an eine kleine Menge an Stati (z. B. nur in Waiting pausieren, bei jeder Kunden-Antwort wieder starten).
Benachrichtigungen scheitern oft, weil sie keinen Owner haben. Wenn Alerts an alle gehen, werden sie zum Hintergrundrauschen. Eskalationen sollten an eine bestimmte Person oder Rolle gehen, mit einer klaren Erwartung, was als Nächstes zu tun ist.
Häufige Fehlerbilder:
Ein einfacher Test: Angenommen, ein Ticket wurde eskaliert und der Requester beschwert sich. Kannst du in einer Minute beantworten, wer das Ticket in jedem Schritt besessen hat, wann die SLA pausierte und was extern kommuniziert wurde? Wenn nein, füge einen Audit-Trail hinzu und trenne öffentliche Antworten von internen Notizen. In AppMaster kannst du das mit getrennten Datenfeldern und einem Business Process erzwingen, der nur die richtigen Felder in den jeweiligen Screens zeigt.
Bevor du baust, prüfe mit einem "Können wir das morgen betreiben?"-Mindset. Das Tool funktioniert nur, wenn Daten, Regeln und Benachrichtigungen zueinander passen.
Lücken-Check:
first_response_due_at, resolution_due_at, paused_until).Baue zuerst die Tabellen, dann verknüpfe den Workflow. In AppMaster modellierst du die DB im Data Designer (PostgreSQL), implementierst Status-Transitions, SLA-Timer und Eskalationsregeln im Business Process Editor mit visueller Logik. Starte mit einem Team und einer SLA-Policy, betreibe es eine Woche und füge erst dann Komplexität hinzu (mehr Queues, Geschäftszeiten, individuelle Formulare).
Wenn es stabil wirkt, deploye dort, wo dein Team sich wohlfühlt: AppMaster Cloud, AWS, Azure, Google Cloud oder exportiere den Source Code zum Self-Hosting. Wenn du den Ansatz ohne großen Aufbau ausprobieren willst: AppMaster (appmaster.io) ist für interne Tools wie dieses ausgelegt, mit visuellen Workflows und produktionsbereiten Apps, die aus deinem Modell generiert werden.
Was behebt ein Ticket-Triage-Tool im Alltag?Ein Ticket-Triage-Tool bündelt verstreute Anfragen in eine Warteschlange mit klarer Zuständigkeit, einheitlichen Stati und sichtbaren Fristen. Der größte Gewinn: weniger verpasste oder doppelte Arbeit, weil jederzeit klar ist „wer ist zuständig und was passiert als Nächstes“.
Welche Ticket-Quellen sollte ich in der ersten One-Day-Version aufnehmen?Beginne mit E-Mail plus einem einfachen Webformular — sie liefern in der Regel genug Details und lassen sich leichter standardisieren. Chat kannst du später hinzufügen, wenn du Regeln für Pflichtfelder, Deduplizierung und die Umwandlung kurzer Nachrichten in echte Tickets definiert hast.
Was sind die einfachsten Stati, die das Team nicht verwirren?Verwende eine kleine, leicht erklärbare Menge: New, Triaged, In Progress, Waiting, Resolved, Closed. Halte Stati als Bedingungen statt Gefühle und reguliere, wer zwischen ihnen wechseln darf, damit die Bedeutung konsistent bleibt.
Welche Rollen und Berechtigungen sollte ich zuerst definieren?Standardmäßig vier Rollen: Requester, Agent, Team lead, Admin. So bleiben Berechtigungen leicht verständlich und unterstützen reale Abläufe wie teamübergreifende Neu-Zuweisungen oder das Sperren von Schließrechten.
Welche Tabellen und Felder sind im Datenmodell unverhandelbar?Unverzichtbar sind Tickets, Users, Teams, Comments (public vs internal), AssignmentHistory und ein AuditLog. Ergänze Fälligkeitsfelder wie first_response_due_at und resolve_due_at sowie Felder für „last customer/agent message“, damit SLAs und Silence-Checks nicht komplizierte Abfragen brauchen.
Wie bilde ich SLAs ab, ohne es kompliziert zu machen?Speichere SLA-Deadlines als Zeitstempel auf dem Ticket (nicht nur als Dauer), damit Listen, Alerts und Reports konsistent sind. Ein praktisches Default-Set sind drei Timer: first response, next response und resolution, mit klaren Pauseregeln, die an Stati wie „Waiting on customer“ gebunden sind.
Wie sollte die Zuweisung am ersten Tag funktionieren — manuell oder automatisch?Mach die Zuweisung sichtbar und unmittelbar: immer genau einen Owner, einen expliziten unassigned-Zustand und eine Benachrichtigung an den Assignee (oder On-Call/Lead, wenn unassigniert). Für den ersten Tag ist manuelle Zuweisung okay, solange sie schnell und historisch nachverfolgbar ist.
Welche Eskalationsbenachrichtigungen lohnen sich zuerst?Starte mit wenigen, einprägsamen Triggern: unassigned nach kurzer Frist, SLA at risk, SLA breached und zu lange in Waiting. Jede Benachrichtigung sollte an die kleinste Gruppe gehen, die handeln kann, eine nächste Aktion nennen und gedrosselt werden, um Spam zu vermeiden.
Welche Screens machen das Tool sofort nutzbar?Baue eine Ticketliste (Queue) mit Filtern nach Status, Priorität, SLA-Zustand und unassigned; eine Ticket-Detailansicht mit einer einzigen Timeline; und ein schnelles Intake-/Triage-Formular. Ergänze eine kleine Admin-Ansicht nur für Kategorien, SLA-Regeln und On-Call-Rotation.
Wie hilft AppMaster, dieses Triage-Tool schneller ohne Code zu bauen?AppMaster passt gut, wenn du Workflows als visuelle Business-Process-Logik statt handgeschriebenen Code abbilden willst. Du modellierst PostgreSQL-Daten, erzwingst Statusübergänge, berechnest SLA-Deadlines und verschickst Benachrichtigungen — und generierst dann produktionsbereite Apps, während sich die Prozesse ändern.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
