HubSpot Service Prozess aufsetzen: Komplett automatisiert in 4 Schritten

Anfragen kommen über E-Mail, das Kontaktformular, WhatsApp und das Telefon herein. Niemand im Team weiß, was wo offen ist. Tickets liegen in Outlook-Ordnern, SLAs nur in den Köpfen der Mitarbeiter, Eskalationen passieren nach Bauchgefühl. Am Ende wartet ein Kunde vier Tage auf eine Antwort, die in fünf Minuten beantwortbar gewesen wäre. Genau hier setzt ein sauber aufgesetzter Service Prozess in HubSpot an: eine Oberfläche, klare Regeln, Automatisierung dort wo der Mensch sich wiederholen würde.

Was ist ein Service Prozess in HubSpot überhaupt?

Ein Service Prozess in HubSpot bündelt alle Kundenanfragen in einer zentralen Oberfläche. Egal ob der Kunde per E-Mail schreibt, ein Formular ausfüllt, im Chat anfragt oder anruft, jede Anfrage landet als Ticket im selben System. Genau dieses Ticket ist das zentrale Objekt im HubSpot Service Hub, vergleichbar mit einem Deal im Sales-Bereich.

Drei Bausteine bilden zusammen den Service Prozess:

• Tickets als datentragendes Objekt. Jedes Ticket hat eine Kategorie, eine Priorität, eine Quelle, einen zuständigen Mitarbeiter und eine Pipeline-Stage.
• Conversations Inbox als zentraler Posteingang. Alle Kanäle (E-Mail, Live-Chat, Formulare, später WhatsApp und Facebook Messenger) laufen in eine Inbox, aus der heraus Tickets erstellt oder zugewiesen werden.
• Automatisierung über Workflows. Routing, SLA-Tracking, Eskalation, Bewertungsmails laufen automatisch im Hintergrund.

Service Hub ist in drei Tier verfügbar. Starter (15€ pro User) deckt Tickets, einfache Automation und eine Inbox ab. Professional (90€ pro User) bringt SLAs, Custom-Reports, Knowledge Base und Customer Portal. Enterprise (130€ pro User) ergänzt Playbooks, erweiterte Berechtigungen und Workflow-Erweiterungen. In der Praxis sind Starter für kleine Teams bis 3 Service-Mitarbeiter ausreichend, Professional wird Pflicht sobald SLAs, Knowledge Base oder Customer Portal benötigt werden.

Ein wichtiger Punkt der oft übersehen wird: Tickets sind nativ mit Kontakten, Unternehmen und Deals verknüpft. Wenn ein Bestandskunde im Service ein Ticket öffnet, sieht der Service-Mitarbeiter sofort die Sales-Historie, die letzten Marketing-E-Mails und alle bisherigen Tickets. Diese 360°-Sicht ist der eigentliche Hebel gegenüber externen Helpdesk-Tools.

Wie legst du eine Ticket-Pipeline richtig an?

Die Pipeline ist das Rückgrat des Service Prozesses. Hier definierst du, welche Phasen ein Ticket durchläuft und welche Logik dahinter steht. Eine Pipeline lebt davon, dass sie übersichtlich bleibt. In über 90 Setups sehen wir immer wieder denselben Fehler: Teams legen 12 Stages an, weil sie jedes Detail abbilden wollen, und keiner pflegt die Pipeline am Ende sauber.

Unser Standard-Setup hat sechs Stages, mehr ist selten nötig:

1. Neu: Ticket wurde erstellt, niemand ist zugewiesen. Pflichtfelder: Quelle, Kategorie.
2. In Bearbeitung: Mitarbeiter ist zugewiesen, arbeitet aktiv am Ticket. Pflichtfeld: Owner.
3. Wartet auf Kunde: Service hat geantwortet, Reaktion vom Kunden steht aus. Wird automatisch gesetzt sobald eine E-Mail vom Mitarbeiter rausgeht.
4. Wartet auf Drittpartei: Externer Dienstleister, Lieferant oder Hersteller ist involviert. Pflichtfeld: Notiz mit Status der Anfrage.
5. Gelöst: Problem ist behoben, Bestätigung steht aus.
6. Geschlossen: Ticket ist abgeschlossen, Bewertungsmail geht raus.

Eugen erklärt im Video einen wichtigen Automatisierungs-Trick: Tickets in „Wartet auf Kunde" wandern nach 10 Tagen Stille automatisch in „Gelöst". Das verhindert, dass alte Tickets ewig in der Pipeline hängen bleiben und das Reporting verzerren. Wenn der Kunde dann doch noch antwortet, öffnet ein Workflow das Ticket automatisch wieder und schiebt es zurück in „In Bearbeitung".

Pflichtfelder pro Stage zu setzen wirkt erst nach Schikane, ist aber Daten-Hygiene. Wenn ein Ticket in „Geschlossen" landet ohne dass Kategorie, Lösung und Aufwand befüllt sind, ist das Reporting wertlos. HubSpot kann diese Felder erzwingen, sodass der Mitarbeiter sie ausfüllen muss bevor das Ticket weitergeschoben werden kann.

Ticket-Properties gehören zur Pipeline-Architektur dazu. Standard sind Kategorie, Priorität, Quelle und Owner. Zusätzlich empfehlen wir eine Property „Produkt" oder „Modul" damit du auswerten kannst, welcher Bereich deines Angebots die meisten Tickets produziert. Diese Daten fließen später in die Reports und sind Gold wert für Produkt-Entscheidungen.

Wie richtest du SLA und Routing sauber ein?

SLA steht für Service Level Agreement. In HubSpot heißt das konkret: Du definierst, wie schnell ein Ticket erste Antwort bekommen muss (First-Response-Time) und wie schnell es spätestens gelöst sein soll (Resolution-Time). HubSpot misst diese Zeiten automatisch, sobald ein Ticket erstellt wird, und schlägt Alarm bevor die SLA reißt.

SLAs sind im Service Hub Professional verfügbar. Im Starter musst du das über Workflows nachbauen, was machbar aber unschöner ist. Wer Service Hub ernsthaft fährt, kommt um Professional kaum herum.

Bevor du SLAs einstellst, definiere zwei Dinge:

• Geschäftszeiten: Montag bis Freitag, 9 bis 17 Uhr beispielsweise. SLA-Timer pausieren außerhalb der Geschäftszeiten. Ein Ticket das Freitag 16:50 reinkommt, gilt nicht am Samstag morgen als verletzt.
• SLA pro Priorität: Hohe Priorität ist nicht gleich niedrige Priorität. Standard-Setup: hoch = 1h First-Response / 4h Resolution, mittel = 4h / 24h, niedrig = 24h / 72h. Anpassen je nach Geschäftsmodell.

Routing ist der zweite Pfeiler. Tickets sollen nach klaren Regeln zum richtigen Mitarbeiter wandern, statt random verteilt zu werden. Drei Patterns sehen wir in der Praxis am häufigsten:

• Skill-basiert: Rechnungsprobleme an die Finanzbuchhaltung, technische Probleme an den 2nd-Level-Support, Onboarding-Fragen an das Customer Success Team. Routing erfolgt anhand der Ticket-Kategorie.
• Sprach-basiert: Deutsche Tickets an das DACH-Team, englische an das internationale Team. Erkennung über Formular-Feld oder über die Kontakt-Property „Sprache".
• Round-Robin oder Load-Balancing: Tickets werden gleichmäßig auf das Team verteilt, sodass keine Person überlastet wird. HubSpot bringt das nativ mit, sobald die Team-Mitglieder einer Inbox-Owner-Liste zugewiesen sind.

Routing und SLA gehören zusammen gedacht. Wenn ein VIP-Kunde (etwa Enterprise-Vertrag) ein Ticket öffnet, soll das Ticket sofort an den Account Manager gehen und parallel eine Slack-Nachricht an den Team-Lead schicken. Diese Kombination aus Routing-Regel plus Benachrichtigungs-Workflow erzeugt das, was Kunden als „die wurden gleich aktiv" empfinden.

Welche Workflows automatisieren den Service Prozess?

Workflows sind der Hebel, der einen manuellen Service Prozess in einen automatisierten verwandelt. HubSpot Workflows kommen mit If/Then-Verzweigungen, zeitgesteuerten Aktionen und nativen Integrationen in Slack, E-Mail und externe Systeme. Sechs Workflow-Patterns sehen wir in fast jedem produktiven Service-Setup:

1. Auto-Antwort bei Ticket-Erstellung. Sobald ein Ticket angelegt wird, geht eine Bestätigungsmail an den Kunden mit Ticket-Nummer, Zusammenfassung der Anfrage und erwarteter Antwortzeit. Schließt die Unsicherheits-Lücke beim Kunden komplett.
2. Eskalation bei SLA-Verletzung. 75% der SLA-Zeit erreicht und kein Owner antwortet, Slack-Nachricht an den Team-Lead. 100% erreicht, E-Mail an den Service Manager.
3. VIP-Routing. Ticket von einem Enterprise-Kunden oder einem Account mit Deal-Volumen über X € löst sofort eine Benachrichtigung an den zuständigen Account Manager aus.
4. Auto-Move nach Inaktivität. Tickets in „Wartet auf Kunde" wandern nach 10 Tagen ohne Antwort in „Gelöst". Wenn der Kunde später doch noch antwortet, öffnet ein zweiter Workflow das Ticket automatisch wieder.
5. Re-Open bei neuer Antwort. Geschlossene Tickets, auf die der Kunde innerhalb von 14 Tagen erneut antwortet, werden automatisch wieder geöffnet und beim ursprünglichen Owner platziert.
6. Bewertungs-Mail nach Ticket-Abschluss. 24 Stunden nach Schließen geht eine Umfrage mit NPS-Score an den Kunden raus. Antworten landen automatisch in den Reports.

Ein Workflow-Pattern aus dem Video, das wir bei Kunden besonders gerne einsetzen: Sobald ein Mitarbeiter beim Schließen des Tickets eine Aufwandschätzung größer als 7 (von 10) eingibt, geht automatisch ein Ticket an den Service Manager mit Notiz „Hoher Aufwand, bitte Review durchführen". Damit lösen aufwendige Tickets aktiv eine Review-Schleife aus, in der nach Prozess-Verbesserungen gesucht wird. Kein Durchrutschen durchs Raster.

Wichtig: Workflows sollen den Mitarbeiter entlasten, nicht überfordern. Wenn jedes Ticket fünf parallele Notifications auslöst, schaltet das Team die Benachrichtigungen aus und die Automation läuft ins Leere. Lieber drei robuste Workflows die wirklich genutzt werden, als 15 verschachtelte Konstrukte die keiner mehr versteht.

Wie baust du Knowledge Base und Self-Service auf?

Der schnellste Service ist der, bei dem der Kunde sich selbst hilft. Eine HubSpot Knowledge Base ist ein durchsuchbares Hilfe-Center auf deiner Domain, das aus kategorisierten Artikeln besteht. Verfügbar ab Service Hub Professional, mit eigener Domain und voller Anpassbarkeit an dein Branding.

Der typische Aufbau einer Knowledge Base:

• Kategorien wie „Erste Schritte", „Rechnung & Abrechnung", „Technische Fragen", „Integrationen".
• Artikel pro Kategorie, jeder Artikel beantwortet eine konkrete Frage in 3-5 Absätzen plus Screenshots.
• Suchfunktion integriert, sodass Kunden direkt nach Stichwort suchen.
• Bewertungs-Widget unter jedem Artikel („War dieser Artikel hilfreich?"). Antworten landen im Reporting.

Knowledge Base wirkt erst im Verbund mit drei weiteren Bausteinen:

• Chatbot mit FAQ-Antworten. Der Bot prüft die Frage gegen die Knowledge Base und gibt direkt einen Link auf den passenden Artikel zurück. Erst wenn der Kunde sagt „das hilft mir nicht", wird ein Ticket erstellt.
• Customer Portal. Kunden können ihre eigenen Tickets einsehen, kommentieren und neue öffnen. Reduziert die „Wo steht mein Ticket?"-Anfragen drastisch.
• Artikel-Vorschläge im Ticket. Wenn der Mitarbeiter ein Ticket bearbeitet, schlägt HubSpot relevante Knowledge-Base-Artikel vor, die er per Klick an den Kunden schicken kann.

Self-Service-Quote ist die Kennzahl, die du verfolgen solltest. Wie viele Anfragen kommen rein im Verhältnis zu wie vielen Knowledge-Base-Aufrufen? Wer pro 100 Knowledge-Base-Views nur 20 Tickets bekommt, hat einen funktionierenden Self-Service-Layer.

Häufiger Fehler: Knowledge Base wird einmalig angelegt, aber nicht gepflegt. Artikel veralten, Produkte ändern sich, neue Fragen kommen auf. Wir empfehlen eine monatliche Review-Routine, in der die Top-10-Tickets der letzten 30 Tage geprüft werden. Wiederkehrende Fragen ohne Knowledge-Base-Artikel werden direkt in einen neuen Artikel überführt.

Welche Fehler sehen wir im Service-Setup am häufigsten?

Aus über 90 HubSpot-Projekten und Dutzenden Service-Setups kristallisieren sich fünf typische Stolperfallen heraus. Wer diese vermeidet, ist schon weiter als 80% der Teams die wir sehen.

1. Zu viele Pipeline-Stages. 12 Stages bilden die Realität nicht besser ab. Sie garantieren, dass nach 4 Wochen niemand mehr die Pipeline pflegt. 6 Stages reichen für 95% aller Service-Setups.
2. SLAs definiert, aber nicht durchgesetzt. Der Manager sieht im Report dass SLAs verletzt werden, kann aber nicht eingreifen. Lösung: Eskalations-Workflow bei 75% der SLA-Zeit, der proaktiv vor dem Bruch warnt.
3. Tickets nicht an Kontakte verknüpft. Wenn Tickets als isolierte Objekte ohne Kontakt-Verknüpfung leben, geht die 360°-Sicht verloren. Service sieht den Kunden, Sales sieht den Kunden, beide sehen sich nicht gegenseitig.
4. Kein Routing. Alle Tickets landen bei einer Person, die als Triage-Stelle alles weiterverteilen muss. Diese Person wird zum Bottleneck. Sauberes Routing nach Kategorie, Sprache oder Round-Robin löst das in einer Stunde Setup.
5. Knowledge Base wird angelegt, aber nicht gepflegt. 20 Artikel zum Launch, danach drei Jahre Funkstille. Resultat: Self-Service-Quote bleibt bei 5%, weil die Artikel zu alt oder zu generisch sind. Monatliche Review-Routine ist Pflicht.

Ein sechster Fehler den wir bei Sales-getriebenen Unternehmen oft sehen: Service Hub wird parallel zu einem bestehenden Helpdesk-Tool wie Zendesk oder Freshdesk betrieben. Service-Tickets liegen in Tool A, Sales-Kontakte in HubSpot. Die 360°-Sicht ist damit kaputt, beide Teams arbeiten an unterschiedlichen Datenbeständen. Wer Service Hub ernsthaft einsetzt, sollte konsolidieren, statt Doppel-Strukturen zu fahren. Migration aus Zendesk oder Freshdesk dauert 2-4 Wochen je nach Datenmenge.

Wer unsicher ist ob sein bestehendes HubSpot-Setup sauber läuft, kann mit einem HubSpot Audit starten. Wir schauen die Konfiguration durch und identifizieren die größten Hebel. Wer den Service Prozess von Grund auf neu aufsetzen will, ist im HubSpot Setup richtig. Laufende Optimierung übernehmen wir im HubSpot Admin.

Häufige Fragen zum HubSpot Service Prozess