The Tuesday Test
What the Starbucks AI inventory tool retirement confirms about enterprise adoption
The Starbucks AI inventory story is interesting because it’s very easy to treat it as a story about Starbucks, or a tool that didn’t work, but I don’t think that’s really the takeaway here. To me, it’s a pretty clear example of where a lot of AI adoption is getting stuck right now, which is that we keep confusing the fact that a system launched with evidence that the work actually changed.
On paper, inventory is a perfect problem to solve with AI. It’s repetitive, it’s operationally important, it happens constantly, and it’s the kind of work where you’d expect automation to create real leverage and scale, so I don’t think the original idea was irrational at all. In fact, that’s why the internal employee note stood out to me. Reuters reported that Starbucks shared internal employee feedback saying, “The thought behind it was great, but the execution was proving difficult,” and I think that sentence matters because it separates two things we usually concatenate. The idea can be right, and the adoption can still fail.
This is where I think organizations aren’t being honest enough. A lot of companies are looking at AI adoption through the lens of a program rollout. Did we deploy it successfully? That’s an IT question. Did we train people? That’s an L&D question. Did usage start? That’s a telemetry question. Those are useful program questions, but they’re not the adoption questions, and the reason those are the wrong questions is that none of them are measuring behavior. The real question is much simpler, which is, did the old work stop?
That’s what I’d be curious to know about the Starbucks case, because from what workers had reportedly raised earlier this year, the tool was confusing similar milk types, skipping items, and creating the kind of verification work that defeats the point of automation. Once that happens, the promise changes. The promise was supposed to be that the tool would remove work, but the reality became do the original work AND check AI’s work as well. At that point, you haven’t adopted a new workflow, you’ve now introduced a second workflow and asked people to do both.
That pattern is showing up everywhere right now. A support rep gets an AI-generated case summary, but still has to read the entire thread because they don’t fully trust it. A PM gets AI-generated customer themes, but still has to go back through the raw calls because the synthesis missed the nuance. A team gets a new AI assistant, but the shadow spreadsheet keeps living because that’s still the place people trust. In all of those cases, the tool may have launched and people may even be using it, but the old work hasn’t actually stopped, so you have addition instead of adoption.
Adoption should leave evidence behind in the workflow itself. Something should be gone. A manual step should disappear. An old weekly report should start getting a stale “last modified date”. That’s what I mean when I say adoption is measured by what stops, not what launches. The launch tells you something entered the organization. The stop list tells you whether the organization actually changed.
And I think that’s where a lot of AI programs are going to have a hard time, because launch metrics are much easier to defend. You can show training completion, you can show logins, and you can show enabled users. You can show the number of stores, teams, or departments where the tool is available, but all of those numbers can still hide the lived experience of the work, and the person closest to the workflow knows very quickly whether their Tuesday got better.
That’s probably the most practical adoption test I can think of. Is their Tuesday actually better instead of just different? If the answer is yes, you’ll see it because something will have stopped. They’ll stop double-checking something, or they’ll stop routing around the system. They’ll stop maintaining the old process on the side. If the answer is no, then the dashboard can be green and the adoption can still be theoretical.
That’s hard for organizations to admit because by the time a tool is live, a lot of people have a stake in the story that it worked. There’s a business case behind it. There’s budget behind it. There are leadership updates behind it. There are people who had to argue for it, fund it, sell it, defend it, and stand up in rooms saying, “This is where we’re going,” so when the people closest to the work start saying, “This is making my day harder,” that signal can feel like a threat to the story, even though it’s actually the most important data you have.
That’s the part of the Starbucks story I respect. They eventually made a decision that aligned with what people closer to the work had been signaling. A lot of organizations wouldn’t get there. They’d keep the tool running because turning it off would feel politically harder than letting it underperform quietly.
They’d keep calling it adoption because the system was deployed, they’d keep training people on it, and they’d keep reporting activity around it while the work itself stayed basically the same.
So if I were sitting with a team before an AI rollout, I don’t think I’d start with the launch plan. I’d start with the stop list. I’d ask the people closest to the work, “If this is successful three months from now, what should you no longer have to do? What should feel easier? What workaround should we be able to retire? What part of your Tuesday should feel meaningfully different?” Then three months later, I’d go back and ask whether any of that actually happened. Without a proper baseline, we can’t possibly measure the success of the program, at least not by any meaningful metrics.
If none of it stopped, I don’t think we should call that adoption yet. We can call it deployment, we can call it experimentation or enablement, and those may all be valid stages, but adoption is a higher bar. Adoption is measured by what stopped, not what launched.