Zapier-Experte: behalten, was Zapier gut kann, und umziehen, was ihm entwachsen ist

Zapiers eigentlicher Vorteil ist nicht die Funktionsliste. Eine nicht-technische Person kann einen Zap bauen, ihn ein halbes Jahr später verstehen und ohne Hilfe reparieren. Dazu kommt der Katalog: Nach den veröffentlichten Zahlen der Anbieter hat Zapier mehr Integrationen als Make oder n8n, sodass eine Nischen-App dort eher eine native Anbindung hat. Prüfen Sie trotzdem, ob die konkrete Aktion verfügbar ist, die Sie brauchen, nicht nur die App.

Die Grenze liegt im selben Modell. Ein Zap geht davon aus, dass ein Auslöser ein Element erzeugt, das geradlinig durch die Schritte läuft. Paths ergänzen Verzweigungen, Looping by Zapier verarbeitet Listen, aber beides sitzt auf diesem Modell auf. Muss ein Prozess eine Sammlung durchlaufen, Ergebnisse wieder zusammenführen oder nach mehreren Bedingungen gleichzeitig verzweigen, lässt sich Zapier meist dazu bringen. Das Ergebnis ist dann teuer und schwer nachzuvollziehen.

Auf Zapier bleiben sollten deshalb in der Regel:

• einfache, lineare Zaps, die von der Person gepflegt werden, die sie braucht
• alles, was an einer App hängt, die nur Zapier anbindet
• Automationen mit geringem Volumen und geringem Risiko, bei denen die ganze Rechnung klein ist
• Zaps in Teams, in denen niemand ein mächtigeres Werkzeug betreuen würde

Laut Zapier-Dokumentation zählt ein Task jedes Mal, wenn ein Aktionsschritt erfolgreich ausgeführt wird. Auslöser zählen nicht, ebenso wenig gefilterte oder fehlgeschlagene Schritte. Die Kosten wachsen deshalb mit Schritten mal Datensätzen: Zwei zusätzliche Schritte in einem Zap, der zehntausendmal im Monat läuft, sind eine Entscheidung über zwanzigtausend Tasks, getroffen in einer Minute.

Ein Kosten-Audit beginnt deshalb im Task-Verlauf: Zaps nach verbrauchten Tasks sortieren. Oft machen wenige Zaps den Großteil aus, prüfen Sie das aber an Ihren eigenen Daten. Ist die Verteilung flach, lohnt sich kein Umzug, sondern Aufräumen:

• Filter so früh wie möglich. Ein Zap, der bei Schritt zwei stoppt, verbraucht keine Tasks für die Schritte danach; die Reihenfolge ist also auch eine Kostenfrage.
• Auslöser auf das eine Feld, das wirklich zählt, statt auf jede Änderung am Datensatz.
• Keine Suchschritte, die bereits erledigte Arbeit wiederholen.

Wer nach einer Zapier-Alternative sucht, hat oft eine Rechnung, die ihm nicht gefällt, und keine Plattform, der er entwachsen ist. Entscheiden Sie pro Automation, nicht pro Konto. Viele Teams landen bei zwei Plattformen, und das ist eine vernünftige Aufteilung.

Der Unterschied zeigt sich bei Listen. Laufen hundert Datensätze gemeinsam durch einen Workflow, ist das bei n8n Cloud eine Ausführung, bei Abrechnung pro Schritt dagegen bis zu hundert Einheiten für jeden Schritt. Bei Make kommt hinzu, dass laut Make-Dokumentation auch eine geplante Prüfung auf neue Daten Credits verbraucht, während Zapier für Polling keine Tasks berechnet.

• Zaps, die lesbar bleiben. Ein Zap erledigt eine Aufgabe und ist so benannt, dass die Liste sagt, wofür er da ist. Formatter übernimmt Datums- und Textformate, damit niemand einen Code-Schritt pflegen muss, den er nicht lesen kann.
• Paths, solange die Verzweigung flach ist. Für eine Handvoll sich ausschließender Bedingungen sind Paths gut. Wird daraus eine Matrix oder müssen zwei Zweige wieder zu einem Ergebnis zusammenlaufen, gehört die Automation auf eine Plattform mit Router und Aggregator, und das sagen wir dann auch.
• Zapier als Anschluss, nicht als Logik. Hat eine App nur bei Zapier eine Integration, fängt der Zap den Auslöser ab und reicht die Daten direkt an einen Webhook weiter. Die eigentliche Arbeit läuft dort, wo Logik, Fehlerbehandlung und Ausführungsverlauf liegen, und der Zap bleibt bei ein bis zwei Tasks pro Datensatz.
• Ausfälle sichtbar machen. Nach wiederholten Fehlern pausiert Zapier einen Zap und benachrichtigt den Eigentümer, oft ein persönliches Konto, dessen Postfach niemand mehr liest. Wir verlegen die Zaps in ein gemeinsames Konto, leiten Fehlermeldungen in einen Kanal, den das Team beobachtet, und prüfen die zurückgehaltenen Tasks, in denen fehlende Datensätze oft liegen.
• Polling-Verzögerung erklären statt neu bauen. Polling-Auslöser prüfen in einem vom Plan abhängigen Intervall, deshalb kann ein funktionierender Zap minutenlang wie ausgefallen wirken. Wo die Quell-App einen Sofort-Auslöser oder Webhook anbietet, stellen wir um; sonst benennen wir die Verzögerung offen.

Zapier kann Zap-Definitionen auf den Team- und Enterprise-Plänen als JSON exportieren. Diese Datei ist aber für Sicherungen und andere Zapier-Konten gedacht; Make importiert sie nicht. Ein Umzug ist deshalb ein Neubau und wird als solcher geplant:

1. 01Bestand aufnehmen: jeder Zap mit Eigentümer, Auslöser, Apps, Verbindung, Task-Verbrauch und letztem Lauf. Abgeschaltete, defekte oder überholte Zaps werden gelöscht, nicht migriert.
2. 02Sortieren in bleiben, umziehen und stilllegen. Der Maßstab ist nicht, ob sich ein Zap nachbauen lässt, sondern ob der Nachbau besser ist.
3. 03Sichern, was Zapier hält: Zap-Verlauf, zurückgehaltene und fehlerhafte Läufe, Inhalte aus Zapiers Speicher und Tabellen. Nichts davon kommt automatisch zu Make.
4. 04Die teuersten und am stärksten verzweigten Zaps zuerst neu bauen, mit Schreibzugriffen auf eine Testumgebung oder im reinen Protokollmodus.
5. 05Parallel laufen lassen: Das Szenario empfängt echte Ereignisse und protokolliert, was es getan hätte, während nur der Zap schreibt. Wenn die Ergebnisse übereinstimmen, wird zu einem festgehaltenen Zeitpunkt umgeschaltet, und der alte Zap bleibt pausiert, nicht gelöscht.

Günstiger wird es dabei nicht automatisch. Ein linearer Zap, eins zu eins übertragen, kann auf Make mehr Einheiten verbrauchen, weil dort auch der Auslöser zählt. Einsparungen entstehen meist erst, wenn Schleifen umgebaut und Ergebnisse vor dem Schreiben zusammengefasst werden. Wir schätzen das anhand Ihres Ausführungsverlaufs, bevor wir einen Umzug empfehlen.