We Automated Our Entire Order Fulfillment: Here's What Happened

The Problem: 45 Minutes Every Morning, 7 Days a Week

I run an e-commerce company called Industrial 4 Less. We sell industrial storage equipment -- bin shelving, wire racks, storage cabinets, that kind of thing. It's a dropship operation: customers order from our Shopify store or our Amazon listings, and our supplier ships directly to them.

Every night, our supplier sends confirmation emails with PDF attachments. Each PDF has a PO number, tracking number, carrier info, and the items shipped. Every morning, someone had to open each email, find those details, match them to the correct Shopify order, click "fulfill," paste in the tracking number, then do the same thing on Amazon for multi-channel orders.

Fifteen to twenty orders a night. Two to three minutes each on a good day. Forty-five minutes before the actual workday even started.

That doesn't sound terrible in isolation. But do it every single morning -- weekends, holidays, doesn't matter -- and it becomes the most soul-crushing part of the job. Not because it's hard. Because it's the exact same thing every time. Open email. Download PDF. Find PO number. Find tracking number. Open Shopify. Search order. Click fulfill. Paste tracking. Next.

And the errors. Oh, the errors. Wrong tracking number pasted into the wrong order. An Amazon shipment confirmation missed because you got distracted mid-process. An order fulfilled twice because you lost track of where you were. Each mistake means a customer service ticket, a confused customer, and 15 more minutes fixing something that shouldn't have broken.

This went on for months. I kept thinking, "This is the kind of thing a computer should be doing."

So I built one.

What We Built

Phase 1: Email Extraction

The system connects to our Outlook inbox using Microsoft's Graph API. Every night, it scans for new PO confirmation emails from our supplier. When it finds them, it downloads the attached PDFs.

Then it reads each PDF. Not just "opens the file" -- actually reads the content, understands the layout, and extracts the specific data points we need: PO number, tracking number, carrier, items shipped, quantities.

This was harder than it sounds. PDFs aren't structured data. They're basically pictures of text arranged on a page. The supplier's PDF format has tables, headers, footer text, and a bunch of information we don't need mixed in with the stuff we do. Getting reliable extraction meant understanding the document layout and building logic specific to their format.

Phase 2: Order Matching

Once the system has the PO data, it needs to figure out which Shopify order each PO belongs to. Our PO numbers map to Shopify order names, but it's not always a one-to-one match. Some orders have multiple shipments. Some PO numbers reference the Shopify order in a slightly different format.

The system also cross-references Amazon order IDs for orders that came through our Amazon channel. A single customer purchase might exist as a Shopify order AND an Amazon order that need to be updated simultaneously.

The output of this phase is a fulfillment queue: a clean list of "this tracking number goes to this order on these platforms."

Phase 3: Automated Fulfillment

This is where it actually does the work.

For Shopify orders, the system uses the Shopify Admin GraphQL API. It creates a fulfillment record with the tracking number and carrier, which triggers Shopify's built-in customer notification emails. The customer gets their tracking info without us doing anything.

For Amazon orders, it submits a shipping confirmation feed through the SP-API. Amazon's feed system is asynchronous -- you submit the data and wait for Amazon to process it -- so the system handles that polling automatically.

Both platforms update simultaneously. No more fulfilling on Shopify and forgetting Amazon.

Phase 4: Reporting

When the run finishes, the system sends a summary email. Here's what was fulfilled. Here's what needs manual attention. Here's any errors that came up.

It also updates a master tracker spreadsheet automatically. Every order, every tracking number, every date -- logged without anyone typing a thing.

Instead of spending 45 minutes doing the work, I spend 2 minutes scanning the summary email. Most mornings, it's just a confirmation that everything went through.

The Results (With Real Numbers)

I'm going to give you actual numbers because I think the vagueness of most case studies is insulting. "Saved significant time." "Dramatically reduced errors." Come on.

The first successful run processed ~50 orders. Most were fulfilled automatically. A handful were flagged for manual review (unusual formats the system hadn't seen before). One was a known exception we'd already accounted for.

At $100/hour for owner time -- which is conservative for the opportunity cost of not working on growth -- that's $27,300 per year in recovered time. The system took about three weeks to build.

If we'd hired someone to build this as a client engagement, it would fall into our Tier 2 pricing: $7,000 to $15,000. Even at the high end, the payback period is under seven months. At the low end, it's under three.

What Went Wrong Along the Way

I'd be lying if I said it worked perfectly from day one. Building automation against real-world data is messy. Here's what tripped us up.

PDF parsing was fragile. The supplier's PDF format looked consistent until it wasn't. They changed the layout slightly for certain order types. Multi-page POs had different spacing. One time, they updated their template entirely, and the parser broke on every single email that night. We had to build the extraction logic to be more flexible and handle format variations, not just the "standard" layout.

Amazon's feed API has a delay. When you submit a shipping confirmation to Amazon, it doesn't confirm instantly. There's a processing window. Early versions of the system would submit the feed and assume success. We had to build in status checking to verify Amazon actually accepted the confirmation. Sometimes feeds fail silently -- the submission goes through but individual orders within the feed get rejected for various reasons.

Split shipments. Not every order ships as one package. Large orders might ship in two or three boxes on different days. The system had to learn to handle partial fulfillment -- mark the first shipment, hold the order open for the rest, and close it when everything has shipped.

The lesson: budget time for edge cases. The "happy path" -- standard order, single shipment, clean PDF -- took about a week to build. The edge cases took another two weeks. That ratio is pretty typical for any automation project. The common cases are easy. The exceptions are where the work lives.

What We'd Do Differently

If I were building this from scratch today, three things would change.

Start with just Shopify. We tried to get Shopify and Amazon working simultaneously from the start. That doubled the debugging surface. I'd build Shopify fulfillment first, validate it for a week, then add Amazon as a second phase. Faster to get a win, easier to isolate issues.

Build error reporting from day one. The first week, I was manually checking whether the system worked each morning. Did the orders actually fulfill? Did Amazon get the tracking? I was basically doing a mini version of the original manual process just to verify the automation. Once I built proper error reporting and summary emails, that verification dropped to two minutes.

Document the supplier's email format immediately. I reverse-engineered the PDF format by looking at examples. It would have been faster to sit down on day one, open ten different PO confirmations, and catalog every variation: single shipment, multi-shipment, multi-page, different carriers, different item types. That upfront documentation would have prevented three of the four issues I hit during testing.

Why We're Telling You This

We build these exact systems for other businesses. That's what AdVise Omni is -- we take operational workflows that eat hours of manual time every day and automate them end to end.

But this isn't a demo we built for a conference talk. This isn't a theoretical example from a whitepaper. This system runs every single night. It has processed thousands of orders since we turned it on. When it has a problem, we fix it the next morning because we use it ourselves.

That's the difference between a company that sells automation and a company that lives on it. We don't theorize about what might work. We know what works because we've been running it in production on our own revenue for months.

If your business has a version of this -- a manual process that eats time every day, follows the same steps every time, and involves moving data between systems -- it's probably automatable. The question isn't whether it's possible. It's whether you want to spend another six months doing it by hand.