Lead-Automatisierung mit Make: Leitfaden 2026

Dieser Leitfaden gestaltet den Weg von der Einsendung zu einem verantworteten nächsten Schritt. Er beginnt mit einem kleinen Datensatz, trennt Personen von Ereignissen, ergänzt nachvollziehbare Qualifikationsregeln und wählt das passende Ziel. Beispiele verwenden fiktive Kontakte und bewusste Testfälle. Sie sind keine Kundenresultate, Verkehrsmessungen oder Zusagen zusätzlicher Verkäufe.

Du kannst den Ablauf mit der verlinkten Dokumentation selbst bauen. Als Ausgangspunkt bietet Flowpaja vorhandene kostenlose Vorlagen und den kostenpflichtigen Lead Router. Dieser verbindet Google Forms, HubSpot und Slack mit budgetabhängigem Routing. Er verteilt Leads nicht per Round-Robin. Wähle den Ablauf nach der Aufgabe des nächsten Bearbeiters, nicht nach der Zahl der Apps auf der Arbeitsfläche.

1. Ein sinnvolles Ergebnis vor den Modulen definieren

Schreibe das gewünschte Ergebnis in einen Satz: „Wenn jemand unser Anfrageformular absendet, halten wir einen Kontakt fest, speichern die Anfrage und benachrichtigen den zuständigen Verantwortlichen.“ Darin stecken drei Aufgaben. Ein Kontakt repräsentiert die Person. Eine Anfrage repräsentiert deren Handlung. Ein Hinweis fordert jemanden zur Antwort auf. Alles in einer Tabellenzeile zusammenzufassen kann anfangs funktionieren. Du musst aber verstehen, welche Daten eine spätere Einsendung überschreibt.

Entscheide, wer den nächsten Schritt übernimmt und wo diese Person arbeitet. Slack passt, wenn der Verantwortliche Slack verwendet. Eine E-Mail an den Eigentümer passt, wenn tägliche Sichtung genügt. Ein CRM hilft bei Phasen, Notizen und mehreren Bearbeitern. Dieselben Daten an drei Ziele zu senden schafft drei Pflegeorte. Beginne mit der kleinsten nützlichen Zielmenge.

Definiere auch eine Stoppregel. Wiederholte Zustellung desselben Ereignisses darf beispielsweise keinen zweiten Hinweis auslösen. Eine bekannte Person mit einer echten neuen Anfrage kann dagegen einen weiteren Hinweis verdienen. Eine leere E-Mail gehört in einen Prüfpfad, nicht in einen gemeinsam verwendeten „unbekannt“-Kontakt. Diese Entscheidungen bestimmen Filter direkter als der Formularanbieter.

Notiere für den ersten Aufbau Formular, Ziel, Identitätsregel, Qualifikationsfelder, Verantwortlichen und erwartete Reaktion. Das wird die Abnahmeliste. Ein grünes Ausführungssymbol genügt nicht: Prüfe auch den Datensatz und die Zielnachricht.

2. Kleinen, ausdrücklichen Datenvertrag verwenden

Ein praktischer Vertrag umfasst event_id, submitted_at, email, name, company, budget_amount, budget_currency, source und message. Optionale Felder bleiben optional. Fehlendes Budget ist unbekannt, nicht 0. Fehlendes Unternehmen macht eine Anfrage nicht automatisch ungültig. Eine fehlende E-Mail verhindert aber eine sinnvolle E-Mail-Kontaktsuche.

Halte bei der Fehlersuche Originalwerte neben normalisierten Werten fest, etwa email_raw und email_key. Normalisiere den Vergleichsschlüssel mit lower(trim(email)). Entferne weder Punkte noch Plus-Tags und unterstelle nicht, dass jede Adresse Gmail gehört. Solche Änderungen können verschiedene Kontakte zusammenführen. Normalisierung ist eine Vergleichsregel, kein Identitätsnachweis.

Budgeteinheiten müssen klar sein. 10000 bedeutet wenig ohne Währung und Zeitraum. Jahres-, Monats- und einmaliges Projektbudget sind unterschiedliche Signale. Die Beispiele verwenden ein fiktives einmaliges USD-Budget. Währungen nur mit bestätigter Umrechnungsquelle und festgelegtem Kursdatum umrechnen.

Diese Feldnamen sind ein vorgeschlagener Vertrag, keine zugesicherten Ausgabefelder des Anbieters. Ordne sie aus einer erfassten Einsendung zu. Bestätige Feldpfad und Datentyp für deinen konkreten Trigger.

3. Formulare mit dem passenden Trigger erfassen

Google Forms kann Antworten in eine verbundene Google-Tabelle schreiben. Google Sheets › Watch New Rows kann neue Zeilen nach einem Zeitplan erfassen. Das ist ein einfacher Einstieg, bringt aber regelmäßige Prüfungen und einen Startpunkt mit. Halte Überschriften stabil und vermeide Leerzeilen innerhalb der überwachten Tabelle. Eine vorhandene Antwort zu bearbeiten erzeugt nicht zwangsläufig eine neue Zeile oder einen neuen Triggerlauf.

Flowpaja hat bereits einen Leitfaden zu Google Forms, HubSpot und Slack. Verwende ihn für die Erstverbindung. Die Erweiterung für bearbeitete Antworten aus dem früheren EN-Paket behandelt eine andere Frage: bestehende Daten aktualisieren, ohne jede Prüfung als neue Anfrage zu behandeln.

Ein sofortiger Formulartrigger kann geplante Leerprüfungen vermeiden, wenn Anbieter und Konto ihn unterstützen. Make bietet Typeform-Antwortmodule und eine Tally-Verbindung. Der Ausgabevertrag hängt trotzdem von Fragen und Verbindung ab. Eine sichtbare Frage umzubenennen garantiert nicht, dass ihr Mappingtoken gleich bleibt. Erfasse nach Formularänderungen ein neues Beispiel.

Ein allgemeiner Webhook eignet sich, wenn das Formular eine dokumentierte HTTP-Anfrage senden kann. Füge Webhooks › Custom webhook hinzu, erstelle einen neuen Webhook und verwende Detect new values bei einer fiktiven Einsendung. Erkannte Struktur erleichtert Mapping, macht aber nicht alle künftigen Felder vertrauenswürdig. Prüfe Pflichtfelder vor Zeile oder Kontakt.

4. Webhook-Vertrag vor echten Formularen testen

Verwende ein privates Testszenario mit Testtabelle und Testziel. Das folgende Beispiel beschreibt eine Anfrage; sie wurde hier nicht gesendet. Ersetze den Platzhalter nur in deiner Testumgebung. Adresse und Ereignis sind absichtlich fiktiv.

curl -X POST "$MAKE_TEST_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  --data '{"event_id":"enquiry-001","email":"alex@example.invalid","name":"Alex Example","budget_amount":10000,"budget_currency":"USD","source":"test-form"}'

Prüfe das Triggerbündel. Ist budget_amount Number oder Text? Liegt die E-Mail am erwarteten Pfad? Braucht eine verschachtelte Antwort eine ausdrückliche Zuordnung vor Sheets? Teste mit derselben Ereignis-ID eine Wiederholung. Teste mit neuer Ereignis-ID und gleicher E-Mail einen wiederkehrenden Kontakt.

Schütze den Webhook mit den vom Anbieter und Make unterstützten Authentifizierungsoptionen. Veröffentliche die private URL nicht in Downloads, Screenshots oder Beispiel-Repositories. Bei ausgehendem HTTP bestimmt Return error if HTTP request fails, ob 4xx oder 5xx zum Szenariofehler wird. Prüfe die Antwort für die Wiederherstellung. Ein Timeout beweist nicht, dass die entfernte Schreibaktion ausblieb.

5. Facebook Lead Ads als eigene Quelle behandeln

Facebook Lead Ads erfasst Anfragen, ohne die Person zuerst auf eine Website zu schicken. Make dokumentiert New Lead, Watch Leads und Get Lead Details. Seiten- und Lead-Zugriff müssen richtig eingerichtet sein. Ein sichtbares Werbekonto beweist nicht, dass die Make-Verbindung Lead-Zugriff hat.

Erfasse vor CRM-Schreibaktionen einen Test-Lead und prüfe die Antworten. Ordne anhand tatsächlich ausgegebener Kennungen zu. Untersuche fehlende Antworten, Checkboxen und Telefonnummern. Eine Anbieter-Lead-ID ist ein nützlicher Ereignisschlüssel, weil wiederholte Zustellung dieselbe ID behalten kann. Bewahre Seiten- und Formularkontext daneben, falls das für kollisionsfreie Identität nötig ist.

Dieser Leitfaden wiederholt keine bestehenden Facebook-Inhalte und erstellt keine Werbekampagne. Der Annahmeaufbau muss auch mit fiktiven Fixtures prüfbar sein. Liefert der Anbieter-Test nicht an den gewählten Trigger, behebe zuerst den Zugriff. Erkläre nicht die gesamte Strecke für fertig.

Reichere Leads nicht automatisch an, nur weil eine App das kann. Eine Anfrage lässt sich aus erklärtem Budget, Projekttyp und Termin bewerten. Ergänze eine kostenpflichtige Suche erst, wenn klar ist, welche Entscheidung ihre Daten ändern.

6. Kontakt- und Ereignisduplikate trennen

E-Mail-Dedupe fragt: „Kennen wir diese Person unter diesem Schlüssel?“ Ereignis-Dedupe fragt: „Haben wir diese Einsendung bereits behandelt?“ Eine Person kann zwei echte Anfragen senden. Eine Anfrage kann nach einem Timeout zweimal zugestellt werden.

In einer einfachen Kontakttabelle sucht Google Sheets › Search Rows in der normalisierten E-Mail-Spalte. Ohne Treffer entsteht ein leeres Bündel mit Total number of bundles = 0. Route anhand dieser Zahl: = 0 für neu, > 0 für vorhanden. Verwende nicht die Arraylänge eines Aggregators. Lege Limit und Behandlung mehrerer Treffer fest. Mehrere passende Zeilen sind ein Datenproblem, keine Erlaubnis zum blinden Mehrfachupdate.

Für Wiederholungsschutz brauchst du zusätzlich die stabile Ereignis-ID. Ein Ereignisdatensatz kann Bearbeitungsphase, Ziel-ID und letzten Versuch enthalten. Die Markierung vor einer externen Aktion verringert ein Risiko, schafft aber ein anderes: Ein fehlgeschlagener Schreibschritt kann einen markierten Datensatz zurücklassen. Verwende Zwischenzustände statt „reserviert“ mit „zugestellt“ gleichzusetzen.

Suchen und Erstellen ist keine atomare Transaktion. Zwei parallele Läufe können beide keinen Treffer sehen. Sequenzielle Verarbeitung hilft bei einem einzigen schreibenden Szenario, schützt aber nicht gegen andere Szenarien oder manuelle Aktionen. Definiere den Schutzbereich und teste gleichzeitige Einsendungen, bevor du Duplikatsicherheit versprichst.

7. CRM-Identität und Eigenschaftszuordnung präzise halten

HubSpot kann Kontakte suchen und danach erstellen oder aktualisieren. Make dokumentiert Search for Contacts, Create a Contact, Update a Contact und Create or Update a Contact. Wähle verstandenes Verhalten und prüfe die ausgegebene Kontakt-ID. Übertrage nicht ungeprüft die Sheets-Semantik leerer Suchbündel auf HubSpot.

Exakte E-Mail-Suche passt zum Lead-Router-Umfang. Sie bedeutet weder unscharfe Unternehmenssuche noch Aliasauflösung oder automatische Bereinigung eines unordentlichen CRM. Bewahre vorhandene Informationen, wenn eine neue Einsendung ein optionales Feld leer lässt. Entscheide, ob das neueste Budget den Kontaktwert ersetzt oder eine getrennte Anfrage bildet.

Auswahlfelder brauchen einen eigenen Test. Sichtbare Bezeichnung und interner Wert können verschieden sein. Mappe den vom Zielportal akzeptierten internen Wert, nicht bloß den Formulartext. Werte eines kopierten Testportals gelten nicht überall. Prüfe Eigenschaften und erlaubte Werte im tatsächlichen Portal.

Ein CRM-Fehler muss den Erfolgshinweis verhindern. „Neuer Kontakt erstellt“ ist falsch, wenn das Erstellen scheiterte. Der Fehlerpfad braucht eine minimale Ereignisreferenz und Phase. Poste weder die ganze Anfrage noch Authentifizierungsdaten in einen breiten Kanal.

8. Leads anhand erklärter Fakten bewerten

Beginne mit erklärbaren Regeln. Ein fiktives System gibt zwei Punkte für bekanntes USD-Budget ab 10000, einen für erklärte Teamgröße ab zehn und einen für eine tatsächlich angebotene Leistung. Das sind Entwurfsentscheidungen, keine gemessenen Kaufwahrscheinlichkeiten.

Halte Eingaben, Ergebnis und Grund zusammen. „Score 3: Budgetschwelle erfüllt; Leistung angeboten“ ist hilfreicher als „KI sagt heiß“. Fehlendes Budget braucht den Grund „Budget unbekannt“, nicht „Budget null“. Ein niedriger Score soll zur normalen Sichtung führen statt eine echte Anfrage still zu löschen.

Regeln können in Sheets-Hilfsspalten oder in Make nach der Zuordnung stehen. Wähle eine einzige maßgebliche Stelle. Ändert jemand die Schwelle in der Tabelle, während Make eine feste alte Zahl nutzt, widersprechen sich Hinweis und Score. Notiere beim Testen die Regelversion.

Teste Grenzen: 9999, 10000 und 10001; null, leer und nichtnumerisch; USD und andere Währung. Eine Regel ist nicht fertig, weil der Beispielwert funktioniert. Versprich weder Konversion noch Käufe durch „heiße“ Leads.

9. Hinweise an einem echten nächsten Schritt ausrichten

Budgetrouting kann qualifizierte Anfragen in einen fokussierten Slack-Kanal und andere in einen allgemeinen Kanal leiten. Das Slack-Modul heißt Send a Message. Füge die App bei Bedarf dem Zielkanal hinzu und teste den tatsächlich ausgewählten Kanal. Sein Name auf einem Screenshot beweist keine Schreibberechtigung.

Nachrichten brauchen Anfrage-ID, Name, Quelle, Qualifikationsgrund und den zu öffnenden Datensatz. Verhindere unbeabsichtigte breite Erwähnungen oder Formatierung durch Nutzereingaben, soweit die Moduloptionen das ermöglichen. Sende Tests nur in einen privaten Testkanal. Ersetze den festen Eigentümerempfänger nicht durch eine echte Kundenadresse.

Für E-Mail-Hinweise bleibt die Eigentümeradresse fest und sichtbar. Die Einsenderadresse steht nur im Inhalt, wenn sie für die Bearbeitung nötig ist. Eigentümerhinweis und automatische Antwort an den Anfragenden sind unterschiedliche Produkte mit unterschiedlichen Fehler- und Duplikatrisiken. Entscheide bewusst vor Gmail › Send an email.

Round-Robin-Zuweisung ist ebenfalls eine eigene Aufgabe. Sie braucht eine verfügbare Bearbeiterliste, einen Zeiger, Regeln für Abwesenheit und Konkurrenzschutz. Der frühere EN-Paketentwurf behandelt diesen Aufbau getrennt. Budgetkanäle des Lead Router sind keine Round-Robin-Eigentümerzuweisung.

10. Fehler nach dem tatsächlichen Ergebnis behandeln

Verwende aktuelle Namen: Retry (früher Break), Skip (früher Ignore), Resume, Commit und Rollback. Wähle nach den Daten, die bleiben sollen, und der Arbeit, die fortgesetzt werden darf. Retry hilft bei behebbaren Fehlern mit entsprechend konfigurierten unvollständigen Ausführungen. Externe Nebenwirkungen müssen trotzdem sicher wiederholbar sein.

Skip verwirft das betroffene Bündel. Es kann spätere Arbeit ermöglichen, ist aber keine allgemeine Lösung für verlorene Leads. Resume liefert Ersatz-Ausgabe. Verwende das nur mit sinnvoller Bedeutung, beispielsweise einer ausdrücklich unbekannten optionalen Suchantwort. Erfinde keine Kontakt-ID für fehlgeschlagenes Erstellen.

Commit und Rollback beziehen sich auf unterstütztes Transaktionsverhalten. Sie machen keine zugestellte Slack-Nachricht oder E-Mail rückgängig. Bestimme vor dem Handler die letzte unumkehrbare Aktion. Halte genug Zustand fest, um „CRM fertig, Hinweis fehlgeschlagen“ von „CRM fehlgeschlagen, Hinweis nicht versucht“ zu trennen.

Kopiere bekannte Fehler aus der tatsächlichen Ausführung. Allgemeine Dokumentation enthält There is no scenario listening for this webhook und Module initialization failed with an error. Anbieterfehler unterscheiden sich. Notiere den exakten eigenen Fehler, bevor du ihn veröffentlichst. Ein nützlicher Fehlerdatensatz enthält Ereignis-ID, Modul, Zeit und Ergebnis, nicht jedes persönliche Feld.

11. Credits mit ausdrücklich erklärter Rechnung planen

Für gewöhnliche Module mit festen Credits modellierst du geplante Prüfungen, ausgeführte Aktionen und Bündel. Angezeigte Routerpfade beweisen nicht, dass alle liefen. Ein übersprungener Pfad darf nicht wie eine gesendete Nachricht zählen. Prüfe die Credit-Dokumentation deiner Module; KI und andere dynamische Kosten brauchen ein anderes Modell.

Ständiges Polling alle 15 Minuten ergibt vier Prüfungen pro Stunde: 4 × 24 × 30 = 2880 in 30 Tagen. Bei ausdrücklich angenommenem einem Credit je Prüfung sind das 2880 Credits vor Lead-Verarbeitung. Das ist eine Rechnung, keine gemessene Rechnung dieses Pakets. In 31 Tagen sind es unter derselben Annahme 2976 Prüfungen.

Angenommen, ein Szenario prüft 720-mal monatlich und verarbeitet 50 Leads mit je drei weiteren Ein-Credit-Aktionen. Das Modell ist 720 + 50 × 3 = 870. Wiederholungen, weitere Hinweise, Suchen und andere Szenarien fehlen darin. Es ist ein Entwurfsbeispiel, nicht die gemessene Rechnung des Lead Router.

Make Free umfasst aktuell 1000 Credits monatlich, zwei aktive Szenarien, mindestens 15 Minuten geplanten Abstand und höchstens fünf Minuten Laufzeit. Sofortige Webhooks unterscheiden sich vom Polling; rechne sie nicht als 15-Minuten-Prüfungen. Kontogrenzen werden gemeinsam genutzt. Kostenloser Download bedeutet nicht kostenlose Ausführung jeder Kombination von Apps und Zeitplänen.

12. Datensatz, Pfad und Wiederherstellung testen

Erstelle Testtabelle, Test-CRM und Testkanal. Adressen enden auf example.invalid. Solche Fixtures beweisen weder Nachfrage noch Einwilligung, zugestellte Kundenpost oder Einkommen. Lege erwartete Ergebnisse vorher fest, damit plausible Ausgabe nicht mit bestandenem Test verwechselt wird.

Teste neuen Kontakt, exakt wiederholtes Ereignis, bekannten Kontakt mit neuem Ereignis und leeres Pflichtfeld. Ergänze Schwellenwert und Nicht-USD-Budget. Prüfe Pfad und geschriebene Felder. Die Duplikatroute darf keinen zweiten Slack-Hinweis erzeugen, wenn die Spezifikation das ausschließt.

Teste danach die Wiederherstellung. Trenne oder verstelle bewusst ein Testziel, beobachte den Fehler und stelle es wieder her. Erzeugt Wiederholung eine neue Zeile? Aktualisiert sie den richtigen Kontakt? Wiederholt sie einen bereits erfolgreichen Hinweis? Der Ereignisschlüssel bleibt gleich; ein neuer Schlüssel entwertet diesen Test.

Prüfe zuletzt Lebenszyklusänderungen. Eine geänderte Buchung ist keine neue Person. Eine zurückgezogene Anfrage braucht möglicherweise Statusänderung. Geänderte E-Mail kann manuelle Abstimmung statt automatisches Zusammenführen brauchen. Dokumentiere nicht sicher entscheidbare Fälle und leite sie zum Verantwortlichen.

13. Vorhandene Vorlage passend zur Aufgabe wählen

Für ein allgemeines Webhook-Formular beginne mit Webhook to Sheets mit Duplikatprüfung. Der dokumentierte Schlüssel ist request_id; bewahre ihn bei Wiederholung. Für Google-Forms-Hinweise nutze Form responses to Slack. Beide ergänzen kein HubSpot-Kontaktmanagement.

Für Google Forms, HubSpot-Updates und budgetabhängige Slack-Kanäle gibt es Lead Router für 19 USD. Der Kauf bietet Blueprint und Einrichtungsmaterial. Er ist weder Hostingdienst noch Zuweisungsalgorithmus oder Zusage sofortiger Forms-Verarbeitung. Die Antworttabelle wird im gewählten Zeitplan geprüft.

Für überfällige Rechnungen sendet Overdue Invoice Digest eine Zusammenfassung an den Eigentümer. Invoice Reminder ist der kostenpflichtige Kunden-Erinnerungsablauf. Verkaufe einen Digest nicht als automatische Einziehung oder Bankabgleich.

Für ein Make-Konto nutze https://www.make.com/en/register?pc=flowpaja: affiliate link. Ersetze den Platzhalter erst nach Prüfung von Ziel und Zugehörigkeit. Beispiele bleiben Dateianleitungen. Deine Einrichtung braucht eigene Verbindungen, Zuordnungen und Ausführungstests.

14. Themenspezifische Baunotizen nutzen

Die EN-Quelldatei verweist auf lokale Entwürfe ihres früheren Pakets, nicht auf zehn bestätigte neue öffentliche Seiten. Hier stehen die vollständigen Themenhinweise ohne nicht mitgelieferte Paketlinks. Eine öffentliche kanonische URL muss vor Verlinkung freigegeben werden.

1. Bearbeitete Google-Forms-Antworten und sichere CRM-Updates: geänderte Zeilen behandeln, ohne jeden Hinweis zu wiederholen.
2. HubSpot-Kontaktduplikatfehler: Identität, Kollisionen und sichere Wiederherstellung untersuchen.
3. Typeform-Budgetqualifikation: qualifizierten Hinweis von allgemeiner Antwortbenachrichtigung unterscheiden.
4. Optionale Tally-Felder und Budgetmapping: Arrays, Leerantworten und Währung behandeln.
5. Webflow-Formulare zum CRM: Formularidentität und Ereigniszustand bewahren.
6. WordPress-Webhook-Verträge: Plugins integrieren, ohne native Webhook-Unterstützung zu unterstellen.
7. Nachvollziehbarer Lead-Score in Sheets: erklärte Fakten und sichtbare Regeln verwenden.
8. Round-Robin mit Data Store: Eigentümer getrennt von Budgetkanälen zuweisen.
9. Calendly-Buchungslebenszyklus: Erstellen, Verschieben und Stornieren bewusst behandeln.
10. Webhook-Ereignis- und E-Mail-Dedupe: Wiederholungen blockieren, ohne neue Anfragen zu verwerfen.

15. Eine beantwortbare Freigabeliste

Prüfe vor Aktivierung den dokumentierten Datenvertrag, Pflichtfeldprüfung und richtigen Leer-Suchpfad. Testziele müssen klar markiert sein. Ersetze Beispielschwellen erst nach Zustimmung des Eigentümers zu ihrer Bedeutung. Bewahre eine funktionierende Blueprint-Kopie ohne Kontogeheimnisse auf.

Der Hinweis muss tatsächliche Ergebnisse melden, keine Hoffnungen. Teste fehlgeschlagenes Schreiben und fehlgeschlagene Benachrichtigung getrennt. Vergleiche den Zeitplan mit der gemeinsam genutzten Credit-Grenze. Notiere beobachtete Credits nach dem Test; vorher bleiben sie unbekannt.

Übergebe dann eine Betriebsnotiz: wo Schwellen geändert werden, wo fehlgeschlagene Anfragen liegen, was sicher wiederholbar ist und wann pausiert werden soll. Das Ergebnis ist ein bedienbarer Ablauf statt nur eine schöne Arbeitsfläche. Diese Ausführungstests müssen im echten Konto stattfinden; dieses Paket hat sie nicht ausgeführt.