The demo needs a second act
A chatbot can produce a list of ways to improve a restaurant's marketing. The operator still has to decide which suggestion matters, make the change and determine whether it helped. A useful answer can therefore leave most of the actual work untouched.
Sterling Douglass returns to that gap in his ChatGTM conversation with Michael Beck and Chad Horn. The Chowly co-founder is interested in systems that connect analysis to action and then return to the result. His measure of value is the business outcome the system helps produce, rather than the novelty of having a conversation with software.
That is a useful starting point for an operator sorting through AI offers. Ask the vendor to continue the demonstration past the answer. Who does the work next? What can the system change? Who checks it? And how will anyone know whether the change was worth making?
Use the simplest process that solves the problem
Douglass distinguishes between a defined workflow and a more flexible agent. He describes workflows that move information through predetermined steps, and agents that operate with a particular environment, tools and instructions. In his examples, both have a place. The more elaborate option is not automatically the more valuable one.
He illustrates the difference through advertising. Moving attribution data into another system can follow a repeatable process. Analyzing performance, proposing a change and testing a hypothesis involves a different kind of work. Understanding which problem you are solving helps prevent the language of the sales pitch from making the decision for you.
For a restaurant buyer, this can become a simple request: describe the work without using the word AI. If the explanation is that a report arrives with the correct numbers every morning, evaluate that reliability. If the system changes campaigns, evaluate the decisions, the controls and the evidence of improvement. Each deserves a different set of questions.
Keep the expert in the feedback loop
Douglass describes Chowly's marketing team using agents alongside people who already understand advertising. In his example, an agent can analyze performance by time of day, while a person brings judgment about the customer's volume and the appropriate objective. The team can then make a change, record what it expects and check the outcome later.
The return visit is important. Douglass gives an example in which narrowing the advertising schedule too far can concentrate the budget in an unhelpful way. A plausible change still needs to be evaluated against what actually happens. The system should preserve enough context for the team to learn from the result.
A practical test plan would capture the baseline, the change, the expected result and the review date. It should also make clear who can approve spending and who can reverse an unwanted change. These are operating decisions. They remain necessary even when the interface makes the work feel as easy as sending a message.
Watch where the bottleneck moves
Inside a company, faster production can expose a different constraint. Douglass describes work moving more quickly until testing, training or adoption becomes the next limitation. He treats that shift as useful evidence about where the organization needs attention next.
That perspective is especially relevant when a team celebrates how much more it can produce. More campaigns, features or written material do not guarantee that anyone has time to review, understand or use them. Output can accelerate while the experience for the customer remains unchanged.
When introducing an AI-assisted process, look beyond the person whose task became faster. Ask what arrives at the next person's desk and whether they can handle it. A successful experiment may need a better review process or clearer ownership before it needs more automation. Otherwise the queue has merely moved to somewhere less visible.
Build judgment along with fluency
Douglass is enthusiastic about learning through use, but he also describes a limit: someone without a strong sense of quality can produce weak work much faster. He encourages using the tools to understand the work, not simply to generate more of it.
His account of a hiring exercise makes that point concrete. He asked a candidate to build something with unfamiliar tools, then focused the follow-up conversation on what the candidate had learned. The finished artifact was a way into a discussion about understanding, obstacles and capability.
For restaurant teams, the equivalent starting point can be modest. Choose a bounded task, define a useful result and examine what happened. The goal is enough understanding to judge the next suggestion and recognize when help is needed. An impressive answer begins the conversation; a checked result is what earns the system a place in the business.
