Eine Marke für selbstgeführte Audiotouren braucht einen Gutscheincode pro Reisendem, nicht pro Buchung. Eine Familie mit sechs Tickets braucht sechs Codes, in einer E-Mail, bei einem Verkauf, der nie erstattet werden kann. Eine Teillieferung ist schlimmer als gar keine.
Wir haben das Fulfilment als zwei Make.com-Szenarien gebaut, getrennt an der Nahtstelle: Eines kennt den Vertriebskanal, das andere weiß nichts darüber, woher eine Bestellung kommt. Sie treffen sich auf einer Nutzlast aus sieben Feldern. Der Checkout löst den Webhook aus, Airtable hält das Code-Inventar, Postmark verschickt die Mail. Es reserviert exakt N Codes, liest sie zurück, um sicherzugehen, dass es sie bekommen hat, und sendet gar nichts, wenn der Bestand nicht reicht.
Diese Trennung hat sich mitten im Projekt bezahlt gemacht: Der Kunde hat seinen Channel-Manager abgeschafft und ist auf Stripe gewechselt. Nur das Eingangsszenario wurde neu geschrieben. Der Fulfilment-Kern wurde nie wieder geöffnet, und die Änderung war noch am selben Abend live.
In drei Tagen gebaut und übergeben, zum Festpreis.
Verifiziert mit einem echten Kauf über das Live-Konto, Ende zu Ende. Bestandsmangel, doppelte Webhooks und eine 20-Ticket-Bestellung gegen eine befüllte Sandbox getestet.
Kundenbewertung auf Upwork (Original, englisch)
“Jonathan is a top-tier automation engineer and systems architect. Midway through our integration, our distribution strategy required a complete pivot from Bókun to Stripe. Jonathan adapted the entire architecture seamlessly—absorbing the channel shift with minimal changes to core logic, ensuring that the pipeline fails safe rather than risking broken voucher deliveries, and making language expansion entirely plug-and-play without touching the automation. His communication was exceptionally clear, rapid, and proactive from start to finish. Highly recommended for any complex automation work.”