Ausdrucken

Szenario-Beispiele erklärt

In diesem Artikel möchten wir Ihnen anhand der Szenario-Templates, die doo Ihnen bereit stellt, sowie weiterer Beispiele die Logik der doo Automatisierungs-Szenarien verdeutlichen.

1. Zertifikatversand nach Check-in

In folgendem Beispiel wird die Erstellung sowie der Versand von Teilnehmerzertifikaten an die Teilnehmer automatisiert, die zu einer Veranstaltung eingecheckt wurden. Sie soll entsprechend aktiviert werden, sobald in doo eine Änderung an einem Teilnehmer, in diesem Fall der Check-in, registriert wird.

  • Watch attendee: Beginnen Sie das Szenario mit einem “Watch attendee” Modul, das Informationen über Ihre neuen Teilnehmer sammelt und weiterleitet.

  • Get event field: Das Modul gibt Ihnen den Wert für ein bestimmtes Ereignisfeld zurück, das Sie bei der Erstellung des Events eingefügt haben. Damit diese Automatisierung richtig funktioniert, müssen Sie ein benutzerdefiniertes Veranstaltungsfeld haben, in das Sie die ID Ihres benutzerdefinierten Dokuments einfügen können (das Sie in den Einstellungen Ihrer Organisation finden können).

  • Router: Da die Zusendung von einem Zertifikat nur möglich ist, wenn dies für den entsprechenden Teilnehmer schon generiert wurde, muss der Szenario erst prüfen, ob dies der Fall ist.  Dafür wird ein Router platziert, welches anhand eines Filters zwei mögliche Routen darstellt. 

  • Route 1: Dokument wurde schon generiert: Nachdem Sie einen “Metadata = attendee_document_generated”-Filter setzen, können Sie die nächsten doo Module verbinden, um das Zertifikat, mittels des Moduls “Send a auto email”, als Anhang an den korrekten Teilnehmer zu schicken. Hierfür müssen Sie die gewünschte Auto-E-Mail-Vorlage auswählen, die mit Ihrem benutzerdefinierten Dokument verbunden ist.

  • Route 2: Dokument wurde noch nicht generiert: Erst sollten Sie einen “Metadata:trigger = attendee_checkin”-Filter setzen, um zu prüfen, ob der Teilnehmer überhaupt eingecheckt wurde. Wenn ja, wird diese Information an das nächste Modul weitergegeben, welches dann das Dokument für diesen bestimmten Teilnehmer erstellt. Dieses wird dann versendet, wenn das Make-Szenario erneut ausgeführt wird und der Workflow erneut den ersten Weg durchläuft.

  • Break: Für beide Routen, sollte ein “Error Handling”-Modul eingesetzt werden, damit das Szenario beim Auftreten eines Problems weiter fortgesetzt, gleichzeitig aber als Warnung markiert wird.

2. Automatischer Ticket-Neuversand auf Bucheranfrage per E-Mail

Für den Fall, dass Teilnehmer ihre E-Mails mit dem Ticket nicht mehr finden können, können Sie ihnen mithilfe dieses Szenarios eine Self-Service Option bieten, sich ihr Ticket noch einmal selbst zuschicken. Hierfür muss der Bucher lediglich von der E-Mail-Adresse, die er für die Buchung verwendet hat, eine E-Mail an eine spezielle E-Mail-Adresse schreiben.

  • Modul 1 – Webhooks – Custom Mailhook: Als Auslöser für dieses Szenario fungiert ein sogenannter Mailhook. Bei diesem Mailhook handelt es sich um eine einzigartige E-Mail-Adresse, die extra für das Szenario neu erstellt wird. Sobald eine E-Mail an diese Adresse versendet wird, wird das Szenario ausgelöst. Klicken Sie in der Konfiguration des Moduls auf “Add” und wählen “My gateway mailhook webhook” aus. Sie können den Namen individuell anpassen, um ihn später in der Webhookübersicht besser zuordnen zu können. Die Adresse Ihres Webhooks wird Ihnen sodann unterhalb angezeigt und kann von dort kopiert, um sie an Ihre Bucher zu kommunizieren.

  • Modul 2 – Tools – Set multiple variables: Im nächsten Schritt ist ein Tool eingebaut, mit dem Sie Variablen definieren, die Sie später im Scenario benötigen. Die E-Mail-Adresse des Senders wird als Variable “Booker Email” festgelegt wird, damit sie im weiteren Szenarioverlauf verwendet werden kann. Außerdem kann hier nach erstmaligem Speichern des Szenarios unter “Variable 2” die doo Event-ID eingegeben werden, für die die Automatisierung gelten soll.

  • Modul 3 – doo – Search booking: Nachdem Sie Ihre doo Organisations-ID für das darauffolgende “Search bookings”-doo Modul bestätigt haben, kann in Ihrem Account nach der E-Mail-Adresse des sendenden Teilnehmers gesucht werden.

  • Filter “If any booking found”: Durch den nachfolgenden Filter wird überprüft, ob eine Buchung zu der E-Mail-Adresse vorliegt.

  • Modul 4 – doo – Get booking: Wenn ja, werden im nächsten Schritt die dazugehörigen Buchungsdaten abgefragt. Als Input wird die Booking ID des Search Moduls gemapped, damit jeweils die Daten der dort gefundene Buchung aufgerufen werden.

  • Filter “If the booking is correct“: Durch den darauffolgenden Filter wird überprüft, ob die Buchung noch aktiv ist, um zu verhindern, dass Tickets für eine bereits stornierte Buchung noch einmal rausgeschickt werden.

  • Modul 5 – doo – Resend booking confirmation email: Liegt zu der E-Mail-Adresse, von der aus die E-Mail an den Mailhook geschickt wurde, eine aktive Buchung vor, wird durch das nachfolgende Modul “Resend Booking Confirmation Email” die dazugehörige Buchungsbestätigung inkl. Ticket erneut versendet. Auch für dieses Modul ist die Booking ID der Input und wird entsprechend gemapped.

  • Error Handling Module – Break: Für jedes doo Modul wird ein “Error Handling”-Modul eingesetzt, damit das Szenario beim Auftreten eines Problems im Zusammenhang mit einer bestimmten E-Mail-Adresse bzw. Buchung für neu eingehende E-Mails weiter funktioniert, Sie aber über eine entsprechende Warnung über das Problem informiert werden.

3. Automatischer Zertifikatsversand nach Ausfüllen von Feedbackformular

Das folgende Beispiel automatisiert den Versand von Zertifikaten an Teilnehmer unter der Voraussetzung, dass diese zuvor ein Feedback-Formular ausgefüllt haben. Dieser Prozess, der z. B. häufig bei virtuellen Veranstaltungen eingesetzt wird, kann durch die Kombination von zwei Szenarien automatisiert werden: Das erste Szenario automatisiert eine E-Mail mit dem Link zu einem Formular, das nach dem Ende der Veranstaltung an alle eingecheckten Teilnehmer geschickt werden soll. Das zweite Szenario wird gestartet, sobald ein Teilnehmer das Formular ausgefüllt hat, und sorgt dafür, dass dieser Person eine zweite E-Mail mit seinem personalisierten Zertifikat zugeschickt wird.

3.1. Formular und Auto-E-Mail mit vorbefüllter Buchungs-ID erstellen

Bevor der Prozess automatisiert werden kann, müssen Sie das Feedback-Formular und die Auto-E-Mail erstellen, die an Ihre Teilnehmer mit dem Link zu diesem Formular verschickt werden soll. 

Bitte beachten Sie, dass das Formular als erste Frage ein Textfeld für die Buchungs-ID der Person enthalten sollte, welche als Identifikator dienen wird. Die jeweilige Buchungs-ID kann aus Ihrem Automatisierungsszenario als Prefill-Wert (= API-Platzhalter) übernommen werden, so dass ausgefüllte Umfragen einem einzelnen Teilnehmer zugeordnet werden können, der sodann als Empfänger des Zertifikats ausgewählt wird.

Um vorbefüllte Antworten für Ihre Empfänger zu konfigurieren, muss die URL des Formulars geändert werden, indem das Suffix ?prefill= hinzugefügt wird, gefolgt von einem Array mit den Antworten, die vorausgefüllt werden sollen. In unserem Fall soll die Antwort auf die erste Frage (“Buchungs-ID”) mit dem Wert der Buchungs-ID des Teilnehmers vorausgefüllt werden, die wir später in den erweiterten Einstellungen des “Auto-E-Mail-Moduls” definieren werden. Der geänderte Link zu Ihrem Formular sollte wie folgt aussehen:

 https://doo.net/de-de/forms/IHRE-FORMULAR-ID?prefill=[“{{placeholders.orderID}}”]

Wenn Sie weitere Vorbefüllungen hinzufügen möchten (z. B. wenn Sie Bilder mit Sternebewertungen in Ihre E-Mail einfügen und die Bewertung, die der Empfänger in der E-Mail angeklickt hat, vorbefüllen möchten), können Sie das obige URL-Beispiel entsprechend ändern, indem Sie weitere Antworten an den Prefill-Suffix anhängen (siehe letzter Absatz dieses Artikels).

3.2. Szenario für Umfrageversand an eingecheckte Teilnehmer

  • Das Szenario beginnt mit einem “Watch attendee”-Webhook, der bei jeder Änderung der Teilnehmerdaten ausgelöst wird.

  • Auf das Auslöser-Modul folgt ein “Get attendee”-Modul, das benötigt wird, um alle Teilnehmerinformationen zu erhalten.

  • Danach wird ein Filter hinzugefügt, um nur Teilnehmer für eine bestimmte Veranstaltung auszuwählen. Bitte klicken Sie auf den Filter und wählen Sie Ihre Veranstaltungs-ID.

  • Im nächsten Schritt verwenden wir ein “Get ticket”-Modul, um auf alle Ticketinformationen zuzugreifen. Dieses Modul wird nur benötigt, wenn Sie später nach einer bestimmten Ticketkategorie filtern möchten. Wenn nicht, können Sie diesen Schritt überspringen.

  • Der Filter enthält zwei Bedingungen: eine prüft, ob der Teilnehmer eingecheckt ist, und die andere schränkt den E-Mail-Versand auf die Teilnehmer ein, die sich für eine bestimmte Ticketkategorie registriert haben (dieser Filter ist relevant, wenn Sie mehrere Ticketkategorien haben und nur die Bucher einer bestimmten Kategorie das Formular erhalten sollen).

  • Das Szenario endet mit einem “Send Auto Email”-Modul. Um die ausgefüllten Umfragen dem einzelnen Teilnehmer zuordnen und ihm anschließend sein Zertifikat zusenden zu können, muss die jeweilige Buchungs-ID als Vorbefüllungswert in das Formular übernommen werden. Um die ausgefüllten Umfragen dem entsprechenden Teilnehmer zuordnen zu können, müssen wir dafür sorgen, dass die Buchungs-ID im Formular vorausgefüllt wird. Dazu muss in den erweiterten Einstellungen des Moduls ein Platzhalter mit einem Schlüssel namens “orderID” und dem Wert der Buchungs-ID aus dem Modul “Get Ticket” hinterlegt werden.

3.3. Szenario erstellen für Generierung und Versand von Zertifikaten an Teilnehmer, die das Formular ausgefüllt haben

Im zweiten Szenario geht es um den Versand des Zertifikats an den richtigen Teilnehmer, nachdem dieser das Formular ausgefüllt hat. Bitte stellen Sie sicher, dass Sie zunächst eine Auto E-Mail erstellen, die für den Versand verwendet werden soll, und das entsprechende Dokument als Anhang auswählen.

  • Das Szenario beginnt mit einem “Watch form response”-Modul, das immer dann ausgelöst wird, wenn eine neue Formularantwort gespeichert wird.

  • Auf den Auslöser folgt ein “Get form response”-Modul, um alle Informationen über das Formular abzurufen.

  • Der folgende Filter schränkt den Datenfluss so ein, dass nur Antworten auf ein bestimmtes Formular berücksichtigt werden. Bitte wählen Sie die richtige Formular-ID aus.

  • Es folgt das Modul “Search form response answers”, bei dem die Formularantwort-ID mithilfe der vorherigen Module zugeordnet wird.

  • Der folgende Array-Aggregator bündelt die Buchungsinformationen, den Antworttext und die Antwort-ID des Formulars, die benötigt werden, um das ausgefüllte Formular im nächsten Schritt dem entsprechenden Teilnehmer zuzuordnen.

  • Das nächste Modul “Search attendee” ist mit dem Suchtyp “Attendees for booking” konfiguriert, um die Buchungs-ID durch Zugriff auf den Antworttext auf das erste Element im bereitgestellten Array zu erhalten, wie in der Abbildung gezeigt.

     

  • Das nächste Modul “Get attendee” ruft die Teilnehmerdaten ab, die zu der in das Formular eingegebenen Buchungs-ID gehören.

  • Mit dem Modul “Generate custom document” wird anschließend das Zertifikat für den Teilnehmer erstellt, gefolgt von einem “Sleep”-Modul, das den Prozess für ein paar Minuten unterbricht, um sicherzustellen, dass das Dokument erfolgreich generiert wurde, bevor mit dem nächsten Schritt fortgefahren wird.

  • Das Szenario endet mit einem “Send auto email”-Modul. Bitte passen Sie die Einstellungen an und wählen Sie die entsprechende Auto-E-Mail mit dem angehängten Zertifikat sowie der Teilnehmer- und Kontakt-ID, die Sie mit den vorherigen Modulen erhalten haben.

Schlagwörter:
Table of Contents

ANTWORT NICHT GEFUNDEN?

Unser Support-Team hilft Ihnen gerne weiter

SUPPORT KONTAKTIEREN