Wenn Anfragen aus Website-Formularen, Calendly-Buchungen oder E-Mails in verschiedenen Ecken landen, ist nicht das Volumen das Problem, sondern der fehlende Prozess. Mit Zapier und Notion lässt sich ein klarer Intake aufbauen: Eingang erfassen, Daten prüfen, Kontakt anlegen, Aufgabe erzeugen und offene Fälle sichtbar halten.
Warum Zapier und Notion für einen CRM-Intake gut zusammenpassen
Zapier eignet sich für Selbstständige und kleine Teams besonders dann, wenn Standard-Integrationen schnell produktiv werden sollen. Notion passt als leichtgewichtige Arbeitsoberfläche dazu, wenn Kontakte, Anfragen und nächste Schritte an einem Ort sichtbar sein sollen.
Die Kombination ist kein vollwertiges CRM im Enterprise-Sinn. Für Erstkontakt, Vorqualifizierung und Nachfassen reicht sie aber oft aus, solange der Prozess sauber modelliert ist. Zapier übernimmt dabei die Ereignislogik: Ein Trigger (das auslösende Ereignis am Anfang eines Workflows) startet den Zap, Filter prüfen Bedingungen, und eine oder mehrere Actions schreiben strukturierte Datensätze nach Notion.
Technisch wichtig ist die Rollenverteilung. Zapier ist task-basiert und deshalb dann sinnvoll, wenn jeder Lauf einen klaren Nutzen hat und nicht zu viele Zwischenaktionen braucht. Notion ist keine klassische relationale Datenbank wie Airtable, kann aber mit Datenbanken, Select-Feldern, Relations und Statusfeldern einen belastbaren Intake-Prozess tragen.
Typisch ist diese Kette: Formular-Eingang → Filter auf vollständige Pflichtfelder → Kontakt in Notion suchen → bei Treffer aktualisieren, sonst neu anlegen → Aufgabe für Rückruf oder Angebot erzeugen. Gerade für Einzelunternehmer spart das nicht „Stunden von selbst“, aber es spart zuverlässig die manuelle Übertragung zwischen Formular, Postfach und Aufgabenliste.
- Lege in Notion zuerst getrennte Datenbanken für Kontakte, Anfragen und Aufgaben an.
- Definiere pro Datenbank eindeutige Felder wie E-Mail, Status, Quelle und nächster Schritt.
- Starte in Zapier mit einem einzigen Eingangskanal und erweitere erst danach auf weitere Trigger.
- Nutze Filter früh im Zap, damit unvollständige oder irrelevante Datensätze keine Tasks verbrauchen.
- Plane von Anfang an ein Feld für Fehlerhinweise oder manuelle Prüfung ein.
Welche Notion-Struktur den Workflow wirklich trägt
Der Erfolg des Workflows hängt weniger am Tool als an der Datenstruktur. Ein CRM-Intake in Notion funktioniert nur dann stabil, wenn Felder eindeutig benannt sind und jede Zeile eine klare Rolle im Prozess hat.
Für Selbstständige reicht meist ein Setup aus drei Datenbanken: Kontakte, Anfragen, Aufgaben. In Kontakte liegen stabile Stammdaten wie Name, E-Mail, Firma, Website und Segment. In Anfragen werden konkrete Eingänge gespeichert, etwa Formularanfragen, Buchungswünsche oder Projektbriefings. Die Aufgaben-Datenbank bildet ab, was als Nächstes passieren muss: Rückruf, Angebotsentwurf, Erinnerung oder Absage.
Wichtig ist die Trennung zwischen Person und Ereignis. Wenn jede neue Anfrage einfach als neuer Kontakt angelegt wird, entstehen Dubletten und der Verlauf wird unübersichtlich. Besser ist: Ein Kontakt kann mehrere Anfragen haben, und jede Anfrage kann eine oder mehrere Aufgaben auslösen. Diese Logik wirkt zunächst formaler, reduziert aber spätere Nacharbeit deutlich.
In der Praxis tragen wenige Felder den größten Teil des Systems: E-Mail als Suchschlüssel, Status für die Bearbeitung, Quelle für den Ursprung, Priorität für die Reihenfolge und ein Datumsfeld für das letzte Ereignis. Wer ähnliche Übergaben schon zwischen Tools baut, merkt schnell, dass die passende Datenbasis darüber entscheidet, ob ein Workflow robust bleibt oder nur gut aussieht.
Ein einfaches Schema kann so aussehen:
Kontakte: Name | E-Mail | Firma | Status | Letzter Kontakt
Anfragen: Titel | Kontakt-Relation | Quelle | Bedarf | Status | Eingangsdatum
Aufgaben: Aufgabe | Anfrage-Relation | Fällig am | Zuständig | StatusDiese Struktur lässt sich später erweitern, etwa um Angebotsstatus, Umsatzpotenzial oder Lead-Quelle. Für den Start ist wichtiger, dass Suchfelder konsistent sind und keine Freitext-Orgie entsteht.
So baut der Zap den Intake von Formular bis Follow-up auf
Ein stabiler Intake-Zap sollte immer erst prüfen und dann schreiben. Die Kernlogik lautet: Eingang empfangen, bereinigen, vorhandenen Kontakt finden, Datensatz aktualisieren oder anlegen und anschließend die nächste Aktion erzeugen.
Ein realistischer Aufbau in Zapier für ein Website-Formular sieht so aus. Trigger: neuer Form Submit, etwa aus Typeform, Webflow Forms oder einem anderen unterstützten Formular-Tool. Danach folgt idealerweise ein Formatter-Schritt, der Leerzeichen entfernt, E-Mail-Adressen vereinheitlicht oder Auswahlfelder in ein sauberes Format bringt. Anschließend prüft ein Filter, ob E-Mail, Name und Anliegen vorhanden sind.
Der nächste Schritt ist entscheidend: erst suchen, dann schreiben. Verwende in Zapier eine Search Action für den Kontakt in Notion anhand der E-Mail-Adresse. Gibt es einen Treffer, wird der bestehende Kontakt aktualisiert; gibt es keinen, wird ein neuer Kontakt erstellt. Danach wird in jedem Fall eine neue Anfrage in der Anfragen-Datenbank angelegt und mit dem Kontakt verknüpft.
Zum Schluss erzeugt der Zap eine Aufgabe. Diese Action sollte nicht nur „Follow-up“ heißen, sondern konkrete Regeln abbilden, etwa „Rückruf innerhalb von 1 Werktag“, wenn Budget oder Projektart dafür sprechen. Wer Intake und Nachfassen koppeln will, profitiert oft davon, dass saubere Follow-up-Logik nicht im Postfach, sondern im Workflow beginnt.
- Richte den Formular-Trigger ein und teste mit einem echten Beispieldatensatz.
- Normalisiere Eingaben mit Formatter, vor allem E-Mail, Telefonnummer und Auswahlfelder.
- Suche den Kontakt per E-Mail in Notion, bevor du neue Datensätze anlegst.
- Erstelle die Anfrage immer als separates Ereignis und verknüpfe sie mit dem Kontakt.
- Lege direkt eine Aufgabe mit Fälligkeitsdatum und Bearbeitungsstatus an.
- Sende bei Fehlern optional eine interne Benachrichtigung per E-Mail oder Slack.
Was ist bei Dubletten, unvollständigen Daten und Fehlern wichtig?
Error-Handling ist im CRM-Intake wichtiger als der Happy Path. Der eigentliche Nutzen entsteht nicht dadurch, dass perfekte Datensätze automatisch ankommen, sondern dadurch, dass fehlerhafte Eingänge sichtbar werden und den Prozess nicht still beschädigen.
Der häufigste Fehlerfall sind Dubletten. Sie entstehen meist nicht durch das Tool, sondern durch unterschiedliche Schreibweisen, zweite Formulareinreichungen oder wechselnde geschäftliche und private E-Mail-Adressen. Deshalb sollte die E-Mail zwar der erste Suchschlüssel sein, aber nicht der einzige Prüfpunkt. Wenn E-Mail fehlt oder sich ändert, hilft ein zusätzlicher Review-Status statt einer blinden Neuerstellung.
Der zweite Problemblock sind unvollständige Angaben. Ein Zap sollte solche Datensätze nicht einfach in dieselbe Bearbeitungsschlange schieben wie saubere Leads. Sinnvoll ist ein separater Status wie „Prüfen“ oder „Unvollständig“, kombiniert mit einer Aufgabe zur manuellen Nachsicht. So bleibt der Workflow nachvollziehbar, ohne fragwürdige Daten still weiterzureichen.
Drittens braucht jeder produktive Ablauf eine Fehlerreaktion. In Zapier heißt das praktisch: kritische Schritte klein halten, Abhängigkeiten reduzieren und Benachrichtigungen für fehlgeschlagene Runs aktivieren. Auch wenn andere Tools wie n8n bei komplexen Branches und Wiederholungslogik mehr Tiefe bieten, reicht Zapier für viele Intake-Prozesse aus, solange die Ausnahmen bewusst modelliert sind. Wer Trigger-Arten grundlegend sauber einordnet, baut mit passender Trigger-Logik stabilere Abläufe.
| Fehlerfall | Typische Ursache | Sinnvolle Reaktion |
|---|---|---|
| Doppelter Kontakt | Mehrfache Einreichung oder zweite Mailadresse | Search vor Create, Status „Prüfen“, manuelle Freigabe |
| Leere Pflichtfelder | Schwaches Formular oder fehlerhafte Übergabe | Filter stoppen, Aufgabe zur Nachprüfung erzeugen |
| Notion-Feld passt nicht | Geänderte Property oder falsches Mapping | Zap-Test erneut fahren, Feldnamen vereinheitlichen |
| Verpasster Follow-up | Aufgabe ohne Fälligkeit oder Status | Pflichtfelder in der Aufgaben-Datenbank ergänzen |
Wann reicht Zapier aus – und wann nicht mehr?
Für standardisierte Intake-Prozesse mit wenigen Verzweigungen reicht Zapier oft völlig aus. Wenn aber mehrere Bedingungen, Schleifen, API-Sonderfälle oder eigene Retry-Strategien nötig werden, stößt ein einfacher Zap schneller an Grenzen als ein visuell tieferes Tool.
Für Selbstständige ist der entscheidende Punkt nicht „mächtiger oder schwächer“, sondern „welcher Prozess muss zuverlässig laufen“. Zapier ist stark, wenn Trigger und Actions aus verbreiteten SaaS-Tools kommen, die Integrationen sauber gepflegt sind und der Ablauf in überschaubaren Schritten bleibt. Typische Beispiele sind Formular zu Notion, Kalenderbuchung zu Aufgabe oder Lead zu E-Mail-Benachrichtigung.
Grenzwertig wird es, wenn der Intake stark verzweigt. Etwa dann, wenn unterschiedliche Formulare je nach Leistung in verschiedene Pipelines laufen, mehrere Datenquellen zusammengeführt werden oder vor dem Anlegen noch API-Abfragen gegen externe Systeme erfolgen. In solchen Fällen sind Make oder n8n oft transparenter, weil Branching, Datenmanipulation und Fehlerpfade stärker im Canvas sichtbar sind. Für KMU kann auch ein Wechsel sinnvoll sein, wenn aus dem Intake später ein kompletter Vertriebsprozess wird.
Das bedeutet nicht, dass Zapier „zu einfach“ wäre. Es bedeutet nur: Ein gutes Werkzeug bleibt gut, solange es zum Prozess passt. Wer vor allem schnelle Standardübergaben zwischen Formular, Notion und Aufgaben braucht, fährt mit Zapier häufig stabiler als mit einem überkomplexen Setup.
Welche Grenze oft zuerst erreicht wird
Nicht die Anzahl der Kontakte ist meist das Problem, sondern die Anzahl der Sonderregeln. Sobald für jede Quelle, jede Leistung und jede Ausnahme ein eigener Pfad entsteht, wächst auch die Wartung. Dann lohnt sich eine Bestandsaufnahme: Welche Schritte sind echte Geschäftslogik, und welche sind nur Workarounds für schlechte Eingabedaten?
Wie ein realistischer Ausbau aussieht
Ein sinnvoller nächster Schritt ist selten ein Toolwechsel, sondern ein zweiter sauberer Zap. Statt einen Mega-Zap zu bauen, kann ein erster Zap den Intake strukturieren und ein zweiter Zap nur das Nachfassen oder die Qualifizierung übernehmen. Das macht Tests einfacher und Fehlerursachen klarer.
Wie bleibt der Workflow im Alltag wartbar?
Workflow-Automatisierung ist im Alltag nur dann hilfreich, wenn sie beobachtbar bleibt. Ein Intake-Setup sollte deshalb nicht nur Daten schreiben, sondern auch sichtbar machen, wo etwas hängen bleibt, wer als Nächstes dran ist und welche Felder für Folgeprozesse wirklich gebraucht werden.
Zur Wartbarkeit gehört zuerst ein schlankes Naming. Benenne Zaps nach Prozess und Zweck, zum Beispiel „Formular zu Kontakt + Anfrage“ statt nur „Lead Intake“. Auch in Notion helfen klare Statuswerte wie „Neu“, „Prüfen“, „In Arbeit“, „Wartet“ und „Erledigt“ mehr als kreative Freitextlösungen. So werden Views belastbar und spätere Automationen einfacher.
Ebenso wichtig ist der Umgang mit Zugangsdaten. API-Keys und Verbindungen gehören in den Credential- oder Verbindungsbereich des jeweiligen Tools, nicht in Notizen oder Klartextfelder. Sobald personenbezogene Daten verarbeitet werden, sollten nur die nötigen Felder übertragen werden, nicht jede Formulareingabe pauschal. Das ist kein Zusatzthema, sondern Teil eines guten Prozessdesigns.
Ein kleines Fallbeispiel zeigt den Unterschied: Eine Solo-Beratung erhält Anfragen über Website und Terminbuchung. Vor der Automatisierung lagen Kontaktdaten im Postfach, Gesprächsnotizen in Notion und To-dos auf Zuruf. Nach dem Umbau landen neue Eingänge strukturiert als Kontakt plus Anfrage in Notion, kritische Fälle bekommen sofort eine Aufgabe, und unvollständige Anfragen laufen in einen Prüfstatus. Das Ergebnis ist kein „automatisierter Vertrieb“, sondern ein sauberer erster Prozess ohne Copy-Paste-Chaos.
- Prüfe einmal pro Woche fehlgeschlagene Zap-Runs und wiederkehrende Ursachen.
- Reduziere Notion-Felder, die nie gefüllt oder nie ausgewertet werden.
- Halte Statuswerte kurz und eindeutig, damit Filter und Views stabil bleiben.
- Trenne Intake, Qualifizierung und Nachfassen lieber in mehrere kleine Abläufe.
- Dokumentiere in einem Satz pro Zap: Trigger, Ziel und Fehlerreaktion.
Kann Notion ein echtes CRM ersetzen?
Für einfachen Intake, Angebotsvorstufen und Nachfass-Prozesse oft ja. Für komplexe Vertriebsorganisation, ausgefeilte Reporting-Anforderungen oder tiefe Rollenrechte ist ein spezialisiertes CRM meist passender.
Warum sollte der Zap erst suchen und dann erstellen?
Weil genau dort die meisten Dubletten entstehen. Eine Search Action vor dem Create-Schritt hält Stammdaten sauber und sorgt dafür, dass neue Anfragen einem bestehenden Kontakt zugeordnet werden können.
Ist ein Webhook besser als ein normaler App-Trigger?
Das hängt vom Eingangssystem ab. Wenn das Formular oder Tool Webhooks sauber unterstützt, kommen Daten meist direkter an; wenn nicht, ist Polling über einen Standard-Trigger oft völlig ausreichend und für Einsteiger wartbarer.
Wann sollte aus Notion auf Airtable oder ein CRM gewechselt werden?
Dann, wenn Beziehungen, Auswertungen oder Prozessregeln spürbar komplizierter werden. Ein Wechsel ist meist sinnvoller, bevor viele Sonderfälle in Formeln, Views und Hilfsfeldern versteckt werden.
Ein guter CRM-Intake mit Zapier und Notion ersetzt kein Vertriebsmodell, aber er schafft einen sauberen Anfang. Entscheidend sind nicht möglichst viele Automationen, sondern eine klare Datenstruktur, ein Suchschritt vor dem Schreiben und sichtbare Fehlerpfade. Wenn Kontakt, Anfrage und Aufgabe getrennt modelliert sind, bleibt der Ablauf auch bei mehr Volumen verständlich. Genau dann spart die Automatisierung nicht abstrakt Zeit, sondern ganz konkret die manuelle Übergabe zwischen Eingang, Übersicht und nächstem Schritt.
