Automate After the Walkthrough

The first useful version of an automation is usually not automated. It is a walkthrough. Someone checks the shelf, opens the export, traces the number, asks why the system says one thing and the floor says another, and writes down the exception that made the answer messy.

That part can feel slow because it is not the visible build. But it is where the real design happens. At Compass, inventory drift was not a single technical problem. It was production logging, cafe requests, purchasing timing, stale records, and human workarounds all showing up as one bad number in NetSuite.

If I had started with the script, I would have made the wrong thing faster. The better sequence was to walk the warehouse, compare physical counts against the saved searches, and separate recent production mistakes from chronic ignored errors. Once the team could explain the failure modes, automation had something honest to support.

The ordering calculator became useful for the same reason. It pulled 30-day sales, current inventory, and supplier lead times, but the important work was not just connecting those inputs. The first version over-ordered because the workflow had constraints the data did not yet describe cleanly. That feedback was not a failure. It was the system teaching us what still had to be made explicit.

Trust followed when the automation matched what operators already understood. The nightly export, the cron-driven attachment pull, and the weekly COO report worked because the underlying habits had changed first. People knew what the numbers meant, where they came from, and what to do when an exception appeared.

That is the standard I care about. Automate the repeatable work, but only after the manual version has exposed the edge cases, ownership, and close conditions. Otherwise the tool is not removing work. It is preserving confusion at a higher speed.