Zum Hauptinhalt springen

Workflow-Rezepte

Auf dieser Seite findest Du fertige Workflow-Ideen, die Du direkt umsetzen kannst. Jedes Rezept beschreibt ein reales Szenario, zeigt Dir die Schrittkette und erklärt, was Du konfigurieren musst. Nutze sie so wie sie sind oder passe sie an Deinen Prozess an.

Alle Rezepte verwenden Bausteine, die bereits im Workflow-Editor verfügbar sind -- Trigger, Aktionen, Bedingungen, Wartezeiten und Tags. Falls Du diese noch nicht kennst, lies zuerst Workflows.

Automatische Kommunikation​

1. Bestätigungsmail bei neuer Anfrage​

Szenario: Ein potenzieller Kunde füllt Dein Kontaktformular auf der Website aus. Du möchtest eine sofortige Bestätigungsmail, damit die Person weiss, dass die Anfrage eingegangen ist.

Aufbau:

Form Submitted (contact) → Send Email (Bestätigungstemplate)

Konfiguration:

  • Trigger: Formulartyp auf contact setzen.
  • Send Email: Dein Bestätigungstemplate auswählen. Empfängertyp auf Event-Kontakt setzen, damit die Mail an die Person geht, die das Formular ausgefüllt hat.

Ergebnis: Jede Kontaktformular-Eingabe löst sofort eine Bestätigungsmail aus. Niemand im Team muss etwas tun -- der Kunde bekommt innert Sekunden eine Rückmeldung.

2. Follow-up nach 3 Tagen ohne Reaktion​

Szenario: Eine neue Anfrage ist reingekommen, aber niemand im Team hat sich darum gekümmert. Du willst nach 3 Tagen eine automatische Erinnerung, damit nichts untergeht.

Aufbau:

No Activity (3 Tage) → Check: Event Status = New? → Ja: Send Notification (Zuständige Person)

Konfiguration:

  • Trigger: Inaktivitätsdauer auf 3 Tage setzen.
  • Bedingung: Event Status prüfen, auf New setzen.
  • Send Notification: Ziel Assignee, Titel zum Beispiel "Erinnerung: Anfrage seit 3 Tagen unbearbeitet".

Ergebnis: Wenn ein Event 3 Tage lang im Status "New" bleibt, ohne dass jemand es aktualisiert, bekommt die zuständige Person eine Benachrichtigung. Events, die bereits in einen anderen Status verschoben wurden, werden ignoriert.

3. Feedbackanfrage nach Eventabschluss​

Szenario: Nach dem Event möchtest Du dem Kunden eine Feedback-Mail schicken -- aber nur, wenn das Event tatsächlich durchgeführt wurde und nicht storniert.

Aufbau:

Time After Event (1 Tag) → Check: Event Status = Completed? → Ja: Send Email (Feedback-Template)

Konfiguration:

  • Trigger: Time After Event, Versatz 1 Tag.
  • Bedingung: Event Status prüfen, auf Completed setzen.
  • Send Email: Feedback-Template auswählen. Empfänger: Event-Kontakt.

Ergebnis: Einen Tag nach jedem Event-Datum prüft der Workflow, ob das Event abgeschlossen wurde. Falls ja, bekommt der Kunde eine Feedbackanfrage. Stornierte oder verschobene Events werden automatisch übersprungen.

Vertriebspipeline​

4. Neue Events automatisch zuweisen​

Szenario: In Deinem Team gibt es eine Standardperson, die alle neuen Anfragen bearbeitet -- oder Du willst sicherstellen, dass kein Event ohne Zuständigkeit bleibt.

Aufbau:

Event Created → Assign Event (Teammitglied)

Konfiguration:

  • Trigger: Event Created (keine weitere Filterung nötig).
  • Assign Event: Das Teammitglied auswählen, das standardmässig zugewiesen werden soll.

Ergebnis: Jedes neue Event hat sofort eine verantwortliche Person. Kein "Ich dachte, Du kümmerst Dich darum" mehr.

5. Auf Qualifiziert setzen, wenn das Detailformular komplett ist​

Szenario: Du schickst Kunden nach dem Erstkontakt ein Detailformular. Sobald sie es vollständig ausfüllen, soll das Event automatisch von New auf Qualified wechseln.

Aufbau:

Form Submitted (event) → Check: Form Completion = vollständig? → Ja: Update Event Status (Qualified)

Konfiguration:

  • Trigger: Form Submitted, Formulartyp event.
  • Bedingung: Form Completion für das Detailformular prüfen.
  • Update Event Status: auf Qualified setzen.

Ergebnis: Wenn ein Kunde das ausgefüllte Detailformular einreicht, rückt das Event in der Pipeline vor, ohne dass jemand den Status manuell ändern muss. Dein Team sieht sofort, welche Events bereit für eine Offerte sind.

6. Team über neue Buchung informieren​

Szenario: Wenn ein Event den Status "Booked" erreicht, soll Dein gesamtes Vertriebsteam informiert werden -- zur Koordination und weil eine neue Buchung Grund zur Freude ist.

Aufbau:

Event Status Changed (→ Booked) → Send Notification (Alle Teammitglieder)

Konfiguration:

  • Trigger: Event Status Changed, Filter Zielstatus = Booked.
  • Send Notification: Ziel Alle Teammitglieder, Titel "Neue Buchung bestätigt!".

Ergebnis: Das ganze Team bekommt eine In-App-Benachrichtigung, sobald eine Buchung bestätigt wird. Alle sind auf dem Laufenden, ohne extra Slack-Nachrichten oder E-Mail-Threads.

7. CRM-Sync bei Statuswechsel​

Szenario: Dein Team nutzt ein externes CRM und Du möchtest bei jedem Statuswechsel Event-Daten dorthin senden -- damit beide Systeme synchron bleiben.

Aufbau:

Event Status Changed → Send Webhook (CRM-Endpunkt)

Konfiguration:

  • Trigger: Event Status Changed (kein Statusfilter -- bei jeder Änderung auslösen).
  • Send Webhook: Die Webhook-Integration auswählen, die auf Deinen CRM-Endpunkt zeigt.

Ergebnis: Jeder Statuswechsel sendet einen Payload an Dein CRM. Dein externes System hat immer den aktuellen Event-Status, ohne dass jemand zwischen den Tools hin- und herkopiert.

Erinnerungen & Eskalation​

8. Erinnerung bei fehlendem Detailformular -- 2 Wochen vor dem Event​

Szenario: Du brauchst das Detailformular vom Kunden spätestens zwei Wochen vor dem Event. Falls es noch nicht ausgefüllt ist, soll eine Erinnerungsmail rausgehen.

Aufbau:

Time Before Event (14 Tage) → Check: Form Completion = unvollständig? → Ja: Send Email (Erinnerungstemplate)

Konfiguration:

  • Trigger: Time Before Event, Versatz 14 Tage.
  • Bedingung: Form Completion prüfen -- so konfigurieren, dass die Bedingung greift, wenn das Formular nicht vollständig ist (den false-Zweig nutzen oder die Form Completion Ratio auf < 100% prüfen).
  • Send Email: Erinnerungstemplate auswählen. Empfänger: Event-Kontakt.

Ergebnis: Zwei Wochen vor jedem Event prüft der Workflow, ob der Kunde seine Details eingereicht hat. Falls nicht, bekommt er eine freundliche Erinnerung. Events mit vollständigem Formular werden übersprungen.

9. Eskalationskette: 3 Tage, dann 7 Tage, dann Team​

Szenario: Eine Anfrage liegt brach. Nach 3 Tagen soll die zuständige Person erinnert werden. Nach insgesamt 7 Tagen ohne Fortschritt soll das ganze Team informiert werden.

Aufbau:

No Activity (3 Tage) → Send Notification (Zuständige Person: "Event braucht Aufmerksamkeit")
  → Wait (4 Tage)
  → Check: Event Status = New?
    → Ja: Send Notification (Alle Teammitglieder: "Eskalation: Event seit 7 Tagen unbearbeitet")

Konfiguration:

  • Trigger: No Activity, 3 Tage.
  • Send Notification: Ziel Assignee.
  • Wait: 4 Tage (ergibt insgesamt 7 Tage seit der letzten Aktivität).
  • Bedingung: Event Status prüfen, auf New setzen (falls jemand es inzwischen bearbeitet hat, stoppen).
  • Send Notification (zweite): Ziel Alle Teammitglieder mit Eskalationsnachricht.

Ergebnis: Ein zweistufiges Sicherheitsnetz. Die zuständige Person bekommt nach 3 Tagen einen sanften Hinweis. Falls das Event nach einer vollen Woche immer noch unbearbeitet ist, wird das gesamte Team informiert. Events, die zwischenzeitlich bearbeitet wurden, werden nicht eskaliert.

10. Catering-Deadline-Erinnerung​

Szenario: Dein Venue-Partner braucht die Catering-Zahlen 7 Tage vor dem Event. Du möchtest eine automatische Mail an den Kunden, falls das Event den Tag "catering" hat, aber die Catering-Details noch fehlen.

Aufbau:

Time Before Event (7 Tage) → Check: Has Tag "catering"?
  → Ja: Check: Form Completion (Catering-Formular) = unvollständig?
    → Ja: Send Email (Catering-Deadline-Erinnerung)

Konfiguration:

  • Trigger: Time Before Event, Versatz 7 Tage.
  • Bedingung 1: Has Tag, auf catering setzen.
  • Bedingung 2: Form Completion für das Catering-Detailformular prüfen.
  • Send Email: Catering-Erinnerungstemplate an Event-Kontakt.

Ergebnis: Nur Events mit dem Tag "catering" werden geprüft. Falls das Catering-Formular 7 Tage vor dem Event noch unvollständig ist, bekommt der Kunde eine spezifische Erinnerung. Alle anderen Events sind nicht betroffen.

Tagging & Organisation​

11. Automatisch taggen nach Formulartyp​

Szenario: Wenn jemand das Kontaktformular auf Deiner Website ausfüllt, soll das Event automatisch den Tag "web-inquiry" bekommen -- damit Du online Leads filtern und auswerten kannst.

Aufbau:

Form Submitted (contact) → Add Tag ("web-inquiry")

Konfiguration:

  • Trigger: Form Submitted, Formulartyp contact.
  • Add Tag: web-inquiry eingeben.

Ergebnis: Jede Online-Anfrage wird sofort getaggt. Du kannst die Event-Liste nach "web-inquiry" filtern und sehen, wie viele Leads über Deine Website kommen.

12. Events mit vielen Teilnehmenden taggen​

Szenario: Events mit mehr als 100 Teilnehmenden erfordern einen anderen Logistikprozess. Du willst diese Events automatisch taggen, damit Dein Operations-Team sie schnell findet.

Aufbau:

Event Field Changed (attendees) → Check: Field Value (attendees > 100)?
  → Ja: Add Tag ("large-event")

Konfiguration:

  • Trigger: Event Field Changed, das Feld attendees überwachen.
  • Bedingung: Field Value prüfen -- Feld attendees, Operator >, Wert 100.
  • Add Tag: large-event eingeben.

Ergebnis: Sobald jemand mehr als 100 Teilnehmende bei einem Event einträgt, wird der Tag "large-event" automatisch gesetzt. Dein Operations-Team kann nach diesem Tag filtern und die Ressourcen entsprechend planen.

Mehrstufige Workflows​

13. Kompletter Onboarding-Ablauf für neue Events​

Szenario: Wenn ein neues Event erstellt wird, möchtest Du es zuweisen, eine Willkommensmail senden und 3 Tage später nachfassen, falls der Kunde das Detailformular noch nicht ausgefüllt hat.

Aufbau:

Event Created → Assign Event (Standard-Koordinator/in)
  → Wait (1 Stunde)
  → Send Email (Willkommen + nächste Schritte)
  → Wait (3 Tage)
  → Check: Form Completion (Detailformular) = vollständig?
    → Nein: Send Email (freundliche Erinnerung)
    → Ja: Update Event Status (Qualified)

Konfiguration:

  • Trigger: Event Created.
  • Assign Event: Deine/n Standard-Event-Koordinator/in auswählen.
  • Wait: 1 Stunde (gibt dem System Zeit und vermeidet, dass die Mail in der gleichen Sekunde rausgeht wie die Event-Erstellung).
  • Send Email: Willkommenstemplate an Event-Kontakt.
  • Wait: 3 Tage.
  • Bedingung: Form Completion für das Detailformular.
  • False-Zweig: Send Email mit Erinnerungstemplate.
  • True-Zweig: Update Event Status auf Qualified.

Ergebnis: Eine vollständige Onboarding-Sequenz läuft automatisch. Die Koordination ist zugewiesen, der Kunde bekommt eine Willkommensmail, und 3 Tage später wird die Pipeline entweder weitergeschoben oder ein Reminder verschickt. Dein Team muss erst bei der eigentlichen Offerte eingreifen.

14. Follow-up-Sequenz nach Offerte​

Szenario: Du hast eine Offerte geschickt und willst nachfassen, falls der Kunde nicht reagiert. Zuerst eine freundliche Nachfrage nach 5 Tagen, dann ein Hinweis an die zuständige Person nach 10 Tagen.

Aufbau:

Event Status Changed (→ Proposal Sent) → Wait (5 Tage)
  → Check: Event Status = Proposal Sent?
    → Ja: Send Email (Follow-up: "Gibt es Fragen zu unserer Offerte?")
      → Wait (5 Tage)
      → Check: Event Status = Proposal Sent?
        → Ja: Send Notification (Zuständige Person: "Offerte seit 10 Tagen unbeantwortet -- evtl. anrufen")

Konfiguration:

  • Trigger: Event Status Changed, Filter auf Zielstatus Proposal Sent.
  • Wait: 5 Tage.
  • Bedingung: Event Status = Proposal Sent (falls der Kunde bereits gebucht oder abgesagt hat, hier stoppen).
  • Send Email: Follow-up-Template an Event-Kontakt.
  • Wait: 5 weitere Tage.
  • Bedingung: Event Status = Proposal Sent erneut prüfen.
  • Send Notification: Ziel Assignee mit Hinweis, den Kunden anzurufen.

Ergebnis: Ein zweistufiges Follow-up, das das Tempo des Kunden respektiert. Sobald sich der Status ändert, werden die restlichen Schritte übersprungen. Falls nicht, bekommt Dein Team ein klares Signal zum Nachfassen.

Schnelle Erfolge​

15. Manueller Trigger für Ad-hoc-Benachrichtigungen​

Szenario: Manchmal musst Du das ganze Team schnell über ein Event informieren -- eine kurzfristige Änderung, ein VIP-Gast, der früher kommt, oder ein Raumwechsel. Du willst das mit einem Klick erledigen.

Aufbau:

Manual Trigger → Send Notification (Alle Teammitglieder)

Konfiguration:

  • Trigger: Manual.
  • Send Notification: Ziel Alle Teammitglieder, einen beschreibenden Titel setzen wie "Achtung: dieses Event prüfen".

Ergebnis: Von jeder Event-Detailseite aus klickst Du auf Trigger Now, wählst das Event aus, und Dein ganzes Team bekommt sofort eine Benachrichtigung. Kein E-Mail-Schreiben oder Chat-Nachlaufen nötig.

Tipps zum Bauen von Workflows​

  1. Fang einfach an und baue dann aus. Beginne mit einem einzelnen Trigger und einer Aktion. Sobald Du im Runs-Tab siehst, dass es funktioniert, fügst Du Bedingungen und Wartezeiten hinzu. Einen 2-Schritt-Workflow zu debuggen ist viel einfacher als einen mit 10 Schritten.

  2. Nutze Bedingungen, um Rauschen zu vermeiden. Ohne Bedingungen wird jedes Event verarbeitet, das zum Trigger passt. Füge früh in der Kette eine Event-Status- oder Form-Completion-Prüfung ein, um Events herauszufiltern, die keine Aufmerksamkeit brauchen.

  3. Achte auf Deine Wartezeiten. Ein "Wait 7 days"-Schritt bedeutet, dass die Workflow-Instanz eine volle Woche im Status "Waiting" bleibt. Stell sicher, dass das Timing zu Deinem realen Prozess passt -- und denk daran, dass Du einen wartenden Run jederzeit manuell abbrechen kannst.

  4. Prüfe den Runs-Tab regelmässig. Der Runs-Tab zeigt Dir genau, was passiert ist -- welcher Schritt erfolgreich war, welcher fehlgeschlagen ist und warum. Das ist der schnellste Weg, um zu verstehen, ob Dein Workflow tut, was er soll.

  5. Nutze das Draft/Publish-Modell. Speichere Deine Änderungen zuerst als Draft und veröffentliche erst, wenn Du sicher bist. Du kannst jederzeit eine frühere Version wiederherstellen, falls etwas schiefgeht.

Verwandt​