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.

Administration: Ticket-Status und Ticket-Typen — Übersicht

Ticket-Status: Meilensteine der Pipeline

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

Neuer Ticket-Typ: Bezeichnung, Kategorie, Life Cycle

Ticket-Typ bearbeiten: Life Cycle Neukundengewinnung

Klicken Sie auf Speichern.

Ticket-Typen-Liste im Mandanten

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.

Kategorien: Ticket-Kategorien für Auswertung

Kurzvideo

Das Video zeigt das Anlegen eines Ticket-Typs mit Life Cycle in der Administration.

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

Ticket anlegen: Ticket-Typ wählen

Kanban: Pipeline des gewählten Ticket-Typs

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-Starter-Kit — Standardabläufe automatisieren (Einstieg)
Workflow anlegen — Experten-Referenz