Your Software Should Remove Work. This One Added 30 Minutes a Week.

I own an AI studio, and through it I work on AI projects for companies around the world. In this series, I write about some of the biggest mistakes I have seen in AI and software implementation projects, so that you can avoid making the same ones.

One of my clients, a paint manufacturer¹, sells most of what it makes through small, independent hardware stores. It delivers to those stores on its own routes, so it always knew exactly how much paint it had sent to each one. What it had no idea about was what happened after that: how much had sold, and how much was still sitting on the shelf. These are small shops, often family businesses, and it is common for one person to own several of them. The company's working assumption was that these shops were too small to use any kind of system: sales written down by hand, or rung up on a simple cash register that doesn't keep track of stock. If that was true, the only record of what was left was the shelf itself, and the only people who looked at that shelf every day were the shopkeepers and staff behind the counter.

The company badly wanted that number, and not just to plan nicer delivery routes. Without it, the company planned everything from what stores ordered, and orders are a late and distorted version of what customers actually buy. A store that ran out last week orders double this week. A store sitting on too much stock orders nothing for a month. The factory reads both as real changes in demand. It produces too much of some colors and too little of others, buys raw materials on the wrong forecast, and ends up with backorders on exactly the products people want.

Every one of those mistakes costs money, in rush production runs to catch up, extra delivery trips to stores that ran short, and paint piling up in a warehouse where nobody wants it. Every gap on the shelf is also a lost sale, because someone who comes in to buy paint for the weekend does not wait for your next delivery. They buy another brand.

Supply chain researchers have a name for the way small changes at the shelf grow into big swings at the factory: the bullwhip effect, described by Hau Lee, V. Padmanabhan and Seungjin Whang in MIT Sloan Management Review in 1997. Seeing what is left at the point of sale is how companies take the whip out of it.

Fact box: the bullwhip effect

When you crack a whip, a small flick of the wrist becomes a big swing at the tip. Supply chains do the same thing with demand. Each step in the chain, from the shop to the distributor to the factory to the factory's own suppliers, sees only the orders coming from the step below it, not what customers actually buy. So each step adds a little extra stock to be safe, orders in bigger batches and overreacts to a sudden spike or dip. By the time the signal reaches the factory, a small change at the shelf has turned into a big swing in production.

The term was made famous by Hau Lee, V. Padmanabhan and Seungjin Whang in 1997. Their best-known example came from Procter & Gamble, which noticed that orders for Pampers diapers swung up and down sharply, even though babies use diapers at a remarkably steady rate. The further up the chain P&G looked, the wilder the swings became.

The usual cure is visibility. When every step in the chain can see what is actually selling at the point of sale, it stops guessing from orders.

To solve the problem, my client turned to the only people who could actually see the shelves every day: its resellers, the stores themselves. The idea sounded simple. If every store told the company once a week what it had left, the company could take care of the rest. But what a store had left was never one number. A hardware store carries the company's paint in dozens of colors, several finishes and different can sizes, next to the primers, thinners, brushes and rollers that go with it. In the industry, each of those is a separate SKU, short for stock keeping unit: every color in every finish and every can size counts as its own item. Reporting stock meant counting every SKU on the shelf, one by one.

So the project quickly turned into something elaborate. There was a link to an app, and a spreadsheet that store staff were supposed to download, fill in SKU by SKU, and send back. After a while the company also asked them to add the prices they were charging. Most stores never filled it out, and some filled it out randomly just to get it off their desk. When that didn't work, someone from customer service started calling the stores every week to ask for their stock, category by category. For many stores, an honest count took thirty minutes or more, and the person on the other end of the line often had customers waiting. The numbers that came back were hard to trust, and the project was shut down before it was ever fully rolled out.

I started working with the company after that, and my advice was to keep the goal and drop the method. Knowing what is left on your customers' shelves is genuinely valuable. But this solution was doomed from day one, because it asked people who would get nothing out of the data to spend half an hour every week producing it for someone else. That is where IT projects go to die.

The app became the goal, and the problem got forgotten

On paper, the plan the company had sounded good. It described a simple app the stores would use to report their stock, so easy that nobody would need training or a manual. But like so many companies before them, my client forgot that technology is an enabler. Software, data and AI are tools for solving a problem. They are not the goal. Somewhere along the way the app became the project, and all the energy went into building the tool instead of solving the problem it was meant to solve, which meant understanding the people, the resources and the incentives involved in actually getting the job done.

The plan even shows it. It listed what the project depended on to work, and the first thing on that list was that the company would come up with some kind of reward to get the stores to report every week. Right next to it was a note saying management might need to rethink how it rewarded stores for sharing information. The most important question in the whole project, why anyone in a store would bother, was parked as an assumption for someone to solve later. Nobody did.

And that was the real problem. The people in the stores had absolutely no incentive to co-own this problem with the company. The benefits landed with the manufacturer, and the work landed with them. On top of that, the stores are not married to my client's paint. They carry plenty of other brands right next to it, so if my client's cans run out, the customer simply picks another brand from the same shelf and the store still makes the sale. A partially empty shelf is the manufacturer's problem, not the store's. This is one of the most common mistakes I see: companies confuse simple with free. A beautiful app still takes time to use, and thirty minutes of easy counting is still thirty minutes, taken from someone with customers waiting and a store to run. You can make a task easier, but you cannot make someone care about a task that only helps you.

Almost no store counted, and the counts that came in could not be trusted

People do one of two things with a data request that doesn't help them. They ignore it, and you get gaps. Or they fill it in with whatever is fastest, and you get dummy data. The second is much worse. An empty dashboard tells you that you don't know. A dashboard full of made-up counts tells you that you do, and then you plan your routes and your production around fiction.

This isn't only a small-store problem. In a 2024 survey by Validity, a company that sells data quality tools, more than half of respondents at data-reliant companies said their staff manipulate the customer records in their CRM system to tell managers what they want to hear, and 45 percent said staff simply make the data up. Doctors live with the same thing. A 2016 study found that for every hour doctors spend with patients, they spend nearly two more on electronic records and desk work, and when researchers at Penn Medicine looked at more than 100 million clinical notes, about half of the text had been duplicated from earlier notes. When a system demands text, people give it text.

And doctors and sales reps are employees. They are paid to fill in these systems, and the data still degrades. The people behind the counter in these stores didn't even work for the company. They worked for its customers. The company had no power to make them count, and they had every reason not to.

Brewers solved the same problem by making ordering easier for the shop

The companies that have cracked this didn't ask for extra work. They found something the shopkeeper already wanted to do and put the data collection inside it. AB InBev, the brewer, built an ordering app for small shops called BEES. Instead of waiting for a sales rep to come by, shop owners can see the full range and the prices, pick a delivery day, collect rewards and get clearer credit terms. AB InBev now reports more than six million customers on the platform and 72 percent of its revenue coming through its digital B2B platforms, and it told investors in 2023 that it suddenly had data it had never had before. Nobody had to beg the shopkeepers for it. They ordered because ordering got easier.

My client can't just copy BEES. Beer gets reordered every week, and the brewer is often a shop's most important supplier. Paint is one product line among thousands in a hardware store, and no store is going to install an app for every brand on its shelves. What carries over is the principle: capture the data at a moment when people are already doing something for their own reasons.

The stores already had cash registers, and some had a system from a competitor

For my client, the answer was closer than anyone thought. I challenged the assumption that the stores had no system at all. My suggestion, inspired by another client of mine, was to give the stores something they would actually want: a simple inventory app, or a tablet, that keeps track of the store's entire stock, every brand on every shelf, not just my client's paint.

This way, the store gets a tool that helps it run its business. My client gets a view of the whole transaction, including what sells when its own paint doesn't. Then we went out to the stores. Every single one of them had a cash register, and some of them already had an inventory system, supplied by my client's competitor. The transaction was already being recorded. It just wasn't being recorded for my client. What that says about how far a company can drift from its own customers deserves an article of its own, and I'll come back to it in the next piece in this series.

The company tried an app, a spreadsheet and phone calls, but never offered the stores anything

To be fair, the company did try. It went from an app to a spreadsheet to phone calls, and each version was an honest attempt to make the request easier. Each one failed, and they stopped before a full rollout.

What never changed was the deal. In every version, the store gave thirty minutes and got nothing back. The company tested how to ask and never tested why anyone would answer. That test would have been almost free. Visit ten stores, look at what sits next to the till, and ask the people behind the counter what they would want in exchange for counting the paint every week. Most of them would have laughed, and some of them would have pointed at the system they already had.

There was a deal to be made, at least in theory. My client could have offered the stores a revenue share, a small percentage back on every can sold, for stores that reported their stock every week. That would have given the people behind the counter a reason to count. The project offered the stores nothing, so it got nothing back. But I don't think paying for counts was ever the best answer. The better question was where the transaction was already being recorded.

The real cost isn't just one failed project. When a solution fails this visibly, the goal tends to get buried with it. After the last attempt crashed, nobody wants to be the person who proposes shelf data again, even though the idea was right all along.

Paying a fee for every count would have started a second business

The obvious objection is: fine, then pay the stores. Sometimes that works. Market research companies have paid households for decades to scan what they buy, and NielsenIQ expanded its UK panel to 30,000 households in 2024. But look at what that takes. Recruiting people, designing the rewards, checking the data and throwing out the ones who cheat is a whole business. A paint company that starts paying for stock counts has started a second company without noticing.

It has also created a reason to cheat. The social scientist Donald Campbell warned in the 1970s that the more a number is used to make decisions, the more pressure there is to corrupt it, an idea now known as Campbell's law. His example was the military's body counts. Pay a store per count and you will get counts. Whether they have anything to do with the shelf is another question. That is why a revenue share works better than a fee. A fee rewards sending a number, while a share of sales rewards a number that is true.

My client built a tool when what it needed was data from the point of sale

Looking back, my client made four mistakes, and none of them were technical.

1. It became tech-centric. The moment the problem was framed, the conversation turned to which tool to build: an app, a link, a spreadsheet. Nobody stopped to ask what the stores already used, what they needed or what they would get out of it.
2. It got stuck on the process. Every time the stores didn't report, the company changed how it asked, from the app to the spreadsheet to the phone calls, instead of questioning whether it should be asking at all.
3. It never got the people it depended on on board. The whole project relied on store staff doing extra work every week, yet nobody visited them, asked them or offered them anything. They had no reason to co-own the problem, and they didn't.
4. It mistook a tool for the project. The project was never to roll out an app or an AI feature. The project was to get reliable data from the point of sale. Seen that way, the question changes from how to get stores to use your app to where that information is already being recorded, and the answer was sitting next to the till the whole time.

At the start, the shelf looked like something only the people in the store could see, and the whole plan depended on persuading them to count it for the company. But the shelf was never the only record. Every can that left it went through a cash register, and in some stores through a system my client's competitor had put there. The information was being recorded every single day. My client just never went out to look. Nobody in that store ever agreed to count for you, and good software would never have asked them to.

¹ Every story in this series is real. To protect my clients, I change the details that could identify them, such as the industry, the products, the company's size and location, and the names of people and suppliers. What happened, the decisions that were made and the reasons they went wrong are kept as they were.

Sources

• Christine Sinsky et al., "Allocation of Physician Time in Ambulatory Practice: A Time and Motion Study in 4 Specialties", Annals of Internal Medicine 165(11), 2016.
• Jackson Steinkamp, Jacob Kantrowitz and Subha Airan-Javia, "Prevalence and Sources of Duplicate Information in the Electronic Medical Record", JAMA Network Open 5(9), 2022.
• Validity, "The State of CRM Data Management in 2024", 2024.
• AB InBev, "Second Quarter 2026 Results", July 30, 2026.
• Nick Caton, AB InBev, "Digitize and Monetize: BEES", Capital Markets Day transcript, September 20, 2023.
• NielsenIQ, "NIQ Completes Homescan Panel Expansion to 30,000 Households", October 2024.
• Donald T. Campbell, "Assessing the Impact of Planned Social Change", Occasional Paper 8, Dartmouth College, 1976 (reprinted in Journal of MultiDisciplinary Evaluation, 2011).
• Hau L. Lee, V. Padmanabhan and Seungjin Whang, "The Bullwhip Effect in Supply Chains", MIT Sloan Management Review, 1997.