Replacing 24+ fragile Zapier automations with one LLM-driven pipeline.
Alderbrook Home Goods' multi-partner Amazon Vendor Central operation was held together by 24+ separate Zapier automations. We rebuilt the whole pipeline on AWS Lambda with an LLM handling classification and exception routing.
Client
Alderbrook Home Goods
Partners synced
Wayfair, Walmart, Target, Faire, CommerceHub
Role
AI Engineer & Solution Architect
Alderbrook Home Goods was running 24+ separate Zapier automations just to keep compliance data, orders, and catalog information in sync across retail partners — Wayfair, Walmart, Target, Faire, CommerceHub, and direct SFTP feeds. Each automation was its own point of failure, and no one had a single place to see what needed attention when something broke.
The pipeline pulls compliance, order, and catalog data directly through Amazon's SP-API and normalizes it from five different partner data shapes — Wayfair, Walmart, Target, Faire, and CommerceHub each structure this data differently — into one consistent model before anything downstream touches it.
An LLM sits in the decisioning layer, classifying records and routing anything genuinely ambiguous to a person instead of letting it fail silently the way the old Zapier chain did. Clean, resolved data syncs out to two destinations built for two different audiences: Airtable for day-to-day operational visibility, and BigQuery for reporting and trend analysis.
- 0124+ fragile automations rebuilt as a single Lambda-based pipeline
- 02LLM decisioning layer for classification, extraction, and exception routing
- 03Direct data pulls through Amazon SP-API
- 04Dual sync to Airtable (day-to-day visibility) and BigQuery (reporting and trend analysis)
AWS Lambda + Amazon SP-API + LLM Decisioning Layer + Airtable + BigQuery + Multi-Partner Data Sync + Exception Routing
Built on AWS Lambda with an LLM in the decisioning layer, Airtable, and BigQuery.
How we built it
Audit the opportunity
We mapped all 24+ existing automations, their data sources, and where they were failing or silently dropping exceptions.
Design the operating model
We designed a single pipeline architecture with an LLM sitting in the decisioning layer for classification and exception handling.
Ship fast, validate early
We migrated the pipeline off Zapier and Google Apps Script onto AWS Lambda, pulling compliance, order, and catalog data directly through Amazon's SP-API.
Launch with confidence
We put the system into production across multiple retail partners with dual sync to Airtable and BigQuery for visibility and reporting.
What actually got in the way
Reconciling five different data shapes into one model
Wayfair, Walmart, Target, Faire, CommerceHub, and direct SFTP feeds each structure compliance and order data differently. The pipeline needed a normalization layer before the LLM decisioning step could reason over any of it consistently.
Migrating without a sync gap
Cutting over from 24+ live Zapier automations to a single Lambda pipeline had to happen without a window where data silently stopped flowing — the business was running on this sync in real time, not in a staging environment.
Calibrating the decisioning layer toward recall, not confidence
An exception that gets auto-approved silently is far more expensive than one flagged for a person to check. The logic had to be deliberately tuned so ambiguous cases route to review by default, rather than optimizing for confidence scores that simply looked clean.
4h → 30m
Processing time per sync cycle
0
Manual corrections needed — runs error-free
24+
Fragile automations replaced by one pipeline
The pipeline now runs in production across multiple retail partners, replacing a patchwork of no-code automations with a system the team can actually debug and extend. Processing time per sync cycle dropped from roughly 4 hours to about 30 minutes, and it now runs error-free with no manual correction needed — ambiguous cases get routed for review instead of failing silently.
The highest-value target isn't the slowest process — it's the one that fails silently. None of the 24+ automations was individually the biggest time sink; the real cost was that no one had a single place to see what needed attention when something broke. Read more
Consolidation beats another patch. Every additional automation would have added one more independent point of failure to a system that already had too many — a single observable pipeline was cheaper to extend and debug than another node bolted on.
Dual sync exists because different teams need different things from the same data — Airtable for whoever has to act on an exception today, BigQuery for whoever is analyzing trends next quarter.
Have a similar product idea?
Share the workflow, product idea, or knowledge problem you're solving, and we'll help define the smartest first build.