Automation Routines eCommerce Teams Actually Use Daily

Table of Contents

1. Using email parser bots to track supplier delays automatically

Back in January, one of the suppliers for our t-shirt store decided to start sending tracking numbers in alternating formats — sometimes bare, sometimes inside PDFs, sometimes inside quotes. The sales rep couldn’t even tell me if they had changed systems. The Zap that used to extract tracking numbers from their order confirmations just… stopped. No error, no run. It just saw the email, shrugged, and moved on.

Eventually I switched from Zapier’s built-in parser to Mailparser on Zapier, and created three conditional routes based on regex matching. One caught raw numbers in the email body, one ran OCR on PDFs, and one picked up quoted strings with a dash pattern. Not great for long-term maintainability but the dropship team was back in business.

Undocumented edge case: If the parser hits a PDF where the sender used a font without selectable layers, the OCR step just passes empty strings—and Zapier gives a false success. It looks like everything worked. Nothing does.

Aha moment: Setting a Slack alert when the parsed field is under 10 characters gave a quick way to notice when something failed silently.

2. Quickbooks automation for sales syncing broke on customer type mismatch

Someone on the finance team manually created a customer in QuickBooks with a slightly different name from what came in through Shopify — so when our Make scenario tried to post an invoice, it silently created a duplicate customer, then posted to the wrong account group. This wasn’t caught until we saw two totally separate P&L entries for the same brand purchase.

Turned out QuickBooks doesn’t enforce customer entity matching unless you use the internal customer ID. Most automation tools match by name, which is wild considering how unreliable Shopify customer names are (”Jon Smith”, “Jon_Smith”, “Jon Smith-1”). I ended up injecting a temporary ID link into Shopify order notes via delayed automation just so it could sync later.

Practical tip: Never trust display names across systems. Either attach your own persistent customer key at point of sale or enrich from a verified CRM record.

The whole issue never threw an error. QuickBooks accepted the invoice. Finance saw the sale. Wrong account. Wrong margin. All technically fine.

3. SMS marketing workflows that keep misfiring on timezones

We set up a Flow on Postscript to fire SMS at 9am local time based on customer time zones. It mostly worked until daylight saving hit. Customers in Arizona showed up at the wrong time. Someone in EST got theirs an hour early. Our team blamed Twilio, but it was actually a cached timezone lookup from Shopify’s customer object — which doesn’t update timezone on re-visits. Once populated, it’s static.

How we fixed it: We stopped relying on the Shopify timezone field and instead pulled IPs from Klaviyo events (yes this is sketchy) and passed them to a Node.js function hosted on Fly.io that uses the IP Geolocation API. More accurate, still not perfect (thanks VPN users).

Do not schedule SMS sends based on sign-up IP location
Recalculate timezones on recent interaction, not creation
Delay a campaign by a random 2–7 minute jitter to reduce carrier spam flags
Never assume the timezone returned is the one a person cares about
Log fire time against actual delivery timestamps — and compare weekly

Platform flaw: Most SMS platforms don’t expose sending queue times clearly unless you hit up support. When we got flagged for burst volume, Postscript support confirmed we were sending 4x more than visually shown due to retry logic.

4. Shipping label generator API fails silently on malformed SKUs

Twice now, our shipping label batch runner (ShipStation’s API via n8n) has skipped certain orders entirely because the SKU field had non-breaking spaces or smart quotes. They came from a Google Sheet that someone had copied-and-pasted from Outlook. No errors thrown. Just a quiet 422 that the workflow didn’t catch.

I added a sanitizer node that now replaces those unicode nightmares with dashes, but the bigger fix was a regex matcher that looks for characters outside the printable ASCII block and sets off a Slack warning anytime it finds one in SKU or product label fields.

Behavioral bug: If you resubmit the same order with a cleaned SKU, ShipStation will sometimes double-print the label because it caches submission metadata per timestamp, not per order number.

The thing I didn’t expect? When this failure happened, the fulfillment lead printed the labels manually from Shopify and didn’t tell anyone. Two weeks later, I was wading through webhook logs wondering where the ghost orders came from.

5. ChatGPT product description rewrites require length guards and sentiment failsafes

I had a webhook into OpenAI’s API that took plain product data and spit out short product blurbs for our BFCM landing pages. Initially, I didn’t constrain length because “gpt-4 knows better now.” That was optimistic.

“Embrace the mystical power of ancient artisanship in your wardrobe with this transcendently wearable patterned delight.”

We sell socks. No.

Prompting worked only after I made three structural changes:

Set max_tokens based on character count guard (anything over 1000 chars got clamped with max_tokens: 200)
Inject a hidden content filter chain via post-processing in Make (soft checks for excessive adjectives, banned mood language)
Used temperature 0.3 and top_p 0.85 to reduce dreaminess
Scraped Amazon listing blurb character counts to calibrate target length maps

Edge case I hit: Products with empty fields (e.g. missing material type) would trigger weird hallucinations like “woven gold silk” or “carbon-steel knitted mesh” — so I now pre-fill blanks with “material not listed” to make it obvious when descriptions are going rogue.

6. Inventory notifications misfired due to double-firing webhooks in Airtable

I wired up a low-inventory notifier using Airtable Automation triggers. The idea was: when stock drops below 10, notify the SKU manager. Simple. Except Airtable sometimes fired the webhook twice when a row update triggered two fields via linked record sync. The automation ran twice, two Notify events went out, and suddenly people were ordering unneeded restocks.

Real moment: SKU manager messaged me asking why she got 86 Slack DMs in 3 hours during the warehouse audit. Most were duplicate restock calls.

Fix that actually worked: I added a checkbox field called Notified Already and updated that field as part of the automation success chain. Then filtered the automation to only trigger when Notified Already was empty. Not bulletproof but good enough.

Bug detail: If your automation update modifies the same field that triggers the automation, Airtable sometimes reattempts the automation again within 5 seconds, even if everything inside ran fine. There’s no version control on this behavior — it just happens.

7. Customer support tools need different triage logic for escalations

We had HelpScout hooked into Zapier to detect tickets flagged with certain phrases like “chargeback”, “unauthorized”, “cancel my order”, etc. The automation tagged and escalated those to a specific inbox. Then it broke for three days because someone in CX changed the tag names — from “Urgent” to “Priority-level-one”.

Zaps don’t fail loud on missing tag names. They just skip. No ticket escalation happens. Unless you check the Zap history, you won’t notice that no routing took place.

Eventually we ripped it out and wired the triage logic externally. We used the HelpScout API directly inside Make so we can query tag IDs at runtime instead of assuming static tag names.

Tips from that rewrite:

Log exact tag ID mappings weekly into a private Slack thread
Run a sanity-check count of escalations per day to catch drop-offs
Never rely on platform-configurable tag names in routing logic
Watch for edited replies — some auto-escalate only on first message

Aha quote buried in a ticket log: “I already spoke with Jenn — she said this would be escalated.” That’s how we realized we weren’t routing correctly anymore.

8. Pricing sync flows fail quietly when Google Sheets columns move

Our product pricing updates start in a shared Google Sheet, then sync to BigCommerce via Make. Occasionally someone from merchandising sorts the sheet or moves columns around. If that happens, the mapping breaks — but the sheet still passes valid rows. So the automation doesn’t error. It just posts $0 prices to BigCommerce. That gets noticed fast… but not always before email blasts go out.

Undocumented issue: The Google Sheets module in Make binds to columns by letter (A, B, C), not by header name. If headers move but columns stay alphabetically static, your data gets misattributed — without warning.

So I switched to reading the cell range manually via Sheets API and then reconstructing a row map using header matching. Slightly more overhead, but now we get a Slack ping if a required header is missing.

Real fix lesson: Always bake in upper and lower price guards. I now clamp anything under one dollar or over two thousand to auto-fail the run, even if the other data looks clean.