Operators
The carrot and the stick
We take a bunch of intro & demo calls where people are downright mad about AI. Not in the good way. Two operators that called us up this week had their fair share of prior frustration:
“We had our team and some external people work on an AI voice-agent to take customer calls. It totally failed, even on the easy stuff! We only serve chicken and dressing on Thursdays and Sundays and for some reason it was saying we make it on Mondays and Fridays.”
- Owner, Multi-Unit BBQ Restaurant
“We used AI to analyze this one spec book, and it did all the things we needed, but all our clients have a different format, so it just kept failing on every new version.”
- CEO, Printing & Filing Business for Architects
In most cases, the first build is a one-trick pony. People fed it the “gold standard”, and now it can match that exactly, but only with specific conditions. It’s aggravating because it can’t scale.
One solution is to keep providing more context. Most teams we’ve met have a library of good examples that they want AI to reference. Then they continue to add more. That’s fine, but it’s only half the battle.
Every build needs an error log to know what NOT to do. Tracking the mistakes is just as important as the wins. Otherwise, these errors keep popping up when left unchecked.
Think of any AI tool like a dog. It gets rewarded with treats when it does something good. However, it also needs some discipline to know when it went wrong. An AI tool with only good examples acts exactly like you’d imagine a dog spoiled with treats.
To make this more practical, here are some ways we’ve seen clients deliver tough love in their build instructions:
Staffing: consolidate employees’ availability and preferences to save managers the hassle of building the schedule.
Quality Control: nobody likes checking for errors, so a simple automation sweeps data updates in the ERP for errors.
Proposals: automatic process that writes the first draft for responses to RFPs to decrease the time spent writing similar sentences.
We’ve seen this automated through a live error log spreadsheet, a “graveyard” folder of bad outputs, and an endless list of instructions. Anything works, but it’s always good to have some organization.
Here’s the immediate action for operators to take:
Create a table with 3 columns: Issue, Detail, and Date. Take 5 minutes to list out the 10-20 most common errors you’re getting with a specific tool. Explaining why it’s an issue in the “Detail” section is most important.
Once you link up that table to your tool, it will either get it right or find a new way to be wrong. If it’s the latter, add it to the list and eventually it will run out of ways to be wrong.
