Ticket-Typen gestalten
Sie richten Wice CRM als Administrator ein und möchten Vertriebs- und Service-Prozesse sauber trennen? Dieser Deep-Dive erklärt, wie Sie Ticket-Typen planen, benennen und in der Administration abbilden — mit Design-Regeln, Referenz-Blueprints und Checkliste.
Voraussetzung: Prozessgrundlagen (Ticket, Status, Todo, Kategorien) im CRM-Starter-Kit. Diese Seite setzt dieses Verständnis voraus und wiederholt es nicht.
Was Sie hier lernen
| Thema | Inhalt |
|---|---|
| Entscheidungsrahmen | Wann neuer Ticket-Typ, wann Status, wann Ticket-Kategorie |
| Design-Regeln | Benennung, Pipeline-Umfang, Go-Live-Scope |
| Referenz-Blueprints | Sales und Service als Kopiervorlage |
| Administration | Ticket-Status anlegen, Ticket-Typ zuordnen, testen |
Deep-Dive-Regel: Modellieren Sie Geschäftsprozesse, nicht Abteilungsnamen oder Einzelpersonen. Der Ticket-Typ ist die Schablone des Vorgangs — er legt fest, welche Status-Pipeline ein Ticket durchläuft.
Voraussetzungen
| Voraussetzung | Wo |
|---|---|
| CRM-Starter-Kit gelesen | Tickets, Status, Todo, Kategorien |
| Admin-Rechte | Mehr → Administration |
| Prozess auf Papier skizziert | Admin-Checkliste Phase 0/2 |
| Optional: Benutzergruppen geklärt | Benutzerrechte-Starter-Kit |
Go-Live-Regel: Starten Sie mit höchstens 2–3 Ticket-Typen (typisch Sales + Service). Erweitern Sie die Landschaft erst nach einigen Wochen Live-Betrieb — auf Basis von Team-Feedback und Auswertungen.
Drei Ebenen: Typ, Status, Kategorie
| Ebene | Frage | Wo in Wice | Wann ändern |
|---|---|---|---|
| Ticket-Typ | Welcher Prozess? | Administration → Ticket-Typen | Selten — neue Geschäftslinie |
| Status (Ticket-Status) | Wo in der Pipeline? | Derselbe Bereich → Ticket-Status | Gelegentlich — Pipeline verfeinern |
| Ticket-Kategorie | Wofür werten wir aus? | Administration → Kategorien → Ticket | Öfter — Lead-Quelle, Verlustgrund |
Abgrenzung: Das Feld Kategorie beim Ticket-Typ (z. B. Sales, Service) ist keine Auswertungs-Kategorie — es gruppiert Typen in Menüs und Filtern. Ticket-Kategorien am Vorgang selbst richten Sie separat ein (CRM-Starter-Kit Schritt 4, Kategorien anpassen).
Entscheidungsbaum: Wann ein neuer Ticket-Typ?
| Situation | Empfehlung | Beispiel |
|---|---|---|
| Gleiche Teams, gleiche KPI, gleiche Phasen | Ein Typ | Neukundengewinnung |
| Andere Pipeline, andere Abschlusskriterien | Neuer Typ | Key Account vs. Standardvertrieb |
| Andere Abteilung / andere Kennzahlen | Neuer Typ | Sales vs. Support |
| Nur andere Auswertungsmerkmale | Ticket-Kategorien | Lead-Quelle Messe vs. Website |
| Wiederkehrende Standard-Schritte | Workflow ergänzen | Onboarding-E-Mails im Service |
| Anwender sehen „falsche“ Status | Typ trennen | Support-Status in Sales-Pipeline |
Design-Regeln
Benennung
| Regel | Gut | Schwach |
|---|---|---|
| Prozess benennen | Neukundengewinnung | CRM-Ticket |
| Anwender verstehen es sofort | Technischer Support | Typ B |
| Optional: Nummernprefix für Sortierung | 40 Angebot erstellt | Angebot (ohne Reihenfolge) |
Status-Pipeline pro Typ
| Regel | Richtwert |
|---|---|
| Meilensteine pro Typ | 4–8 am Start |
| Status = erreichtes Ziel | Qualifiziert — nicht „Telefonieren“ |
| Abschluss explizit | Gewonnen und Verloren (Sales); Gelöst und Geschlossen (Service) |
| 3-Sekunden-Regel | Jeder Status in einem Satz erklärbar |
Typ-Landschaft
| Regel | Begründung |
|---|---|
| Max. 2–3 Typen zum Go-Live | Schulbarkeit und Akzeptanz |
| Kein „Alles-Ticket“ | Pipeline und Auswertung bleiben nutzbar |
| Kein Typ pro Mitarbeiter | Typ = Prozess, nicht Person |
Referenz-Blueprints
Zwei Muster für KMU — anpassen, nicht blind kopieren:
Blueprint A: Vertrieb (Sales)
| Element | Vorschlag |
|---|---|
| Ticket-Typ | Neukundengewinnung |
| Kategorie (am Typ) | Sales |
| Status (Life Cycle) | Qualifiziert → Angebot erstellt → Verhandlung → Gewonnen / Verloren |
| Ticket-Kategorien | Lead-Quelle, Branche, Verlustgrund |
| Vertiefung | Sales-Ticket im Vertrieb |
Blueprint B: Service / Support
| Element | Vorschlag |
|---|---|
| Ticket-Typ | Technischer Support |
| Kategorie (am Typ) | Service |
| Status (Life Cycle) | Neu → In Bearbeitung → Warten auf Kunde → Gelöst → Geschlossen |
| Ticket-Kategorien | Fehlerart, Priorität |
| Vertiefung | Service-Ticket im Support |
Hinweis: Konkrete Status-Bezeichnungen können in Ihrem Mandanten abweichen — entscheidend ist die inhaltliche Reihenfolge im Prozess.
Der Deep-Dive in drei Schritten
| Schritt | Inhalt |
|---|---|
| 1 | Ticket-Status (Meilensteine) anlegen |
| 2 | Ticket-Typ anlegen und Life Cycle zuordnen |
| 3 | Testen und Anwender einweisen |
Schritt 1: Ticket-Status anlegen
Die Statuswerte einer Pipeline legen Sie im Bereich Ticket-Status an — auf derselben Administrationsseite wie die Ticket-Typen.
- Öffnen Sie Mehr → Administration → Ticket-Typen.
- Im oberen Bereich Ticket-Status klicken Sie auf + Ticket-Status hinzufügen.
- Vergeben Sie eine Bezeichnung (optional mit Nummernprefix) und ggf. eine Farbe.
- Wiederholen Sie das für alle Meilensteine Ihrer Pipeline (4–8 Status pro geplantem Typ).
- Speichern Sie jeden Status.
Deep-Dive-Regel: Legen Sie Status als Meilensteine an — Tätigkeiten wie „Anrufen“ oder „E-Mail schreiben“ gehören in Todos, nicht in die Status-Liste.
Schritt 2: Ticket-Typ anlegen
- Bleiben Sie auf Administration → Ticket-Typen.
- Im Bereich Ticket-Typen klicken Sie auf + Ticket-Typ hinzufügen (oder bearbeiten Sie einen bestehenden Typ über mehr → Bearbeiten).
- Füllen Sie die Felder aus:
| Feld | Funktion |
|---|---|
| Bezeichnung * | Name des Prozesses — erscheint beim Ticket anlegen |
| Kategorie * | Obergruppe, z. B. Sales oder Service — steuert Gruppierung in Filtern und Menüs |
| Life Cycle | Mehrfachauswahl der Ticket-Status, die zu diesem Typ gehören — Reihenfolge = Prozess-Pipeline |
- Klicken Sie auf Speichern.
Ticket-Kategorien (Auswertung) — optional vor Go-Live
Auswertungs-Kategorien am Vorgang (Lead-Quelle, Verlustgrund) richten Sie unter Administration → Kategorien → Ticket ein — nicht auf der Ticket-Typen-Seite.
Schritt 3: Testen und einweisen
| Prüfpunkt | Erwartung |
|---|---|
| Testticket anlegen | Nur Status des gewählten Typs in der Status-Leiste |
| Kanban öffnen | Spalten entsprechen dem Life Cycle des Typs |
| Falscher Typ gewählt | Pipeline passt nicht zum Vorgang — Typ wechseln oder neu anlegen |
| Web-Formular / Wice Contact | Hinterlegter Standard-Typ erzeugt den richtigen Prozess |
Einweisung für Anwender: Welcher Typ wann? Sales für Neukunden und Angebote, Service für Support — nicht mischten. Vertrieb: Sales-Ticket-Leitfaden.
Was Ticket-Typen in Wice steuern
| Bereich | Auswirkung |
|---|---|
| Ticket anlegen | Dropdown-Auswahl; steuert sichtbare Status |
| Status-Leiste | Nur Ticket-Status aus dem Life Cycle |
| Kanban | Spalten = Status des gewählten Typs |
| Ticket-Hauptansicht | Filter nach Typ und Status |
| Web-to-Lead / Wice Contact | Fest verdrahteter Typ bei Formular-Eingang |
| Workflows | Status-Änderungen pro Step — nur passende Status wählbar |
| Kampagnen | Ticketkriterien in Adresslisten — indirekt typabhängig |
Häufige Fehler
| Symptom | Ursache | Maßnahme |
|---|---|---|
| 15+ Status, niemand pflegt sie | Status-Inflation | Auf 4–8 Meilensteine reduzieren; Tätigkeiten → Todos |
| Vertrieb und Service in einer Pipeline | Ein Typ für alles | Typen trennen |
| Status „E-Mail geschickt“ | Tätigkeit als Status | Todo + passender Meilenstein |
| Kanban unübersichtlich | Zu viele Status-Spalten | Status konsolidieren |
| Anwender wählen falschen Typ | Unklare Benennung | Namen schärfen, einweisen |
| Web-Lead im falschen Prozess | Falscher Typ im Plugin | Wice Contact prüfen |
| Auswertung ohne Aussage | Keine Ticket-Kategorien | CRM-Starter-Kit Schritt 4 umsetzen |
| Änderung an laufenden Tickets | Typ nachträglich umgebaut | Zuerst im Testmandant prüfen; ggf. Wice-Support |
Checkliste: Typ-Landschaft fertig
- CRM-Starter-Kit verstanden (Status vs. Todo)
- Prozess auf Papier: max. 2–3 Typen, je 4–8 Status
- Ticket-Status angelegt
- Ticket-Typen mit Kategorie und Life Cycle gespeichert
- Testticket + Kanban-Stichprobe OK
- Ticket-Kategorien für Auswertung eingerichtet (optional)
- Vertrieb/Service eingewiesen
Betrieb nach Go-Live
| Situation | Empfehlung |
|---|---|
| Team verwechselt Status zwischen Prozessen | Neuen Typ statt weiterer Status |
| Pipeline zu grob | Status innerhalb eines Typs ergänzen |
| Pipeline zu fein | Status zusammenlegen; Todos für Zwischenschritte |
| Neues Geschäftsfeld | Eigenen Typ prüfen — nicht alles in Sales erweitern |
Deep-Dive-Regel: Erweitern Sie Strukturen bewusst und selten. Jede Änderung betrifft Schulung, Auswertungen und ggf. Workflows.
Siehe auch
- CRM-Starter-Kit — Prozessgrundlagen
- Admin-Checkliste: Go-Live-Fahrplan — Phasen und Reihenfolge
- Kategorien anpassen — Ticket-Kategorien und Adresskategorien
- Ticket-Hauptansicht — Filter und Suche
- Kanban-View für Tickets — visuelle Pipeline
- Workflow anlegen — Standardabläufe automatisieren