Implementing inventory software: the go-live checklist

Three weeks after installing inventory software, a dog-gear store held its first meeting about the app. The reorder suggestions looked wrong: it wanted 90 units of a harness that sells about two a day, and nothing for the leash that sells six. The tool was fine. The implementation wasn't — 47 of 312 variants had no cost entered, one supplier's lead time was a guess from a text thread, and nobody had counted the stockroom before go-live. The app was faithfully calculating from wrong inputs.

That's the whole lesson of inventory software implementation: the tool inherits whatever you hand it. Most failed setups aren't software problems, they're data problems that showed up on day one and were never traced back. The sequence below — clean the inputs, decide what the app may write, count before you trust, verify one suggestion by hand — takes two to three weeks on a catalog of a few hundred SKUs, and it ends with a tool you can actually believe.

Clean the four inputs before you install

Everything an inventory app does is arithmetic on four inputs: what you sell (SKUs), what it cost you (costs), where it sits (locations), and how long replenishment takes (lead times). Clean all four in Shopify before the first import, not after — an app that imports a dirty catalog will faithfully reproduce the dirt.

SKUs. One SKU per sellable variant, no blanks, no duplicates, no "same product, two listings" leftovers. Duplicates are the worst offender: if a leash exists twice in the catalog with the stock split between them, no tool can produce a correct reorder point for either listing.

Costs. Every variant needs a cost, and the cost should be landed where you know the freight and duty split. This is the input merchants skip most, and the one that quietly corrupts everything downstream.

Consider the harness from the opening story. Trail Harness, medium — HAR-TR-M — retails at $42.00. The importer's invoice says $19.60 per unit. But the last shipment's freight and duty added $2.80 per unit, so the true landed cost is $22.40. With invoice cost only, the margin looks like (42.00 − 19.60) ÷ 42.00 = 53.3%. With landed cost, it's (42.00 − 22.40) ÷ 42.00 = 46.7%. A 6.6-point miss on the store's bestseller, repeated across every harness variant, misranks which products deserve the next dollar of buying. Enter the best cost you have before go-live; refine as real receipts land.

Locations. Name them the way you physically count them — "Warehouse aisle 2", "Front of store", "Consigno at Pawfect Pets" — because the count cadence in week one runs location by location.

Lead times. Per supplier, measured rather than remembered. If you've been ordering on the calendar method ("I usually order when the shelf looks light"), spend an hour reconstructing the last three orders per supplier: order date to dock date. That measured number becomes the manual lead time you enter per supplier — the reorder calendar hangs off it. If the reconstruction turns up more variance than you expected, the lead-time measurement guide shows how to formalize it.

Install day: decide what the app may write

The permission screen deserves more than a click-through. Every scope an app requests is a contract: read scopes let it see your data, write scopes let it change your store. A reporting tool that only reads can't damage anything — the worst case is a wrong number on a screen. A tool that writes inventory, orders, or purchase orders can move quantities and create documents, so it needs an owner and a rollback habit from day one.

Before approving, open the app's listing and read the "Data access" panel — every listing spells out exactly what it views and edits. Match the access to the job: a purchasing suite will legitimately ask to edit inventory and purchase orders; an analytics layer that wants write access to orders deserves a question. In the admin, the app's page under Settings → Apps and sales channels shows the same picture after install, and uninstalling revokes it.

Data transfer is the other decision. Some tools import a CSV you export from Shopify; some read your store directly. InventoryX, for one, offers a free Stocky CSV import covering catalog and inventory data only — no orders, no PO history — because V1 is designed to read Shopify rather than replace it. Whatever the path, spot-check 20 random variants after import: cost, quantity, and location on each. Twenty checks catch most import mapping errors before they become two hundred.

Week one: count before you trust any suggestion

The app's opening picture of your stock is only as good as Shopify's numbers on install day, and Shopify's numbers drift — that's not an accusation, it's retail. Shrinkage, mis-receipts, and POS sync gaps accumulate between counts.

So the first week of any inventory software implementation is a count week, and it's deliberately partial. Count your fastest movers — the A-list, roughly the 20% of SKUs that carry most of your sales. On a 500-SKU store that's about 100 SKUs, one or two staff-days, and it covers the SKUs where a wrong number does the most damage first. Run the count at close of day, apply it before trading resumes, and correct the source in Shopify, not just in the app. The full cycle-count workflow — scoping, scanning, applying without corrupting live sales — is in the Shopify counts guide.

A full stock take can wait for its annual slot; the point of count week is that every reorder suggestion the app produces in month one is built on counted stock, not inherited stock.

Weeks two and three: lead times, then the first verified reorder

With stock counted, enter lead times per supplier — manually, as plain date ranges. Most small-store tools don't learn lead times from PO history, and V1-era Shopify apps generally don't either; treat the lead time as a number you own and revisit quarterly.

Then run the app's weekly buying view and take one suggestion apart by hand. This is the step that converts trust from hope to arithmetic. A real example from the dog-gear store, week three:

The merino hiking two-pack, SOC-MRN-2P, sells 4.7 pairs per day on days it was in stock — the app excludes the six recent days when it was sold out from that average, which is the correction that matters, because a zero-sales day from an empty shelf is not zero demand. On hand: 41 pairs. Days of cover: 41 ÷ 4.7 ≈ 9 days. Lead time to the sock mill, measured over the last three receipts: 14 days. Cover is shorter than lead time, so the order is already late — order today, not next Monday. Suggested quantity: (14-day lead + 7-day review buffer) × 4.7 ≈ 99 pairs, minus 41 on hand ≈ 58, rounded up to five dozen to respect the pack size.

If your own arithmetic lands within a pack size of the app's suggestion, the implementation is honest. If it doesn't, the gap tells you exactly which input is wrong — usually cost, lead time, or an uncounted SKU — and that's a better discovery in week three than month six.

From there, the cadence carries itself: one buying session a week, same day, same 30 minutes. The weekly checklist is a printable page for that session if the routine needs scaffolding.

The exit test: how you know it's implemented

An implementation is done when three questions take ten minutes to answer:

1. What's low this week? Not "what feels low" — a list, rank-ordered, with days of cover per SKU.
2. What's already incoming? Open POs and in-transit stock, so you don't double-order what's on the water.
3. What did running dry actually cost last month? Days dark per SKU and estimated lost revenue, labeled as the estimate it is.

If the tool plus Shopify answers all three, the software is implemented. If any answer still lives in someone's head, that's the remaining work — and it's usually the third one, because native Shopify reports don't compute lost sales from out-of-stock days as of October 2026, which is precisely the gap a leak-style report fills.

If you're migrating, not starting fresh

Everything above assumes a standing catalog in Shopify. If the catalog is currently trapped in another tool, get your data out first and treat the export as the migration's source of truth — leaving Stocky specifically has its own export guide, since what survives that shutdown export is narrower than most refugees expect. A 3PL cutover is a different project again, with its own go-live week; the 3PL onboarding timeline covers that sequence separately.

Common questions

How long does inventory software implementation take? Budget two to three weeks to first value on a catalog of 100–1,000 SKUs: two to four days cleaning SKUs, costs, locations, and lead times; one week of counting your fastest movers; then the first verified reorder in week two or three. Larger catalogs scale the cleanup and count, not the sequence.

Should I clean my data in Shopify or in the new app? In Shopify, before the import. The app inherits whatever Shopify holds, so fixing SKUs, costs, and locations after import means maintaining two versions of the truth. Fix the source, import once, then spot-check 20 random variants against the original list.

What data do I need ready before installing? Four inputs: one clean SKU per sellable variant, a cost on every variant (landed where you know it), locations named the way you count them, and a measured lead time per supplier. Everything the app computes — margins, reorder points, order-by dates — is arithmetic on these four.

Do I have to count everything at go-live? No. Count your fastest movers first — roughly the 20% of SKUs driving most sales — because wrong numbers there do the most damage. Schedule a full stock take annually and cycle counts in between. Counting the whole store on day one usually delays the project without improving the first month's decisions.

What if the app's numbers disagree with Shopify? Treat Shopify as the source of truth for quantities and investigate the gap: usually a scope limitation, a sync delay, or stock that drifted before the count. Run a spot count on that SKU the same day. A disagreement that persists across SKUs is an implementation issue to fix now, not a quirk to live with.

Next step

Run the four-input audit today: export your product CSV and count the rows with a blank cost field, a blank SKU, or a supplier whose lead time you can't state from memory. That count — not the app comparison you already did — is your real implementation timeline. Then read the cycle-count guide and put count week on the calendar before the app is even installed.