Was Make.com wirklich kostet
Die Preisliste ist schnell gelesen. Sie beantwortet nur nicht die Frage, die zählt: Was verbraucht unser Szenario im Monat? Drei Kostentreiber, eine Rechnung und vier Gegenmittel.
Die Preisliste ist schnell gelesen. Sie beantwortet nur nicht die Frage, die zählt: Was verbraucht unser Szenario im Monat?
Der Grund ist die Abrechnungseinheit. Make rechnet nicht nach Szenarien und nicht nach Nutzern, sondern je Bausteinaktion. Die Einheit heißt inzwischen Credit — früher Operation, die Mechanik ist dieselbe. Wer das nicht einrechnet, plant mit dem Tarif und zahlt nach Verbrauch.
Abgerechnet wird je Arbeitsschritt
Nicht das Szenario kostet, sondern jeder Baustein, den es durchläuft. Ein Ablauf mit acht Bausteinen kostet acht Credits je Durchlauf, nicht einen.
Daraus folgt eine unangenehme Rechnung. Ein Szenario, das alle fünf Minuten prüft, ob eine neue Bestellung da ist, läuft rund 8.640-mal im Monat. Bei acht Bausteinen sind das 69.120 Credits — auch dann, wenn in diesem Monat nur 200 Bestellungen eingegangen sind.
Sie zahlen nicht für die Arbeit, die anfällt. Sie zahlen für das Nachsehen, ob Arbeit anfällt.
Die drei Kostentreiber
1. Der Auslöser
Ein Zeitplan, der zu häufig prüft, ist der teuerste Fehler und der am leichtesten zu behebende.
Zwei Gegenmittel, beide einfach
- Webhook statt Zeitplan. Der Shop meldet, wenn etwas passiert, statt dass das Szenario fragt. Aus 8.640 Läufen werden 200 — bei gleichem Ergebnis und geringerer Verzögerung. Welche Ereignisse Shopware dafür liefert, steht in Webhooks in Shopware 6.
- Seltener prüfen. Muss der Bestandsabgleich alle fünf Minuten laufen oder reicht stündlich? Die Antwort ist fast immer „stündlich reicht" — und zwölfmal seltener heißt zwölfmal günstiger.
2. Schleifen
Eine Schleife über eine Liste kostet je Element. Ein Produktabgleich über 2.000 Artikel ist kein Lauf, sondern 2.000 — multipliziert mit den Bausteinen innerhalb der Schleife. Drei Bausteine je Artikel ergeben 6.000 Credits für einen einzigen nächtlichen Abgleich.
Gegenmittel: Nur verarbeiten, was sich geändert hat. Ein Filter vor der Schleife spart mehr als jede Optimierung innerhalb.
3. Wiederholungen
Fehlversuche zählen wie echte Läufe. Ein Zielsystem, das unzuverlässig antwortet, erzeugt Kosten für Arbeit, die nie ankommt.
Eine Rechnung, die vor den Bau gehört
| Größe | Beispiel | Ihre Zahl |
|---|---|---|
| Läufe je Monat (Auslöser × Häufigkeit) | 200 | |
| Bausteine je Lauf | 8 | |
| Elemente je Schleife (Mittelwert) | 0 | |
| erwartete Fehlversuche | 5 % | |
| Credits je Monat | ~1.680 |
Die Beispielspalte ist eine ereignisgesteuerte Bestellübergabe. Dieselbe Aufgabe mit Fünf-Minuten-Zeitplan landet bei rund 69.000 Credits — Faktor 40 für denselben Nutzen.
Vier Entwurfsentscheidungen, die den Verbrauch bestimmen
In dieser Reihenfolge prüfen
- 1Kann der Auslöser ein Ereignis sein? Wenn ja, ist alles Weitere zweitrangig — hier liegt der Faktor 40.
- 2Lässt sich vor der Schleife filtern? Nur geänderte Datensätze verarbeiten statt alle. Ein Zeitstempel im Quellsystem genügt meistens.
- 3Lassen sich Bausteine zusammenfassen? Zwei Abfragen, die dasselbe System betreffen, sind oft eine. Jeder eingesparte Baustein wirkt mit der Zahl der Läufe multipliziert.
- 4Sind die Wiederholungen begrenzt? Drei Versuche mit wachsendem Abstand, danach eine Meldung an einen Menschen — nicht endlos im Stillen.
Was die Rechnung nicht enthält
Den Aufbau. Ein Szenario zu bauen, zu testen und zu dokumentieren kostet Zeit, die in keinem Tarif steht. Bei einfachen Ketten ein halber Tag, bei Bestellübergaben mit Sonderfällen deutlich mehr.
Den Betrieb. Jemand muss ins Protokoll sehen. Ein Szenario, das seit drei Wochen scheitert, verbraucht weiter Credits und liefert nichts.
Den Wechsel. Wenn der Verbrauch über die Zeit wächst, steht irgendwann die Frage nach einem anderen Abrechnungsmodell im Raum. Was dann zu bedenken ist, haben wir in Make.com oder n8n durchgerechnet — dort geht es weniger um den Preis als um die Frage, wer die Ketten betreut.
Wo der Verbrauch versteckt entsteht
Drei Stellen, an denen Credits anfallen, ohne dass es im Ablaufbild sichtbar ist:
Der Filter nach dem Abruf. Wer 500 Datensätze holt und dann 495 wegwirft, hat trotzdem 500 verarbeitet. Die Einschränkung gehört in die Abfrage, nicht in einen nachgelagerten Filter — das ist derselbe Gedanke wie bei jeder Datenbankabfrage.
Der Fehlerpfad. Ein Zweig, der bei jedem Durchlauf mitläuft und nur im Fehlerfall etwas tut, kostet trotzdem. Prüfungen gehören hinter eine Bedingung, nicht davor.
Die Testläufe. Sie zählen wie produktive. Wer ein Szenario mit einer Schleife über 2.000 Artikel dreimal testet, hat 6.000 Credits verbraucht, bevor es überhaupt live war. Zum Testen die Menge begrenzen — das ist kein Detail, sondern bei großen Abgleichen der Unterschied zwischen einem Tarif und dem nächsten.
Monatlicher Blick, der sich lohnt
- Welche drei Szenarien verbrauchen am meisten, und warum?
- Gibt es Läufe, die nichts gefunden haben? Wie viele?
- Wie hoch ist der Anteil der Fehlversuche am Gesamtverbrauch?
- Läuft noch etwas, das niemand mehr braucht?
Der letzte Punkt ist der häufigste Einzelfund. Szenarien werden gebaut, abgelöst und nicht abgeschaltet — sie laufen weiter und verbrauchen weiter.
Die ehrliche Zusammenfassung
Make ist nicht teuer. Es ist falsch benutzt teuer — und der häufigste Fehler ist ein Zeitplan, wo ein Ereignis gereicht hätte.
Wer die vier Fragen oben vor dem Bau beantwortet, landet in aller Regel im kleinsten kostenpflichtigen Tarif und bleibt jahrelang dort. Wer sie überspringt, wechselt nach vier Monaten in den nächsthöheren und sucht dann nach einer Erklärung.
Welche Prozesse sich überhaupt lohnen zu automatisieren, steht in Automatisierung im Mittelstand.
Wenn Sie ein bestehendes Szenario haben und der Verbrauch Sie überrascht: Wir sehen uns die Läufe an und sagen, welcher der drei Treiber bei Ihnen überwiegt. Das ist meistens einer, und er ist meistens der erste. Mehr dazu unter App- und Plugin-Entwicklung.
