Make-Preisstufen

Makes Preismodell basiert auf Operationen, jede Modulausführung in einem Szenario zählt als eine Operation. Wenn du die Preisstufen verstehst, vermeidest du böse Überraschungen bei der Rechnung, sobald deine Automatisierungen wachsen. Der Free-Plan gibt dir 1.000 Operationen/Monat über 2 aktive Szenarien. Das reicht zum Lernen und Testen, aber nicht für einen echten Business-Workflow. Der Core-Plan ($9/Monat) gibt dir 10.000 Operationen/Monat, 3 aktive Szenarien und ein Mindestintervall von 15 Minuten. Das deckt die meisten Automatisierungsbedürfnisse eines frühen SaaS-Unternehmens ab, etwa eine Onboarding-Sequenz für neue Nutzer plus einen Wochenbericht.

Der Pro-Plan ($16/Monat) schaltet 10.000 Operationen, unbegrenzt aktive Szenarien und ein Mindestintervall von 1 Minute frei, entscheidend für nahezu Echtzeit-Verarbeitung von Webhooks. Der Teams-Plan ($29/Monat) ergänzt Team-Zusammenarbeit und mehrere Nutzer, die Szenarien verwalten. Der Business-Plan ($59/Monat) deckt 150.000 Operationen/Monat ab, passend für SaaS mit hohem Volumen und Hunderten von Webhook-Ereignissen pro Tag.

Praktische Operationen-Budgetierung: Eine 5-Modul-Onboarding-Sequenz, ausgelöst durch 100 neue Registrierungen/Monat, verbraucht 500 Operationen. Ein Wochenbericht-Szenario mit 4 Modulen läuft mit 16 Operationen/Woche. Ein Stripe-Webhook-Handler mit 8 Modulen, der 200 Ereignisse/Monat verarbeitet, verbraucht 1.600 Operationen. Die meisten frühen SaaS-Unternehmen kommen 6 bis 12 Monate lang mit dem Core-Plan aus. Plane den Pro-Plan ein, sobald du Echtzeit-Webhook-Verarbeitung hinzufügst.

Fehlerresistente Workflows aufbauen

Unbehandelte Fehler in Make-Szenarien führen dazu, dass das Szenario stoppt und deine Daten in einem inkonsistenten Zustand zurücklässt. Produktionsreife Make-Workflows brauchen bei jedem externen API-Aufruf eine bewusste Fehlerbehandlung. Mit Makes Fehlerbehandlungs-Routen legst du fest, was passiert, wenn ein Modul fehlschlägt: Resume (das fehlgeschlagene Element überspringen und weitermachen), Ignore (den Fehler protokollieren und weitermachen), Rollback (alle abgeschlossenen Module der Ausführung rückgängig machen), Break (die Ausführung stoppen und die unvollständige Ausführung für einen manuellen erneuten Versuch speichern) oder Commit (die Ausführung trotz des Fehlers als abgeschlossen markieren).

Bei webhook-ausgelösten Szenarien (Stripe, Supabase, eingehende Daten) solltest du externe API-Aufrufe immer in Fehlerbehandler mit der Einstellung Break einbetten. Das speichert die fehlgeschlagene Ausführung in Makes Warteschlange für unvollständige Ausführungen, wo du die Payload prüfen, das Problem beheben und den Vorgang manuell erneut ausführen kannst. Ohne Break-Handler verschwinden fehlgeschlagene Ausführungen und du verlierst die auslösenden Daten dauerhaft.

Bei geplanten Szenarien (Berichte, Stapelverarbeitung) verwendest du besser Ignore oder Resume zusammen mit einer Fehlerbenachrichtigung. Wenn ein Wochenbericht eine Datenquelle nicht abrufen kann, willst du meist trotzdem, dass der Rest des Berichts läuft, und erhältst einen Hinweis auf den teilweisen Fehler, statt gar nichts zu bekommen. Füge auf der Fehlerroute immer eine Slack-Benachrichtigung oder einen E-Mail-Alarm hinzu, stille Fehler sind die gefährlichsten Fehler in produktiver Automatisierung.

Make mit Webhooks und Supabase nutzen

Supabases Datenbank-Webhooks ermöglichen es dir, ein Make-Szenario bei INSERT-, UPDATE- oder DELETE-Ereignissen auf jeder Tabelle auszulösen. Konfiguration: Gehe in Supabase zu Database → Webhooks, erstelle einen neuen Webhook, der auf die Webhook-URL deines Make-Szenarios zeigt (generiert in Make, wenn du ein Custom-Webhook-Trigger-Modul hinzufügst). Wähle die Tabelle und den Ereignistyp aus (Insert für neue Nutzerregistrierung, Update für Statusänderungen). Supabase sendet die geänderten Zeilendaten als Webhook-Payload.

Für einen Trigger bei neuer Nutzerregistrierung: Supabase feuert, wenn eine Zeile in deine profiles-Tabelle eingefügt wird (erstellt durch deinen Auth-Trigger). Make erhält die ID des Nutzers, die E-Mail-Adresse und alle Metadaten, die du bei der Registrierung speicherst. Das Szenario kann die Daten dann anreichern (Clearbit-Abfrage), einen CRM-Kontakt erstellen (HubSpot, Pipedrive), eine Willkommens-E-Mail senden (SendGrid) und in einem Slack-Kanal posten, alles innerhalb von 2 bis 3 Sekunden nach der Registrierung.

Wichtig: Supabase-Webhooks haben ein Timeout von 5 Sekunden. Wenn dein Make-Szenario länger als 5 Sekunden braucht, um auf den Webhook zu antworten, markiert Supabase ihn als fehlgeschlagen und wiederholt den Versuch möglicherweise. Bei lang laufenden Workflows sollte Make den Webhook sofort bestätigen (mit HTTP 200 antworten) und die restlichen Operationen asynchron einreihen. Das erreichst du in Make, indem du in zwei Szenarien aufteilst: ein Empfänger-Szenario, das sofort antwortet und die Daten an einen Make-Datenspeicher sendet, und ein Verarbeitungs-Szenario, das aus dem Datenspeicher liest und die aufwendige Logik ausführt.

Flow 1: Onboarding-Sequenz für neue Nutzer

Auslöser: Neue Zeile in Supabase users-Tabelle. Aktionen: (1) Willkommens-E-Mail über SendGrid senden, (2) Kontakt in HubSpot erstellen, (3) In #new-users Slack-Kanal posten, (4) Tag-3-Follow-up-E-Mail planen, (5) Zu Airtable Neu-Nutzer-Tracking-Basis hinzufügen.

Dieser Flow läuft automatisch für jede neue Registrierung, kein manueller Aufwand, keine verpassten Willkommens-E-Mails. Für deutsche SaaS-Unternehmen kannst du die Willkommens-E-Mail auf Deutsch anpassen und DSGVO-Datenschutzinformationen gemäß eurer Datenschutzerklärung hinzufügen.

Flow 2: Stripe-Abonnement-Ereignisse

Auslöser: Stripe Webhook (subscription.created, subscription.updated, subscription.deleted). Aktionen: (1) Nutzerplan in Supabase aktualisieren (Rolle: free/starter/pro/enterprise), (2) Plan-Bestätigungs-E-Mail über SendGrid senden, (3) HubSpot-Deal-Status aktualisieren, (4) Bei Upgrades in #revenue Slack-Kanal posten.

Das stellt sicher, dass deine App immer den aktuellen Abonnementstatus kennt, auch wenn der Nutzer sein Abonnement über das Stripe-Kundenportal verwaltet. Wichtig für korrekte Rechnungshandhabung, die deutschen Buchführungsanforderungen erfüllt.

Flow 3: Churn-Risiko-Warnung

Auslöser: Supabase geplanter Webhook, läuft jeden Montag um 9:00 Uhr. Aktionen: Nutzer abfragen, die sich weniger als einmal in den letzten 14 Tagen eingeloggt haben UND zahlend sind. Liste an Slack #cs-team-Kanal mit Nutzername, Plan und letztem Login-Datum senden.

Das gibt deinem Customer-Success-Team eine wöchentliche Liste mit gefährdeten Konten, bevor sie kündigen. Im deutschen Markt, wo SaaS-Anbieter wie Personio und Celonis hohe Ansprüche an Customer Success gesetzt haben, kann ein proaktiver Anruf einen großen Unterschied für die Retention machen.

Flow 4: B2B-Lead-Qualifizierung

Auslöser: Neue Formulareinreichung (Typeform, Webflow-Formular oder WeWeb-Formular über Webhook). Aktionen: (1) Unternehmensdata über Clearbit anreichern, (2) Lead basierend auf Unternehmensgröße, Branche und Job-Titel bewerten, (3) Hochpunktige Leads an Pipedrive mit einer Aufgabe für AE weiterleiten, (4) Mittelpunktige Leads in eine Drip-E-Mail-Sequenz einleiten, (5) Niedrigpunktige Leads eine Self-Serve-E-Mail senden.

Für den deutschen Markt: Bewerte Unternehmen aus Berlin, Hamburg oder München mit 50+ Mitarbeitern und einem CTO oder Geschäftsführer als Kontakt mit maximalen Punkten.

Flow 5: Rechnungs- und Vertragsgenerierung

Auslöser: Neue Zeile in Supabase projects-Tabelle (Status = "bestätigt"). Aktionen: (1) PDF-Rechnung über PDFMonkey aus einer Supabase-Projektvorlage generieren, (2) Per SendGrid mit Zahlungslink an Kunden senden, (3) Projektordner in Google Drive erstellen, (4) In #projects Slack-Kanal posten.

Manuelle Rechnungserstellung vollständig eliminieren. Die Rechnung kann korrekte Umsatzsteuer-Referenz und alle relevanten deutschen B2B-Rechnungspflichtangaben (Steuernummer, Rechnungsnummer, Leistungsdatum) enthalten, Standard für deutsche B2B-Transaktionen.

Flow 6: Support-Ticket-Routing

Auslöser: Neue Intercom-Konversation oder Support-E-Mail. Aktionen: (1) Dringlichkeit mit OpenAI klassifizieren (Kritisch / Hoch / Normal / Niedrig), (2) Bei Kritisch: On-Call über PagerDuty alarmieren, (3) Bei Hoch: dem Senior-Support zuweisen und Slack benachrichtigen, (4) Alle Tickets im Airtable-Support-Tracker mit Kategorie und Lösungszeit protokollieren.

Flow 7: Wöchentlicher Umsatzbericht

Auslöser: Jeden Montag um 8:00 Uhr. Aktionen: (1) Stripe nach MRR, neuen Abonnements, Kündigungen und Expansionsumsatz der letzten 7 Tage abfragen, (2) Supabase nach neuen Registrierungen, DAU und Feature-Nutzung abfragen, (3) Als strukturierten Bericht formatieren, (4) Im #leadership Slack-Kanal posten und per E-Mail an die Gründer senden.

Deine KPIs landen jeden Montag ohne manuelles Zusammentragen in deinem Posteingang.

Flows 8-10: Weitere hochwertige Szenarien

Flow 8, NPS-Umfrage-Automatisierung: 30 Tage nach Registrierung ausgelöst, NPS-Umfrage über Delighted senden, Detraktoren sofort an Customer Success weiterleiten.

Flow 9, Trial-Konvertierungssequenz: Ausgelöst, wenn der Trial ausläuft. Tag 0: Upgrade-Aufforderungs-E-Mail. Tag 3: Case-Study-E-Mail. Tag 7: persönliche E-Mail vom Gründer. Tag 14: Kündigungsbestätigung mit Rückgewinnungsangebot.

Flow 10, Datensicherung: jede Nacht um 2:00 Uhr Supabase-Tabellen in verschlüsselte CSV-Dateien in Google Drive exportieren. Einfach, aber kritisch, SaaS-Unternehmen, die das vernachlässigen, bereuen es früher oder später. Das ist außerdem hilfreich für DSGVO-Dokumentation und Prüfungsnachweise.

Gängige SaaS-Automatisierungsmuster

Über die 10 oben beschriebenen Workflows hinaus gibt es vier architektonische Muster, die in fast jedem SaaS-Automatisierungsprojekt wiederkehren. Das ereignisgesteuerte Muster: Jede wichtige Nutzeraktion in deiner App löst einen Supabase-Webhook aus, der ein Make-Szenario auslöst, das die nachgelagerten Effekte übernimmt (CRM-Update, Benachrichtigung, Analytics-Ereignis). Das ist das Rückgrat moderner SaaS-Abläufe, deine App bleibt schlank und jedes operative Anliegen ist in einem eigenen Szenario isoliert.

Das Muster der geplanten Aggregation: Tägliche oder wöchentliche Make-Szenarien fragen deine Datenbank ab, aggregieren Kennzahlen und verteilen Berichte. Das ist einfacher und günstiger, als eine Reporting-Infrastruktur in deiner App zu bauen, und es hält operative Erkenntnisse in Tools, die dein Team ohnehin schon nutzt (Slack, E-Mail, Google Sheets).

Das Anreicherungsmuster: Sobald ein neuer Kontakt oder ein neues Unternehmen in deinem System auftaucht (Registrierung, Lead-Formular, Support-Ticket), reichert ein Make-Szenario ihn mit Drittanbieterdaten an (Clearbit, Hunter.io, LinkedIn), bevor er dein CRM erreicht. Vertriebsteams, die vorangereicherte Leads erhalten, schließen 20 bis 30 % mehr Deals ab, weil sie ihre Zeit mit Verkaufen statt mit Recherche verbringen.

Das Eskalationsmuster: Make überwacht Schwellenwertüberschreitungen (fehlgeschlagene Zahlungen, Support-Reaktionszeit, Fehlerratenspitzen) und eskaliert mit Kontext an das passende Teammitglied. Das in deiner App selbst zu bauen, erfordert eine eigene Monitoring-Infrastruktur. In Make dauert es einen Nachmittag und kostet Cent-Beträge pro Ausführung.