Sales und Marketing vereinen – Integration von MS Bookings in Customer Insights Journeys

Gastausgabe, Autor: Johannes Fleischhut

Microsoft Bookings ist super, um Interessent:innen die Möglichkeit zu geben, selbstständig einen Termin mit einem Mitarbeiter zu vereinbaren. Es spricht nichts dagegen, Bookingsformulare direkt auf der eigenen Website einzubetten, entsprechende Funktionalitäten bietet das Tool. Allerdings erfordert die Buchung eines Termins schon eine relativ hohe Verbindlichkeit, die in dem Moment eines ersten Aufeinandertreffens auf Seiten des Interessenten vielleicht nicht gegeben ist. Die Folge: der potenzielle Lead springt ab. In einem Kundenprojekt haben wir daher einen kleinen Prozess entwickelt, der zunächst einmal ein unverbindliches Leadformular auf der Website anbietet. Interessent:innen geben hier rudimentäre Daten ein, damit zunächst einmal der Lead im CRM angelegt werden kann. Sie erhalten dann eine Bestätigungsmail mit einem Link zur Bookingspage, von wo aus sie optional direkt einen Termin buchen können. Wenn sie es nicht tun, kann sich ein Vertriebsmitarbeiter mit ihnen in Verbindung setzen und den Termin auf diese Weise vereinbaren. Um dem Vertrieb möglichst viel administrative Arbeit abzunehmen, sollte die dazugehörige Journey wissen, ob ein Lead einen Termin vereinbart hat oder nicht und notfalls dem Vertrieb eine entsprechende Aufgabe zuweisen.

Lasst uns also loslegen!

Das Customer Insights Formular für die Website

Zunächst erstellen wir in Dynamics Customer Insights ein sehr einfaches Formular für Leads, welches die vom Vertrieb benötigten Felder beinhaltet (Name, E-Mail Adresse, Telefon, Firma, Position). Außerdem fragen wir verpflichtend einen Consent für transaktionale Kommunikation ab, damit wir später ohne Sorgen die Bestätigungsmail verschicken können.

In meinem Formular habe ich die Labels aus dem HTML Markup entfernt und verwende ausschließlich Platzhalter. Das führt zu einem etwas kompakteren Formular, wir wollten ein schnell zu überblickendes Ergebnis erhalten.

Ansonsten gibt es an diesem Formular nichts wirklich Spannendes, außer der eigenen „matching rule“, die neben der E-Mail Adresse auch das Thema des Leads abprüft. So vermeiden wir, dass doppelte Leads über dieses spezielle Formular angelegt werden, können aber gleichzeitig ausschließen, dass Leads, die über verschiedene Wege im CRM gelandet sind, überschrieben werden. In den Einstellungen im Reiter „Form matching strategy“ können eigene matching rules erstellt werden, hier einfach das standardmäßige Emailfeld und das Thema als zu überprüfende Spalten hinzufügen und anschließend im Formular die neue Regel auswählen.

Wichtig: Alle Felder, die in der „matching rule“ verwendet werden, müssen auch auf dem Formular enthalten sein. Daher habe ich das Feld „Thema“ als verstecktes Feld mit dem Standardwert „Book Demo“ im Formular integriert. Dies überschreibt das standardmäßige Verhalten, welches den Namen des Formulars als Thema des Leads verwenden würde.

Die Bookings Page

Microsoft Bookings ist darauf ausgelegt, sehr einfach bedienbar zu sein. Ich werde mich hier nicht zu sehr in die Details stürzen. Es gibt gute Anleitungen, Bookingspages zu erstellen, zum Beispiel hier: Customize and publish your booking page | Microsoft Learn

Für unsere Bookingspage habe ich zwei verschiedene Dienste erstellt, die unterschiedliche Längen haben. Ansonsten habe ich keine Veränderungen an der Konfiguration vorgenommen. Die fertige Seite sieht so aus:

Das einzige, was hier wirklich zu beachten ist: wir müssen unter Mitarbeitern denjenigen User als Administrator hinterlegen, über den später der Flow laufen soll. Dies ist eine Einschränkung im Power Automate Connector. Da aber pro Dienst des Bookings Kalenders die verfügbaren Mitarbeiter einzeln ausgewählt werden können, ist es nicht schlimm, hierfür einen User zu verwenden, der nicht Bestandteil des Vertriebsteams ist und für den entsprechend auch später keine Termine gebucht werden können sollen.

Die Bestätigungsmail

Auch bei der Bestätigungsmail passiert keine wirkliche Magie. Wir erstellen über Dynamics Customer Insights eine einfache transaktionale E-Mail. Für die Ansprache habe ich die genderneutrale Form „Hallo Vorname Nachname“ gewählt, um nicht auf komplizierte Briefanreden zurückgreifen zu müssen.

In der Mail wird ein statischer Button eingefügt, der den Link zur Bookingspage beinhaltet.

Wenn die Mail fertig ist, könnte sie so oder so ähnlich aussehen:

Wir erstellen einen Custom Trigger

Wenn Du noch nie einen Trigger erstellt hast, keine Angst. Dieser Trigger ist super simpel, wir benötigen ihn, um später über einen Flow in die Journey eingreifen zu können.

Wir erstellen also einen neuen Trigger des Typs „When a customer interacts with a website/app“. Im ersten Schritt können wir nun Attribute hinzufügen. Für unseren Fall benötigen wir ausschließlich die Beziehung zum Lead. Wir wählen also in dem vorausgefüllten Attributsfeld statt Kontakt den Data type Lead aus. Mehr Felder benötigen wir gar nicht.

Den zweiten Schritt können wir vollständig überspringen, da wir den Trigger nicht über Code ausführen wollen, sondern über einen Flow. Wir klicken also auf „Next“ und dann auf „Ready to use“

Der fertige Trigger sieht dann ungefähr so aus:

Die Magie passiert im Flow

Kommen wir nun zum wesentlichen Teil unseres kleinen Prozesses, dem Link zwischen Bookings und Customer Insights: unserem Flow.

Power Automate bietet einen OOB Connector zu Microsoft Bookings. Wir wählen hier den Trigger „When a Appointment is Created” aus. Zum Zeitpunkt dieses Blogs ist der Connector zu Microsoft Bookings noch im Previewmodus, zeigt sich auch hin und wieder etwas zickig, funktioniert aber grundsätzlich und reicht für unseren Use-Case vollkommen aus.

Wichtig ist nun, dass ich den Trigger über denselben Systemuser nutze, der als Administrator in der Bookingspage hinterlegt ist. Ist die Connection hergestellt, sollten in einem Dropdownfeld eigentlich alle für diesen User verfügbaren Bookingspages angezeigt werden. Zum Zeitpunkt des Blogartikels hatte ich Probleme, diese Liste angezeigt zu bekommen, stattdessen erhielt ich eine seitenlange Fehlermeldung, welche wohl auf den Previewstatus des Connectors zurückzuführen war. Das muss uns aber nicht aufhalten, denn zum Glück können wir auch Custom Values in den Trigger einfügen und diese zeigten sich als voll funktionsfähig.

Den Wert, den wir in das Feld „Booking Page“ einfügen müssen, ist die SMTP Adresse unserer Bookingspage. Diese findet sich zum Beispiel in der URL des Seite (hier gelb markiert).

Sobald der Custom Value eingefügt ist, sollte der Trigger funktionieren.

Ich habe mir angewöhnt, bei neuen Triggern und Flows zunächst mal einen Test zu machen und einfach nur einen Compose Schritt einzufügen, der den Body des Triggers enthält. So bekomme ich ein Gefühl für die darin enthaltenen Daten und deren Struktur. Dies sieht dann in etwa so aus:

Wenn der Flow erstmals gelaufen ist, habe ich so meine Daten zur Verfügung und kann später beim Testen denselben Lauf immer wieder reaktivieren, sodass ich nicht ständig den Trigger in echt neu feuern muss (und am Ende 100 Testevents im Kalender habe).

Finde den korrekten Lead im CRM

Damit wir unseren Customer Insights Trigger im nächsten Schritt aktivieren können, müssen wir herausfinden, welcher Lead im CRM mit unserem neuen MS Bookings Eintrag korrespondiert. Ich mache das anhand der E-Mail Adresse und dem Thema. Um das Thema im Flow als Variable zu hinterlegen, könnte man ausgefeilte Logiken einfügen von Umgebungsvariablen bis hin zu eigenen Abfragen aus dem Dataverse. Für mich reicht hier aber eine simple Variable, der ich denselben Namen gebe, wie meinem Themafeld aus dem Leadformular, nämlich „Book Demo“.

Anschließend kann ich über die Dataverse Action „List Rows“ eine Abfrage starten, die mir den neuesten aktiven Lead zurückgibt, der die Emailadresse aus der Bookings-Buchung und das zuvor definierte Thema enthält. In der Regel sollte es von dieser Kombination nur ein Ergebnis geben, ich erzwinge das vorsichtshalber noch, indem ich den „Row count“ auf 1 festlege.

Die Zeile für „Filter rows“ lautet:

statuscode eq 1 and emailaddress1 eq '@{triggerOutputs()?['body/CustomerEmail']}' and subject eq '@{variables('Lead Subject')}'

Anschließend setze ich meine zuvor initiierten Variablen für die Lead ID und die ID des Besitzers. Die „Apply to each“-Schleife, die hier automatisch kreiert wird, akzeptiere ich der Einfachheit halber. Wem das zu unübersichtlich wird, könnte auch mit der Funktion first() arbeiten, dies aber nur als Hinweis.

Bonustipp: Die Extrameile

In unserem Formular haben wir das zwar nicht so gelöst, aber denkbar wäre ja auch – um den Interessent:innen ein noch schnelleres Erlebnis zu bieten – dass nach Absenden des Formulars auf eine neue Seite umgeleitet wird, auf der auch bereits der Link zum Bookingspage hinterlegt ist. In dem Fall, dass nun direkt ein Termin gebucht wird, könnte es passieren, dass der Lead im Dataverse noch überhaupt nicht angelegt wurde. Damit unser Flow dennoch seine Arbeit verrichten kann, sollten wir den Suchprozess solange wiederholen, bis der Lead gefunden wird (oder nach einer gewissen Zeit abbrechen).

Dafür nutzen wir eine „Do until“-Schleife, die z.B. für eine Stunde solange wiederholt wird, bis in der Variable für unsere Lead ID etwas enthalten ist. Innerhalb der Schleife wiederholen wir die zuvor definierten Schritte und fügen am Ende immer eine Wartezeit von einer Minute ein. Wenn nun irgendwann der Lead gefunden wird, wird die Schleife verlassen und wir haben dasselbe Ergebnis, als wenn der Lead von Beginn an gefunden worden wäre.

Jetzt, da wir alle notwendigen Daten haben, können wir unseren Custom Trigger auslösen. Dafür gibt es die Dataverse Action „Perform a background operation“.

Als Catalog wählen wir „Cxp“ (Customer Experience), als Category „Custom” und als Action name dann den Namen, den wir unserem Trigger gegeben haben. Anschließend erweitert sich die Actioncard und wir können unsere Informationen eintragen.

Spaltenname	Wert
msdynmkt_signalingestiontimestamp	@{utcNow()}
msdynmkt_signaltimestamp	@{utcNow()}
msdynmkt_signaluserauthid	@{variables(‚Lead ID‘)}
msdynmkt_profileid	@{variables(‚Lead ID‘)}

Die BindingID lassen wir leer, mit ihr könnten wir einzelne Journey-Läufe ansteuern, die denselben Lead enthalten. Ich gehe nicht davon aus, dass es in unserer Journey häufig zu parallel laufenden Journeys für denselben Lead kommen wird (dafür müsste das Formular innerhalb kurzer Zeit mit denselben Daten mehrfach ausgefüllt werden). Wenn es aber dazu käme, wollen wir ohnehin in allen Läufen für denselben Lead die Information erhalten, dass ein Termin gebucht wurde. Bleibt das Feld „msdynmkt_bindingid“ leer, erreichen wir genau dies.

Zu guter Letzt können wir im CRM noch einen Termin erstellen und an den Lead hängen (Achtung: Wenn Termine ohnehin aus Outlook synchronisiert werden, ist dieser Schritt wahrscheinlich überflüssig). Mit der Dataverse Action „Create new Row“ erstellen wir ein Appointment und fügen die wichtigsten Informationen ein. In meinem Fall waren dies:

Spaltenname	Wert
Betreff	Microsoft Bookings: @{triggerOutputs()?[‚body/ServiceName‘]}
Endzeit	@{triggerOutputs()?[‚body/EndTime‘]}
Startzeit	@{triggerOutputs()?[‚body/StartTime‘]}
Beschreibung	Details via MS Bookings: Email address: @{triggerOutputs()?[‚body/CustomerEmail‘]} Phonenumber: @{triggerOutputs()?[‚body/CustomerPhone‘]} Customer Location: @{triggerOutputs()?[‚body/CustomerLocation/DisplayName‘]}
Bezug (Leads)	leads(@{variables(‚Lead ID‘)})
Activity Party Attribute Name – 1	Organizer
Activity Party Attribute Value – 1	systemusers(@{variables(‚Lead Owner‘)})
Teilnahme-URL für Onlinebesprechung	@{triggerOutputs()?[‚body/JoinWebURL‘]}

Zu guter Letzt die Journey

Wir benötigen eine triggerbasierte Journey, die auf Submissions aus unserem anfangs erstellten Customer Insights Formular reagiert. Als Trigger wählen wir also „Marketing Form Submitted“ und wählen als Formularreferenz unser Formular aus.

Anschließend versenden wir die Bestätigungsmail über eine einfache Email Action.

Nun fügen wir eine „Wait for Trigger“ Condition ein, wählen aus „A trigger is activated“ und wählen anschließend unseren Custom Trigger aus. Als Zeitlimit kann prinzipiell alles gewählt werden, was aus geschäftlicher Sicht Sinn ergibt. Wir haben uns für 4 Stunden entschieden.

Wird der Trigger aktiviert, heißt das, der Flow ist gelaufen. Das wiederrum bedeutet, dass ein Termin durch den Lead gebucht worden ist. Damit ist unsere Journey an dieser Stelle fertig. Im Yes-Branch benötigen wir also keine weiteren Schritte mehr.

Wird der Trigger vier Stunden lang nicht ausgelöst, heißt das, dass keine Terminbuchung erfolgt ist. In diesem Fall sollten wir dem Vertrieb eine Aufgabe erstellen, dass sie sich mit dem Lead zwecks Terminvereinbarung in Verbindung setzen.

Wir haben diese Aufgabe wie folgt definiert:

Spaltenname	Wert
Subject	Make an appointment for a demo
Assign to	Lead owner
Due after	1 day
Notes to assignee	Lead filled out the webform for a free demo, but did not book an appointment afterwards. Contact lead for an appointment.

Im Ganzen sieht also unsere Journey am Ende so aus:

Grenzen des Prozesses

Ich hätte gern eine Möglichkeit gehabt, auf der Bookingspage die Kundendaten, die wir ohnehin über das erste Formular schon kennen, bei Öffnen der Seite vorauszufüllen. Leider bietet MS Bookings m.W. keine Möglichkeit an, auf der Bookingspage Custom Code zu hinterlegen, mit dem wir so etwas erreichen könnten. Evtl. müsste man dafür auf andere, komplexere Tools ausweichen.

Auch wünschte ich mir bei den Bookings-Connectoren, im Übrigen auch bei den Outlook-Connectoren von Power Automate, dass es Möglichkeiten gäbe, über ein Postfach hinaus zu agieren. Viele Kunden wünschen sich postfachübergreifende Automatisierungen, die bislang nur über Workarounds oder mit der Kopie des Flows in andere Postfächer funktionieren.

Was fällt Euch ein, um den Prozess auszuweiten oder zu verfeinern? Schreibt es in die Kommentare!

***Hinweis: Der Inhalt ist zum Zeitpunkt der Erstellung korrekt. Microsoft mag in der Zwischenzeit Änderungen vorgenommen haben.***