If you have been following this series, you know I have been climbing a ladder. First, I asked an AI model to do a task. Then I got tired of explaining the task every time, so I wrote a skill, a reusable set of instructions, and put it in a project folder with everything the task needed.
That is where many people stop, and it is a fine place to stop. The model knows what to do. You just need to feed it.
Automation removes repetitive labor, but it does not remove the need for oversight.
But feeding it is still a job. Every month, I logged into Lightspeed Analytics, downloaded the same reports, dropped them into a project, and asked the model to do something it already knew how to do. I had automated the thinking but not the workflow.
This month, I changed that.
Here is the ladder I have been climbing:
Rung one: Ask. Open a chat and ask the model to perform a task. This works well for a one-time task.
Rung two: Teach. Write down how you want the task done so you don't have to re-explain it. This is useful for recurring work with changing inputs.
Rung three: Build. Have the model write a program to perform the task. Now the logic lives in code you can read, test and fix.
Rung four: Schedule. Put that program on a timer so it runs whether or not you remembered, were busy or were awake.
For much of the year, I made the mistake of treating rung two as the destination. It is not. Rung two is where you discover what the task actually requires. Rungs three and four are where you stop being part of the task.
For most of this year, I have had two skills in my Claude project. One formats monthly and quarterly sales reports from Lightspeed Analytics exports. The other converts those reports into a PDF analysis for the owners, including location performance, category contribution and red-yellow-green status charts. Both worked well, but both required me to download the data first.
Last month, I wrote about getting all 21 stores syncing with Retalyz nightly. Eventually, the obvious consequence clicked: The data was already there. Every sale, refund, category and store was in a database I control and refresh nightly. I was still exporting from Lightspeed because that was the habit.
In August, reporting moved into the portal. A database function assembles the month’s sales, tickets, average ticket, category mix and year-over-year comparison into a single package. A Python renderer turns that package into the email and attachment. A scheduler on our server runs at 7 a.m. Pacific, determines who should receive which locations, renders the appropriate report and sends it.
Nobody opens a chat window. Nobody downloads anything.
The most important decision in this build happened before we wrote any code, and it wasn't technical. I started by reverse-engineering the monthly email our flagship manager already sends. She pulls several Lightspeed reports, creates a daily comparison between this year and last year, and writes a narrative. Looking across a year of those narratives, I realized most of her judgment came down to two numbers: sales and average ticket.
Another reason to automate it: Not every manager sent the report, and those who did formatted it differently. The owners were receiving a stack of documents that answered the same question in different ways. With one email, one layout and every store on the same morning, you do more than save time. They create consistency across the chain.
That is the part I would emphasize for retailers considering a similar project. Start by identifying the person who currently does the work manually. Determine which two or three numbers their judgment depends on, then ask which numbers they wish they had. Do not begin with automation for its own sake. Instead, begin with the decision the report is supposed to support.
If you want to move past rung two, start there on purpose. Write the skill and run it manually for a few cycles. That is where you discover which numbers matter, how date rules behave and where the source data can mislead you.
Then have the model write the program, not just the answer. Ask for a script that pulls the data, applies your rules, and produces the report. Have it explain each rule it applied, then read those rules carefully. That becomes your job: understanding and validating the logic.
Run the old and new processes side by side. Do not turn off the old process until the new one matches it in real periods and real numbers. When they disagree, investigate the difference rather than assuming either process is correct.
Then schedule it. We use a cron job on a cloud server. The exact setup matters less than the principle: Once the process is stable, stop relying on a person to remember to start it.
Finally, monitor it. Something needs to detect when the process does not run or produces an unexpected result. Automation removes repetitive labor, but it does not remove the need for oversight.
The monthly report is only the first step. The next version gives each manager a page to review the report, add a brief narrative, and forward it to the owners. That turns reporting from a recurring production task into a repeatable management process.
The chat window is where you figure out the job. The schedule is where you stop being the job.
Zondre Watson is the general manager of technology and analytics for adult retail chain Ero-Tech. With a background in finance, chocolate and controlled chaos, he blends retail know-how with AI tools to keep 17,000 products moving smoothly.
