I used to run a small dropshipping store, and one thing I never fully solved was tracking which suppliers were reliable vs. which ones quietly caused most of my delays and refunds. I mostly just remembered, or dug through old orders when something went wrong.
I’ve been thinking about building a small tool for exactly this a simple way to see, over time, which suppliers are costing people the most in delays/refunds, instead of relying on memory or digging through old orders.
Before I go further is this something you guys currently struggle with, or does everyone already have a system for it (spreadsheet, app, something else)? Genuinely trying to figure out if this is worth building or if I’m solving a problem that doesn’t really exist.
The problem is real but I think it sits somewhere different from where you are aiming, and that changes whether it is worth building.
The data collection part is already done for you. Every line item on an order carries a vendor field, and Shopify documents it as the name of the item’s supplier. Line items also carry fulfillment_service and origin_location. So you are not solving a capture problem. Anyone with API access can pull supplier per line today, which is also why a spreadsheet feels almost good enough to most people.
Three things break when you actually try to turn that into reliable versus unreliable.
Vendor is a free text field somebody typed. I was reading another merchant’s catalogue in this forum yesterday and their vendor list had Soeji 37 times and soeji 6 times, one brand sitting as two rows. Your per-supplier table will silently split like that, and the table still looks correct, which is the worst version of wrong. Whatever you build needs a normalisation and merge step before the first chart, not after users complain.
Attribution on mixed orders is the harder one. Delays and refunds attach to the order. Vendor attaches to the line item. An order with three lines from two suppliers ships late, and now who caused it. A partial refund on one line, does the whole order count against that supplier. This is a blame assignment problem, not a reporting problem, and it is where tools like this quietly become useless. Merchants will not trust a number they can find a counterexample to in five minutes.
Then a test I would run before writing any code. Pull one old order through the API and note line_item.vendor. Change the vendor on that product. Refetch the same old order. If the historical order now reports the new vendor, the field is a live reference, and every supplier switch rewrites your entire history, which for dropshipping is constant. If it holds the old value you have a real snapshot and a foundation. The docs do not spell this out, so measuring beats assuming, and the answer decides whether the product is viable at all.
When you were running your store, were the bad suppliers slow across everything, or slow on specific SKUs? Those need different tools, and the second one is much less crowded.
Really appreciate this — especially the vendor-field test, that’s exactly the kind of thing I’d have found out the hard way. I don’t have API access yet (haven’t set up the dev store), but that’s my very next step, and I’ll run that test before writing anything further.
On your question — from my own store, it was more the second pattern: certain suppliers were fine overall but consistently slow on specific SKUs, not everything they sold. That’s actually useful to sit with, because it means a single “supplier score” might be the wrong shape for what actually happened to me.
The SKU-level point is interesting because it means a supplier can look “reliable” overall while still repeatedly causing problems on a handful of products.
When that happened in your store, what consequence hurt most — customer refunds, late-delivery complaints, emergency supplier switching, or simply the time spent figuring out where the problem came from?
I’m especially curious whether you would have acted differently if you had seen “Supplier A is normal overall, but these 6 SKUs are causing most delays.”
Honestly, the delays themselves were the core issue and what actually hurt most was the scramble that came after trying to find an alternate supplier fast enough to still fulfill the order before the customer got fed up or asked for a refund. That’s time and stress I didn’t see coming, way more than any single refund cost me directly.
To your question yes, I think I’d have acted differently. If I’d been able to see “Supplier A is fine overall, but these specific SKUs keep causing delays,” I could’ve quietly lined up a backup supplier for those products ahead of time, instead of finding out mid-order and scrambling under pressure. That’s really the gap not knowing which specific products were the risk until it was already too late.
That answer changes what the tool has to be. If the damage is the scramble, the useful output is not a ranking you read at the end of the month, it is something that fires while you can still act.
Two things follow from that.
The clock you care about is per line, not per order. Shopify gives you order created_at, and each fulfillment carries its own created_at plus the line items that went out in it. One order can produce several fulfillments days apart. Measure order to last fulfillment and the slow SKU disappears inside a fast order. Measure order to first fulfillment and you get the opposite distortion. Per line item is the only version that matches what you just described.
The bigger trap is that fulfilled lines are the only ones with an end timestamp. Any duration you compute is computed on lines that already came good. The order sitting at day nine with nothing fulfilled has no duration at all, so it falls out of the table, and that is exactly the order you were scrambling on. Open lines have to be aged against now and treated as their own list, otherwise your report gets calmer the worse things get.
One more thing before you size the table. On a small store most SKUs have one or two orders behind them, so a per SKU ranking is mostly noise at the top. Set a minimum order count before a SKU is allowed to appear, and roll everything under it back up to the vendor.
What kind of lateness were yours? Two days over, or two weeks? That decides whether this can be a daily digest or has to watch orders as they age.
For me personally, it was usually just a couple of days over, not weeks so on my own small volume, a daily digest probably would’ve been enough to catch it in time.
But thinking about this more broadly for the tool itself: at higher order volume (which is where this would actually need to work, not just my old small store), a couple of days of unnoticed delay across dozens or hundreds of orders a day adds up fast by the time a daily digest surfaces it, you could already have several orders past the point of easy recovery. So even though my lateness was mild, I think the real answer might be: the delay tolerance should probably be closer to real-time the higher the order volume gets, not fixed at “a couple of days is fine.” Does that match what you’d expect too, or is daily still enough even at scale?
Hi there @hira.qureshi
To be sure, this can really start to strain for small stores once the order volume ramps up. A straightforward method is to work directly with Shopify order information and add supplier information, fulfilment times, refunds, and cancellations. After a while, you will be able to look at those figures for each supplier and recognize problems without using your memory. Even a simple supplier performance view with average fulfillment time, refund rate and delayed orders would be nice. The trick would be to make the data capture sufficiently automatic, so that merchants do not have to run yet another manual system.
I think there’s definitely a problem there, especially once you have enough orders that you stop remembering which supplier caused what. A supplier can look fine most of the time and still be responsible for a disproportionate number of late deliveries or refunds, but you’d never really notice that from looking at individual orders.
I used to keep a spreadsheet for things like this, but the annoying part was actually keeping it updated. By the time I had a reason to look at it, I usually had to go back through a bunch of orders to figure out what had happened.
I’d probably want the tool to show the supplier alongside actual outcomes rather than just a basic reliability score. Average delivery time is useful, but I’d also want to see refund rate, late orders, maybe the products that are causing the most trouble. I like that same approach with SEO tools too, where the useful part isn’t having more data but being able to see where the problems are concentrated. SiteGuru does that pretty well on the site side.
If you can make the supplier data happen automatically from Shopify orders, I’d definitely see the appeal. The manual tracking is probably the part that makes most people give up on it.
Really appreciate everyone weighing in on this a few of you have independently landed on the same shape (automatic Shopify data pull, per-supplier fulfillment/refund/delay stats, no manual entry) which is a strong signal on its own. Still trying to nail down one thing: would this be worth paying a small monthly fee for, or does it only make sense as a free add-on to something you already use?