CourseSync: eine Make.com-Automatisierung vom Kurskauf in MindBody bis zur Klassenliste in HubSpot und zur Bestätigung an die Eltern

Ein Anbieter von Kursen mit mehreren Terminen hat für diese Automatisierung eine Spezifikation geschrieben. Eltern kaufen einen Kurs in MindBody und buchen die Termine danach selbst, oft ein paar Minuten später und nicht immer der Reihe nach.

Gesucht war eine Automatisierung, die danach den Kontakt in HubSpot aktualisiert, ihn in die richtige Klassenliste aufnimmt, die Anmeldung festhält und eine Bestätigung an die Eltern vorbereitet. Die Klassenlisten waren uneinheitlich benannt, und mehrere Buchungen aus einem Kauf konnten den Ablauf jeweils neu anstoßen.

• Ein Kauf in MindBody startet das Szenario über einen Webhook, weil der MindBody-Connector für Make keinen Auslöser für Verkäufe hat. Bevor das Szenario die Daten verwendet, prüft es die Signatur des Webhooks.
• Es wartet etwa zehn Minuten und sieht dann nach, ob ein Termin des Kurses gebucht ist. In MindBody liest es nur, es bucht und ändert dort nichts. Ist noch nichts gebucht, bittet es die Eltern per E-Mail um ihre Wunschtermine und hält an. Die Buchung schließt das Team dann von Hand ab.
• Mit einem Häkchen am Kontakt kann das Team die Wartezeit und die Buchungsprüfung überspringen. Die Datensätze werden trotzdem aktualisiert.
• Als Klassenliste nimmt es die Liste, deren Zeitraum den gebuchten Termin enthält und deren Name zur Stufe des Kurses passt und dazu, ob er vor Ort oder online stattfindet. Die Listennamen folgen keinem festen Muster. Deshalb wertet ein kleines Programm außerhalb von Make die Namen aus, und das Szenario ruft es auf. Passt keine Liste oder mehr als eine, meldet das Szenario den Fall mit allen Angaben per E-Mail an die Verwaltung und ändert nichts.
• Bevor es etwas schreibt, prüft es, ob der Kontakt schon auf dieser Liste steht. Dann hat eine frühere Buchung aus demselben Kauf die Arbeit bereits erledigt, und der Lauf endet dort.
• Danach trägt es den Kurs in die Kurshistorie des Kontakts ein, ohne frühere Kurse zu überschreiben, nimmt den Kontakt in die Klassenliste auf, schreibt als Nachweis außerhalb beider Systeme eine Zeile in ein Google Sheet und benachrichtigt das Team, wenn die Regeln des Kurses das vorsehen. In HubSpot schreibt es nur Felder mit eigenem Präfix und lässt alle anderen Felder unberührt.
• Die Bestätigung an die Eltern entsteht aus einer HubSpot-Vorlage, geht aber zuerst als Entwurf an die Verwaltung. Ein Mensch gibt den Wortlaut frei, bevor die Familie ihn zu sehen bekommt.

Eine Begleitseite spielt den ganzen Ablauf an einem erfundenen Schüler durch und zeigt, was jeder Schritt liest und schreibt. Dazu gehören ein importierbarer Make-Blueprint mit zwanzig Modulen in drei Routen und ein Runbook, das jedes Modul beschreibt.

Ich habe das Szenario in ein echtes Make-Konto importiert und dort laufen lassen. Die Änderungen in HubSpot, die Listenmitgliedschaft und die Zeile im Sheet habe ich mit echten Testkonten geprüft. Die Abfragen an MindBody und die Listenauswahl liefen gegen einen Nachbau der MindBody-API, und bei den E-Mails habe ich geprüft, dass jeder Pfad die richtige Sendeentscheidung trifft.

Der erste echte Lauf hat zwei Fehler gefunden, die eine reine Strukturprüfung des Blueprints nicht bemerkt hatte. Einige handgeschriebene HTTP-Module scheiterten erst zur Laufzeit, und Make wertete einen Filterausdruck als leeren Wert aus, sodass der Filter alles durchließ. Beides habe ich in dem Skript behoben, das den Blueprint erzeugt, und den Lauf danach fehlerfrei wiederholt.

Gebaut habe ich den Demonstrator nach dieser Spezifikation, mit erfundenen Daten und ohne Zugriff auf die Konten des Anbieters.