Turning the daily spreadsheet job into something that runs itself

What this actually solves

Somebody in your business opens a spreadsheet every morning. They take the supplier's overnight file, look up which of your SKUs it maps to, adjust quantities, change a few prices, check which orders are ready, book the courier, copy tracking numbers back onto the orders, and notice the products that quietly went out of stock. It is not difficult work. It is unrelenting, and it is exactly the kind of work a person does slightly wrong on a Friday afternoon.

The cost is not really the hours, although the hours are the easy part to see. The cost is the errors those hours produce. A quantity typed one digit out becomes an oversell, which becomes a cancellation, which on a marketplace becomes a metric you cannot argue with. A price not carried across from the supplier file becomes a month of selling below cost that nobody catches until the accounts are done. A tracking number pasted onto the wrong order becomes a support conversation and a refund. Automation is not bought to save time. It is bought to stop the business making the same small mistake several hundred times a year.

The part that gets skipped, and the reason so many automation projects produce something nobody trusts, is that the existing process is never written down first. It lives in one person's head, it has exceptions they apply without noticing, and if you automate the version you were told about rather than the version that actually happens, the system will be confidently wrong from day one.

How the work runs

1. Map the real process, step by step. We sit with whoever does it now and record what actually happens, including the exceptions they no longer think of as exceptions. This is the step people want to skip and it is the one that decides whether the finished system is trusted. Two to four days.
2. Decide what stays human. Not everything should be automated. Anything that spends money, cancels an order, changes a price a customer can see, or takes stock to zero gets proposed to a person rather than executed. We agree that boundary in writing before any code exists, so nobody is surprised by what the system is allowed to do. One day.
3. Build it in report-only mode. The supplier feed parser, the SKU matcher, the quantity calculation with its buffer, the low stock alerts, the courier booking, the tracking write-back. All of it runs and produces a report of what it would change. Nothing writes yet. Rate limits on the store API are handled here too, because a job that half-completes because it got throttled is worse than one that never ran. Four to seven days.
4. Run it in parallel with the manual process. For about a week the person keeps doing the job and the system keeps reporting what it would have done, and the two are compared every day. Every disagreement is either a bug or an undocumented rule, and both are worth finding now. Five days.
5. Cut over, schedule and instrument. The write path is enabled behind its limits, the job goes on a schedule, and failure alerting is set up and then deliberately tested by breaking it. A scheduled job with no alerting is a job that will stop silently and be discovered weeks later. Two to three days.

Tools depend on the shape of the problem. Shopify Flow inside Shopify for rules that never need to leave the platform. Zapier or Make where several services need joining and the volume is modest. n8n where the logic is heavy enough that per-task pricing stops making sense. Stock Sync for supplier quantity feeds. Google Sheets with Apps Script, which handles a surprising amount honestly and cheaply. Custom scripts against the store's admin API where none of the above will do it properly.

What moves the price

The range is $700–$5,000 and it is set by three things.

How many systems have to talk. One supplier feed into one store is a contained job. A store, a marketplace, a physical shop till and a courier, all needing to agree about the same stock, is a different order of problem, because now you have to decide what wins when two of them disagree.

How clean the supplier data is. This is the largest factor. A well-formed export with stable SKUs is straightforward. A file where the SKU has a prefix on one side and not the other, where the column order changes when someone at the supplier edits the template, and where quantities occasionally arrive as text, needs matching logic, normalisation and guards, and all of that is real work.

Whether you want a script or a system. A script you run does one job when told. A system runs on a schedule, keeps a log of every run, refuses to do damage, and tells you when it could not finish. The second is several times the price of the first and it is worth it for anything the business depends on every day.

What usually goes wrong

The automation is given permission to destroy. The classic is a rule that sets any product with zero stock to draft. It works for months. Then the supplier's export truncates overnight, three hundred products read as zero, and the script quietly removes most of the storefront before anyone is awake. This is not a hypothetical, it is the most common failure in this category. Every destructive action needs a ceiling: if more than a small number of records would change in one run, stop and ask.

Nothing is logged, so nobody can reconstruct what happened. Three days later a price is wrong and the only honest answer available is a shrug. Every run should write a record of what it read, what it decided and what it changed, kept long enough to answer the question "what did the feed say on Tuesday". Without it you are not debugging, you are guessing, and trust in the system never recovers from the first unexplained change.

SKU matching is assumed instead of measured. Your SKUs and your supplier's are nearly the same, which is more dangerous than being completely different. A prefix, a trailing space, a renamed column, and suddenly the job matches a fraction of what it should and treats everything else as absent. The guard is a match-rate threshold, checked before any write: if an unusually large share of rows fail to match, the run aborts and reports, because that pattern almost never means the stock vanished. It means the file format changed.