"Every day it was the same support emails: 'Where is my order?' 'I want a refund.' 'Is this still in stock?' I was spending 2-3 hours per day on emails that had answers already sitting in my store's database. The tracking number was right there. The refund policy was right there. But a human still had to look it up, copy it, and paste it into a reply. Every single time."
That's Ethan Rogers, describing why he built an AI support tool after running his own online stores, in a post on Indie Hackers (source). His tool ended up covering refunds and stock questions too, but the tracking number line is the cleanest part of that quote, because it names the actual failure mode: the answer already exists in the store's database. A person just has to go find it, copy it, and paste it into a reply, one ticket at a time.
That's the pattern this post is about. Not "customers are impatient." Not "shipping is slow." The data already exists the moment a label gets created. The only question is whether it reaches the customer automatically or waits for someone to notice a support ticket and go look it up.
Why manual tracking handling stops working
At low order volume, copying a tracking number from the courier's dashboard into an email takes thirty seconds. Nobody builds a system for thirty seconds of work. The problem is that this cost doesn't stay flat, it multiplies with every order, and it multiplies again with every day the label sits between "created" and "customer notified."
Two things tend to happen as volume grows. First, the lag between label creation and customer notification stretches, because whoever's doing it by hand is also doing five other things. Second, and this is the part that actually generates tickets, the customer isn't told anything is happening at all until that manual step gets around to them. From the customer's side, an order that's been paid for and gone quiet looks identical to an order that's been lost. They don't know the label was printed an hour ago and the courier just hasn't scanned it yet. All they know is: nothing.
That's the detail worth sitting with. It's rarely the delay itself that generates a "where is my order" ticket. Plenty of customers will wait a week without complaint if they know the package is moving. What generates the ticket is silence. No confirmation the order shipped, no update when it changes hands between courier and last-mile carrier, no signal at all until either the package shows up or the customer gets anxious enough to ask. WISMO tickets are, in a real sense, the most avoidable category of support volume that exists, because the underlying question ("is my order actually coming") almost always has a knowable answer sitting in a system somewhere. The work isn't answering the question. It's routing the answer to the customer before they have to ask it.
What a solution could look like
There's a spectrum here, and it's worth being honest about what each point on it actually solves.
The first is manual copy-paste, what most small stores start with. Someone opens the courier portal, copies the tracking number, pastes it into an email or a spreadsheet, maybe updates the order in the store platform. It works at low volume. It breaks down exactly where growth makes it matter most, and it has zero proactive component: nothing goes to the customer until someone remembers to send it.
Next up is the native platform shipping email. Shopify and most platforms will fire a shipping confirmation automatically once a fulfillment is marked complete, which solves the "did anyone notify the customer" problem. What it usually doesn't solve: the email is generic, often unbranded or thinly branded, sent once at fulfillment and then silent for the rest of transit, and gives no milestone updates if the package sits at a hub for two days. It's a floor, not a system.
Then there are dedicated post-purchase tracking apps: tools like AfterShip, ShippyPro, and Malomo, which sit on top of the store and the courier APIs to give a branded tracking page and, in most tiers, proactive milestone emails or SMS ("shipped," "out for delivery," "delivered"). This is a real improvement over the native email: it's proactive rather than reactive, and it's usually the fastest path to reducing WISMO volume without writing custom code. The tradeoff is that you're renting the logic. Milestone definitions, notification timing, and what counts as "delayed" are whatever the app's defaults say, and customizing beyond that usually means a pricing tier jump or working within someone else's rules engine.
Last is a fully custom automated capture-and-notify system, built to match how a specific brand actually operates: which milestones matter for this product category, what tone the notifications use, what happens differently for a high-value order versus a standard one, how it talks to the support inbox when something looks stuck. More work to build than installing an app. The payoff is that the logic is exactly the brand's logic, not a vendor's default.
None of these fixes a slow carrier. That's true of every option on this list, including the one I'd build, and it's worth saying plainly before going further.
The solution I'd build
Here's how I'd think about building this for a D2C brand doing enough volume that manual handling has started to hurt.
The trigger is the label itself, not the fulfillment record and not a nightly batch job. The moment a shipping label gets created, whether that's through the store platform's fulfillment API or directly through a carrier or shipping tool, that event should fire a webhook immediately. Waiting for a batch job to run means the fastest possible notification is still hours behind reality, which defeats a chunk of the point.
That webhook captures the tracking number and carrier, writes it back to the order record, and triggers the first customer notification: order shipped, courier, tracking link, expected window if the carrier API provides one. This part isn't complicated. It's the same lookup-and-populate logic as the AI support triage pipeline I've written about elsewhere, minus the AI: grab the field, don't make a human type it.
The part that actually moves the WISMO number is what happens after that first email. A tracking number sitting in an order record doesn't help anyone unless something is watching it. This is where I'd have the system poll the carrier's tracking API (or subscribe to their webhook, where one exists) at a sane interval, and fire a notification at specific milestones rather than every status change: picked up, in transit through a major hub, out for delivery, delivered. Every status change is too much noise, customers don't need to know the package changed sort facilities. Milestones are the ones that actually answer "is this still moving."
The other piece worth building deliberately: a stall detector. If a tracking number hasn't updated in, say, 48 to 72 hours past the expected window, that's exactly the profile of an order that's about to generate a support ticket, and it's detectable before the customer notices. Two options at that point: notify the customer proactively ("your package appears to be delayed in transit, here's what we're doing") or flag it to a human on the support side before the ticket lands, so if the customer does write in, the reply isn't a coworker scrambling on the platform's tracking page for the first time. Either way, the goal is the same one that started this post: don't leave the customer with silence.
Pros and cons, honestly
The upside is real: fewer WISMO tickets, less manual courier-portal lookups, a support inbox that isn't absorbing a category of ticket that never needed a human. But it's worth being specific about what this doesn't fix, because a system like this gets oversold constantly.
It depends entirely on carrier data being accurate, and carriers are not always reliable narrators of their own packages. A scan that didn't happen, a status that's stale by a day, a "delivered" flag that fires before the package actually arrives: all of these happen, and when they do, the automated notification is wrong, which is arguably worse than no notification, because now the brand told the customer something false. Any build like this needs to treat carrier data as probably-right, not definitely-right, and design the stall detector and any "delivered" messaging with that skepticism built in.
It doesn't fix a genuinely slow or unreliable carrier. If transit times are bad, this system tells the customer about the bad transit time faster and more clearly, it doesn't make the package move quicker. For some brands, the honest fix here is a carrier conversation, not automation.
And it can't eliminate WISMO tickets caused by carrier-side failures: lost packages, missed scans, packages stuck in customs, misroutes. A customer whose package is genuinely lost is still going to write in, and should. What this system changes is the denominator: fewer tickets from orders that were actually fine and just looked silent, so the tickets that remain are more often the ones that need a person's judgment anyway.
How it gets implemented
The technical shape, without the sales language, starts with a webhook fired the moment a label is created, whether that comes from the store platform's fulfillment event or the shipping/carrier tool used to generate labels. That event carries the tracking number, carrier, and service level, which gets written straight to the order record with no manual entry anywhere in the path. The first customer notification, branded and immediate, fires off that same capture event rather than a separate scheduled job, so there's no gap between the label existing and the customer actually knowing about it.
From there, ongoing tracking runs via carrier API polling or a webhook subscription where the carrier supports one, since not all carriers expose the same level of real-time data. Rather than notifying on every raw status change, the system checks against a defined milestone list and fires only at meaningful transit points, picked up, in transit, out for delivery, delivered, to avoid notification fatigue. A stall detector sits alongside that: a threshold check comparing time-since-last-update against the expected transit window, flagging anything that's gone quiet for review or proactive customer contact before the customer notices and writes in.
Every notification and every stall flag gets logged against the order, so if a ticket does come in anyway, whoever answers it can see exactly what the customer was already told instead of starting from zero. None of this requires the order volume to be enormous to be worth building. It requires the volume to be high enough that the manual version is visibly costing someone time, which for most D2C brands happens well before it feels urgent.
The cost of the pain, and the cited improvement
The clearest number I've found on this comes from ShippyPro's 2026 analysis of reducing WISMO tickets in ecommerce: up to 65% fewer "where is my order" support tickets once proactive tracking notifications are in place.
Worth being precise about what that number is and isn't. It's a vendor's own analysis, not a neutral third-party study, so the incentive to report a strong number is obvious. It's an "up to" figure, meaning a ceiling under favorable conditions, not a typical or guaranteed result. And the case documented in that analysis is food and beverage specifically.
I'd argue the underlying mechanism generalizes past that one vertical, because the logic doesn't depend on what's in the box: a customer who already has a tracking link and a status update doesn't have a reason to ask where their order is, regardless of whether it's a skincare set or a snack subscription. But that's reasoning from mechanism, not a second documented case, and I want to keep that distinction clear rather than imply it's been tested across categories when the source material doesn't say that.
What I can say without hedging is the mechanism itself: the ticket gets prevented by removing the reason it gets asked, not by answering it faster once it lands. That's the same principle threaded through the whole build above, from the first webhook trigger to the stall detector at the end. Silence generates tickets. Information, sent before anyone has to ask for it, doesn't.