The 3-eMail Problem
Why do NZ eCommerce customers get bombarded with redundant dispatch emails? The 3-eMail Problem signals deeper integration and system design issues—and here’s how smart SMEs can fix it.
TL;DR: If your customers are getting three emails for every dispatch, you're not being helpful—you're signalling architectural trouble.
---
1. The Problem
Most Kiwis can relate to the "3-eMail Problem". You've spent time online, painstakingly researching the Widget purchase. After validating the e-commerce vendor's authenticity, you continue with the order. You review the extra freight costs, curse, but move forward anyway and pay for the fastest delivery option. The Widget is definitely a need, not a want. You push the button.
Woosh—the money leaves your account very quickly. Technology is fantastic like that. You wonder why, if technology is so fantastic, it can't woosh the money after the item has been delivered. But you don't dwell on this thought. It is definitely a need.
From this point, however, things slow down, and the excitement recedes.
But all is not lost! Look! A new email from the vendor! You open it, and as expected, it confirms your order. Everything looks OK. It even has a picture of the Widget. How very exciting. You check the details. Good, all is in order (no pun). Okay, noted—there will be another email when the order is dispatched. Good to know. It would be better to know when they (accurately) expect that to happen. Never mind, I'm sure it will happen soon.
Wind forward a couple of days. You've been refreshing your email every hour, looking for the dispatch notice. Doubt creeps in. Maybe you should have taken the four-hour round trip to get it from the competitor. Wait! Do not despair. An email has arrived. You rip it open digitally. Yes! It has been dispatched. There is even a tracking number. This is progress! You note for the record that you never lost faith.
But this isn't your first rodeo. You reread the email and recognise the weasel words. Sigh. Someone has picked, packed, and slapped a courier label on the package—and it's now sitting in the vendor's warehouse. You contemplate whether this is a dark pattern. Then you shake it off; it seems common these days.
The next day: nothing. You must have missed the courier cut-off. That premium freight fee isn't looking so premium now. If technology is so great, why didn't the website hide that shipping option when it was already too late?
Then—finally! After many caffeinations—it arrives! The ACTUAL REAL dispatch email from the vendor. It. Is. On. The. Move. Hooray!
Wait, hang on. Another ACTUAL REAL dispatch email from the courier. They've picked it up—it's on the move. Hooray (more)!
Oh, what now? Another dispatch email, this time from something called Shipping Integration. It too says the parcel is on its way.
That was… a bit much.
You also note that, in all three emails, while there is a tracking number and link, clicking the link takes you to a courier website—where you still need to cut and paste the tracking number. Welcome to the 2010s.
And so it continues. For each step in the courier's journey—including final delivery—you receive at least three, sometimes more, emails telling you the same thing from different parts of the vendor's tech stack and service providers. As an added bonus, you often get push notifications, too. One cannot complain about being under-informed!
This is the 3-eMail Problem. It seems harmless, but it's the canary in the coal mine—signalling deeper business and technology issues.
---
2. Why It Happens
2.1 Common Setup
Many NZ SMEs run on a patchwork of SaaS tools. An eCommerce site might use an online storefront for sales, cloud accounting for finances, and a shipping integration to manage fulfilment. Each system handles part of the customer journey—and each insists on speaking.
2.2 Warning Signs
Customer confusion is usually the first signal. "Which email is real?" or "Why did I get this three times?" are early symptoms. So are broken tracking links and rising unsubscribe rates after fulfilment.
Internally, signs mount. Staff copy data between apps "just in case." Manual updates are sent because "the systems don't talk." Teams coordinate via email when handoffs should be automated. Every workaround reflects a broken or missing integration.
Technical debt builds quietly. APIs labelled "temporary" never get revisited. Webhooks fail silently. CSV imports become the backbone of inter-system sync. What began as a quick fix becomes a permanent liability.
Customers sense the mess. They call to double-check info. Different departments give different answers. Communication feels disjointed—as if it came from three companies, not one. These are not UX issues; they are architectural faults surfacing.
---
3. How to Fix It
3.1 Start with an Email Audit
The 3-eMail Problem signals poor system orchestration. Fix it by first getting visibility into your notification chaos.
Track all customer emails for one week—every system, every trigger. Map them to business events (order placed, dispatched, delivered). You'll quickly spot the redundancy patterns.
💡 Tip: Anonymise personal details from your email logs, then feed them to ChatGPT or Claude with this prompt:
"Categorise these customer notifications by underlying business process, and map any examples of TIMWOOD waste types."
This identifies redundant flows and timing mismatches far faster than manual sorting.
3.2 Identify the Waste
Group emails by customer journey stage—order confirmation, dispatch, delivery. Assess each group for duplication, timing issues, or conflicting content.
Here's how TIMWOOD waste surfaces in the 3-eMail Problem:
| Waste Type | Example |
|---|---|
| Overproduction | Three emails for one dispatch event |
| Waiting | "Dispatched" email sent before pickup occurs |
| Over-processing | Two systems send updates the other already covered |
| Inventory | Emails stuck pending manual action |
| Motion | Customers copy/paste tracking numbers due to broken links |
| Defects | Conflicting order statuses or inaccurate information |
| Transport | Unnecessary handoffs between systems for basic updates |
Each item reflects customer frustration and internal inefficiency. Quantifying them turns complaints into evidence for change.
3.3 Quick Wins: Stop the Bleeding
Designate One Communication Owner
Pick your most customer-facing system (usually your eCommerce platform) as the sole sender of customer notifications. Turn off customer emails in your shipping integration and courier systems—they can still update internally.
Fix the Timing
Stop sending "dispatched" emails when you print labels. Configure systems to trigger notifications only when the courier actually collects the package. Most platforms have webhook delays or conditional triggers for this.
Consolidate Updates
Instead of three separate "on the way" emails, send one comprehensive update with all tracking details, delivery estimates, and support contacts. Your customers want information, not inbox spam.
3.4 Tactical Integration (Growth Stage)
Event Filtering
Set up middleware (Zapier, n8n, or custom webhooks) that captures status updates from all systems but only sends customer notifications from one source. Let systems talk to each other without spamming your customers.
Status Aggregation
Build a simple status dashboard that pulls from all your systems and presents one truth to customers. When Shipping Integration says "collected" and NZ Post says "in transit," your dashboard shows "on the way—tracking ABC123."
API-First Mindset
Configure systems to publish events (order.shipped, package.delivered) rather than notifications. This separates what happened from how you tell customers about it.
3.5 Scale Solution: Event-Driven Architecture
Single Source of Truth
Implement proper event sourcing where each business event has one authoritative publisher. Your eCommerce platform publishes order.created, your fulfilment system publishes order.shipped—no overlap.
Notification Service
Build or buy a dedicated customer communication layer that subscribes to business events and manages all outbound messaging. This becomes your notification gateway—one place to control timing, content, and channels.
System Boundaries
Stop letting every vendor email your customers. Systems should excel at their core function and publish clean events as their output. Customer communication becomes a separate, controlled capability.
3.6 Implementation Maturity Path
Stage 1: Coordination (Immediate)
- Turn off notifications in 2 of 3 systems
- Manually coordinate timing between remaining systems
- Fix broken tracking links
Stage 2: Integration (3–6 months)
- Deploy low-code middleware for event filtering
- Implement status aggregation dashboard
- Automate notification timing
Stage 3: Architecture (6–12 months)
- Event-driven system design
- Dedicated notification service
- Proper system boundaries
The goal isn't enterprise complexity—it's customer clarity. Start with coordination, graduate to integration, scale to architecture. Each stage reduces support load while improving customer experience.
---
Further Reading
Lean Waste Types (TIMWOOD)
TIMWOOD is a well-known acronym from lean manufacturing used to classify seven types of operational waste: Transportation, Inventory, Motion, Waiting, Overproduction, Over-processing, and Defects. Understanding these categories can help SMEs diagnose inefficiencies not just on the shop floor, but also in digital operations like email notifications.
→ Wikipedia – Muda (Japanese term)
---
Written by Mike Carr, Principal at Four Four Solutions – helping NZ SMEs simplify tech stacks and streamline operations.