Freshdesk-Automatisierungsregeln: So funktionieren sie und so richtest du sie ein (2026)

Was "Automatisierungsregeln" in Freshdesk wirklich bedeutet

Wenn du im Freshdesk-Admin-Bereich nach "automations" gesucht hast, ist dir wahrscheinlich aufgefallen, dass die Namen nicht zu der Hälfte der Tutorials im Netz passen. Das liegt daran, dass Freshdesk seine drei klassischen Regeltypen still umbenannt hat. Die alten Bezeichnungen Dispatch'r, Observer und Supervisor (bzw. Time Triggers) sind aus der Oberfläche verschwunden. Heute siehst du Ticket Creation, Ticket Updates und Hourly Triggers, alle unter Admin > Workflows > Automations, jeweils auf einem eigenen Tab.

Die Mechanik darunter hat sich nicht geändert. Jede Regel besteht aus Bedingungen (wenn X zutrifft) und Aktionen (tue Y), und Freshdesks eigene Übersicht zu Automatisierungsregeln bestätigt, dass es genau drei Typen gibt. Was sich zwischen ihnen unterscheidet, ist, wann die Regel zum Zug kommt.

Das ist die Ebene, die die meisten meinen, wenn sie von "Freshdesk-Automatisierungsregeln" sprechen, und sie ist getrennt von zwei Nachbarn, die wir später behandeln: Szenario-Automatisierungen (manuelle Makros) und die automatische Ticketzuweisung. Wenn du die gesamte Automatisierungslandschaft der Plattform sehen willst, bietet unser vollständiger Leitfaden zur Freshdesk-Automatisierung den weiteren Blick; dieser Artikel bleibt bei der Regel-Engine selbst.

Die drei Arten von Freshdesk-Automatisierungsregeln

Das ganze Modell wird verständlich, sobald du aufhörst, darüber nachzudenken, was jede Regel tut, und stattdessen darüber nachdenkst, wann sie laufen darf. Hier das Timing auf einen Blick.

1. Ticket-Creation-Regeln (früher Dispatch'r)

Diese laufen in dem Moment, in dem ein Ticket erstellt wird, was sie zu deiner Eingangstür für die Triage macht. Laut Freshdesks Dokumentation zur Ticket-Erstellung kann eine Creation-Regel das Ticket einer Gruppe oder einem Agenten zuweisen, Eigenschaften wie Status, Priorität und Typ setzen, E-Mail-Benachrichtigungen auslösen oder Tickets löschen und als Spam markieren. Bedingungen lassen sich auf Ticketfeldern, Kontakteigenschaften oder Firmeneigenschaften aufbauen, mit UND/ODER-Operatoren und verschachtelten Blöcken.

Es gibt hier eine Einstellung, über die fast jeder stolpert. Standardmäßig läuft nur die erste passende Regel. Freshdesks eigene Dokumentation warnt: "Die Reihenfolge der Regeln ist sehr wichtig, da nur die erste passende Regel ausgeführt wird." Wenn also eine Regel auslösen sollte und es nicht tut, ist der übliche Übeltäter eine weiter oben stehende Regel, die zuerst gegriffen und die Kette gestoppt hat. Um das zu ändern, klicke auf das Zahnrad über der Regelliste und wähle "Execute all matching rules".

Diesen Regeltyp nutzt du, wenn neue Tickets sortiert sein sollen, bevor ein Agent sie überhaupt sieht: Rechnungsfragen an die Finance-Gruppe leiten, alles von einem VIP-Unternehmen auf hohe Priorität setzen oder einen Autoresponder senden, der den Eingang bestätigt. Das ist das Nächste, was die klassische Engine an Triage schafft, aber sie kann nur nach den Feldern sortieren, die du ihr vorgibst, nicht danach, worum es im Ticket tatsächlich geht.

2. Ticket-Updates-Regeln (früher Observer)

Während Creation-Regeln einmalig am Anfang auslösen, "lauschen" Ticket-Update-Regeln "ständig auf die von dir festgelegten Ereignisse", gleichen sie mit Bedingungen ab und handeln dann. Sie sind die reaktive Ebene: ein gelöstes Ticket wieder öffnen, wenn ein Kunde antwortet, einen Agenten zuweisen, wenn ein Dritter eine Notiz hinzufügt, eine CSAT-Umfrage senden, wenn ein Ticket gelöst wird, oder einen Supervisor per E-Mail informieren, wenn ein VIP schlecht bewertet.

Was Update-Regeln auszeichnet, ist der Ereignisblock oben, den die anderen beiden Regeltypen nicht haben. Er besteht aus zwei Teilen: "wenn eine Aktion ausgeführt wird von" (Agent, Anfragende:r, beide, ein Kollaborator oder das System) und "betrifft eines dieser Ereignisse" (eine geänderte Eigenschaft, eine hinzugefügte Notiz, eine gesendete Antwort, erhaltenes Feedback, plus Systemereignisse wie überfällige Tickets). Bedingungen und Aktionen funktionieren darunter wie gewohnt.

Anders als bei Creation-Regeln gibt es hier keinen Schalter für "nur die erste Übereinstimmung": "Alle passenden Regeln werden von oben nach unten ausgeführt." Update-Regeln bringen außerdem eine Trigger webhook-Aktion mit, mit der du Freshdesk zu externen Systemen erweiterst, derselbe Anschluss, den unser Leitfaden zu Freshdesk-Webhooks durchgeht, und die Basis für praktische Rezepte wie Slack benachrichtigen, wenn die Stimmung sinkt. Ein Hinweis: Update-Regeln sind nicht im Free-Tarif enthalten, sie gibt es erst ab Growth.

3. Hourly Triggers (früher Time Triggers)

Der dritte Typ kümmert sich um den Zeitverlauf, und Freshdesks Dokumentation zu Hourly Triggers macht explizit klar, dass dies die Funktion "FKA Time Triggers" ist. Das sind die Regeln, die erfassen, was nicht passiert: Tickets, die unbearbeitet liegen bleiben, sich einem SLA-Verstoß nähern, oder gelöst, aber nicht geschlossen sind. Ein klassisches Beispiel ist die Eskalation jedes Tickets, das 48 Stunden lang nicht angefasst wurde, indem die Priorität erhöht und ein Supervisor benachrichtigt wird.

Der Haken steckt im Namen. Hourly Triggers laufen einmal pro Stunde, daher muss jeder von dir gesetzte Zeitschwellenwert "immer größer oder gleich einer Stunde" sein. Ein paar weitere Grenzen solltest du kennen, bevor du dich darauf verlässt: Sie prüfen nur Tickets, die in den letzten 30 Tagen aktualisiert wurden, und arbeiten ausschließlich mit Ticket-Eigenschaften, nicht mit Kontakt- oder Firmeneigenschaften, und können keine Bedingungen für Betreffzeile, Beschreibung, E-Mail des Anfragenden, CC, Tags oder Anhänge verwenden. Falls du schon einmal eine zeitbasierte Regel eingerichtet und sie hinterherhinken sehen hast, liegt das daran, und unser eigener Leitfaden zu Freshdesk-Hourly-Triggers geht auf die Workarounds ein.

So richtest du eine Freshdesk-Automatisierungsregel Schritt für Schritt ein

Sobald du weißt, welchen Typ du brauchst, ist der Aufbau bei allen drei gleich: ein optionales Ereignis, ein paar Bedingungen und eine oder mehrere Aktionen.

Hier die Anleitung für eine Ticket-Creation-Regel, die den meisten Teams als Einstieg dient:

1. Gehe zu Admin > Workflows > Automations und öffne den Tab Ticket Creation.
2. Klicke auf New Rule und gib ihr einen Namen, den du später wiedererkennst ("Route billing to Finance" schlägt "Rule 7").
3. Lege deine Bedingungen fest, zum Beispiel Ticketbetreff enthält "refund" ODER Typ ist "Billing". Für alles Komplexere nutzt du UND/ODER-Operatoren und verschachtelte Blöcke.
4. Lege deine Aktionen fest: der Finance-Gruppe zuweisen, Priorität auf Hoch setzen, eine Benachrichtigung senden. Du kannst mehrere stapeln.
5. Prüfe die Ausführungsreihenfolge. Ziehe die Regel an die richtige Position und entscheide über das Zahnradsymbol, ob nur die erste Übereinstimmung oder alle Übereinstimmungen gelten sollen. Allein dieser Schritt verhindert die meisten "Warum ist meine Regel nicht ausgelöst"-Kopfschmerzen.
6. Speichere und teste mit einem echten Ticket, bevor du der Regel in der Produktion vertraust.

Ein paar praktische Gewohnheiten machen das Ganze weniger mühsam. Freshdesk liefert vorgefertigte Beispielregeln (etwa eine, die Rückerstattungstickets an eine Billing-Gruppe leitet), die du dir ansehen oder klonen kannst, statt bei null anzufangen, und jede Regel zeigt regelbezogene Statistiken dazu, wie viele Tickets sie in den letzten 7 Tagen betroffen hat, dein schnellster Realitätscheck, ob eine Regel tatsächlich etwas bewirkt. Es gibt außerdem keine Obergrenze für die Anzahl der Bedingungen in einer Regel, du kannst also sehr spezifisch werden, denk nur daran, dass du dir jede Bedingung vorher selbst überlegen musst.

Die anderen Automatisierungsebenen: Szenarien und Routing

Die drei Regeltypen bekommen die meiste Aufmerksamkeit, aber zwei Nachbarn leisten still viel Arbeit im Hintergrund, und werden oft mit Automatisierungsregeln verwechselt.

Szenario-Automatisierungen sind die manuelle Cousine. Statt bei Bedingungen auszulösen, sind sie mit einem Klick ausgeführte Bündel von Aktionen, die ein Agent auf ein Ticket anwendet, die Makro-Ebene. Statt jedes Mal von Hand ein Ticket als Refund zu taggen, es der Refunds-Gruppe zuzuweisen und den Status auf Processing zu setzen, bündelst du das in ein Scenario und führst es mit einem Klick aus (oder gebündelt über ausgewählte Tickets). Sie liegen unter Admin > Agent Productivity > Scenario Automations, und du kannst für jedes festlegen, ob es privat, gruppenweit oder mit allen geteilt ist. Unser Leitfaden zu Freshdesk-Szenario-Automatisierungen geht tiefer, aber der Screenshot unten zeigt die Bandbreite an Aktionen, die ein Szenario tragen kann.

Die automatische Ticketzuweisung ist die andere. Angetrieben von Freshdesks Omniroute-Engine entscheidet sie, wer ein Ticket bekommt, basierend auf Agentenlast, Verfügbarkeit und Skills. Es gibt drei Routing-Methoden: Round-Robin (zirkulär, kapazitätsbewusst), lastbasiert (weist danach zu, wie ausgelastet jeder Agent ist) und skillbasiert (passt Sprache oder Produktexpertise). Der wichtige Vorbehalt: Advanced Automatic Routing ist nur in Pro und Enterprise enthalten, die ausgefeilteren Auto-Zuweisungs-Optionen fehlen also in den günstigeren Plänen.

Welchen Freshdesk-Plan brauchst du für Automatisierungsregeln?

Nicht jede Automatisierung ist in jedem Plan verfügbar, und daher kommt ein großer Teil der Verwirrung nach dem Motto "warum finde ich diese Einstellung nicht". So verteilen sich die Bausteine über Freshdesks Preisstufen. (Die Zahlen beziehen sich auf die eigenständigen Freshdesk-Pläne; die Preise sind jährlich, pro Agent.)

Die Kernaussage: Grundlegende Triage bei der Erstellung ist kostenlos, aber alles Reaktive, Zeitbasierte oder Lastbewusste braucht mindestens den Growth-Plan, und das smarteste Routing ist Pro und Enterprise vorbehalten. Wenn du abwägst, ob sich der Sprung lohnt, gehen unser Freshdesk-Plänevergleich und unsere ehrliche Freshdesk-Bewertung beide auf die Abwägungen ein.

Wo Freshdesk-Automatisierungsregeln an ihre Grenzen stoßen

Automatisierungsregeln sind in genau einer Sache gut: das zu tun, was du ihnen gesagt hast, wenn die von dir geschriebenen Bedingungen zutreffen. Das ist zugleich ihre Obergrenze. Jede Regel ist eine Vermutung, die du im Voraus darüber angestellt hast, wie Tickets aussehen werden, und Tickets spielen selten mit.

Drei Grenzen zeigen sich immer wieder:

• Regeln greifen bei Bedingungen, nicht bei Bedeutung. Eine Creation-Regel kann ein Ticket weiterleiten, dessen Betreff "refund" enthält, aber ein Kunde, der schreibt "ich will mein Geld zurück", rutscht glatt daran vorbei. Am Ende pflegst du immer länger werdende Schlagwortlisten und bist immer nur eine Formulierung von einem Fehltreffer entfernt.
• Zeitbasierte Logik ist grob. Hourly Triggers wachen nur einmal pro Stunde auf, "eskalieren, wenn nach 30 Minuten keine Antwort kommt" lässt sich damit schlicht nicht ausdrücken. Für schnelle Queues ist eine Stunde eine Ewigkeit.
• Sie können eigentlich nichts beantworten. Regeln können weiterleiten, taggen, Priorität setzen und eine vorgefertigte Antwort vorausfüllen, aber sie können keine Frage lesen und die echte Antwort schreiben. Diese Arbeit landet weiterhin bei einem Menschen.

Das haben wir auch von der Deal-Seite aus gespürt. Bei einer Evaluierung schaffte es ein Freshdesk-Kunde nicht, eine neue Automatisierungsregel mit seinem bestehenden Regelwerk koexistieren zu lassen, die Regeln stritten sich ständig um die Ausführungsreihenfolge, und er wurde beim Support immer wieder auf Freshdesks eigenes Freddy AI verwiesen. Das Problem war nicht, dass Regeln schlecht sind; es ist, dass das Aufstapeln von immer mehr Wenn-Dann-Logik, um Verständnis anzunähern, irgendwann unter dem eigenen Gewicht zusammenbricht. Es ist dieselbe Lücke, die unsere Artikel zu Freshdesk-KI-Auto-Triage und Tagging nach Absicht immer wieder aufgreifen: In dem Moment, in dem du willst, dass das System das Ticket versteht, statt nur ein Feld abzugleichen, hast du die Regel-Engine bereits hinter dir gelassen.

Probiere eesel für die Tickets, die Regeln nicht erreichen

Wenn du bis hierher gelesen hast, hast du deine Routing-Regeln wahrscheinlich schon fein eingestellt und schaust auf den Stapel Tickets, den sie nicht schließen können. Genau für diese Lücke wurde eesel AI gebaut. Es legt sich über dein bestehendes Freshdesk (und Slack, E-Mail, Shopify und über 100 weitere Tools), lernt in Minuten aus deinen bisherigen Tickets und Hilfedokumenten und liest, was jeder Kunde tatsächlich gemeint hat, sodass es Antworten entwerfen oder vollständig auflösen kann, die schlagwortbasierte Regeln nie hinbekommen hätten.

Der Teil, der neben Freshdesks Regeln zählt: Du behältst die Kontrolle darüber, welche Tickets die KI anfasst. Statt eines Alles-oder-nichts-Schalters grenzt du sie nach Ticket-Typ oder Konfidenz ein, sodass sie die repetitiven Fragen übernimmt und die Grenzfälle deinem Team überlässt, genau die "wir lassen die KI nicht auf alles automatisch antworten"-Sorge, die die meisten Einführungen ausbremst. Abgerechnet wird pauschal mit 0,40 $ pro Lösung, ohne Sitzplatzgebühren und mit einem von dir selbst festgelegten Ausgabendeckel. Und weil es sich obendrauf legt, statt Freshdesk zu ersetzen, muss keine Migration eingeplant werden.

Du kannst mit einem Guthaben von 50 $ und ohne Kreditkarte starten, es auf deine echten Tickets ansetzen und sehen, was es leistet, bevor du auch nur einen Cent ausgibst. Probiere eesel und behalte die Freshdesk-Regeln, die du bereits gebaut hast; eesel deckt einfach alles ab, was sie nicht erreichen.