| Wednesday · June 10, 2026 · Issue #035 Marcus runs a 9-person commercial HVAC company in outside Dallas. Installation crews, service contracts, a dispatch operation he built from scratch over eleven years. The kind of business that runs on relationships and reputation — where a missed service call or a doubled booking can cost you a client you've had for a decade. Last fall, Marcus decided to fix his scheduling problem with AI. He found a well-reviewed automation tool, paid for the setup, spent three weeks getting it configured, and launched it to his team with real confidence. Sixty days later, he had more scheduling problems than before. Two long-term service clients had complained. One had left. |
| ⬡ Fear #7 — The One Nobody Admits Out Loud "What if we implement AI and it makes things worse?" This fear is usually dismissed as technophobia. It isn't. It's the most rational fear in AI adoption — and the one the tools industry almost never addresses honestly. Marcus's story is why. | |
| ⬡ What the Tool Did Right — And What Still Went Wrong | |
| Here's the thing that makes Marcus's story genuinely useful: the tool wasn't broken. It did exactly what it was supposed to do. It read the incoming service requests. It checked technician availability. It routed calls by zip code and booked appointments automatically. Fast, consistent, no manual entry required. What it didn't know — because nobody told it, because nobody had ever written it down — was that Marcus's scheduling wasn't actually about availability. It was about relationships. Certain clients always got Darius, the senior tech who'd been with the company for six years and knew their systems cold. Priority clients got morning slots because their facility managers worked half days. Two customers had standing arrangements — informal ones, never in the system — where they'd call Marcus's cell instead of the main line and he'd slot them in personally. The AI had no idea any of this existed. So it ignored all of it. Efficiently. At scale. |
| ⬡ The Principle Every AI Newsletter Skips Automation doesn't fix broken processes. It multiplies them. Marcus's scheduling "process" wasn't actually a process. It was a set of informal agreements, tribal knowledge, and relationship-specific rules that lived entirely in his head and his team's memory. It worked because humans were applying judgment at every step. When he replaced human judgment with automation, he didn't speed up a working process. He sped up the parts that didn't matter and stripped out the parts that did. This is the pattern research keeps confirming. Multiple independent studies from MIT, McKinsey, and RAND have all documented the same finding: AI failures almost never trace back to the wrong model. They trace back to unready processes, undocumented workflows, and outcomes that were never defined before the build began. | |
| ⬡ What Jordan Asked — And What Marcus Couldn't Answer | |
| Marcus came to The Promptory two months after the launch. He was frustrated — not at the tool, but at himself. "I did everything I was supposed to do," he said. "I picked a well-reviewed tool. I got it configured correctly. I trained my team. It still blew up." Jordan asked him four questions. The fourth one stopped him cold. |
| ⬡ Jordan · AI Solutions Director · thepromptory.com Free · No account required · No sales call after | | M | I tried automating our scheduling and it made everything worse. Two clients complained, one left. I'm not sure if I should try again with a different tool or just go back to doing it manually. | | J | Before we talk about tools, I want to understand the process that was there before. Walk me through exactly what happened when a service call came in — who touched it, in what order, and what decisions were made along the way. | | M | Call came in, my office manager would check who was available, pick the nearest tech, and book it. Pretty straightforward. | | J | When your office manager picked a technician, was it always just about availability and proximity? Or were there other factors that influenced who she assigned to which client? | | M | I mean — yeah, she knew certain clients always got Darius. He'd been servicing some of these buildings for years. And some clients wanted morning slots. She just knew that stuff. | | J | How much of that knowledge was documented anywhere — in your CRM, in a spreadsheet, anywhere a system could read it? | | M | ...None of it. It was all just in her head. | | J | That's the real problem — not the tool. Your tool worked perfectly. It just automated the visible part of your process and skipped the part that actually made your clients happy. The good news: this is fixable. But the fix comes before the technology, not from it. Let's talk about what needs to be documented first. Jordan · thepromptory.com → | | | Is your process ready to automate? Jordan will tell you honestly → thepromptory.com | | |
| ⬡ What Marcus Did Next — And What It Changed | |
| Marcus spent two weeks doing something he'd never done in eleven years of running the business: writing the process down. Not the simple version — the real one. Which clients had preferred technicians. Which accounts needed morning slots. What "priority client" actually meant — not just a flag in the system, but a specific set of behaviors that had to be different. What the exception rules were that his office manager had been applying on instinct for years but had never articulated out loud. By the time he was done, he had a two-page document. And when he reloaded that document into a rebuilt automation — with the rules, the exceptions, the client preferences all structured in the system — the scheduling tool that had failed him worked. Same tool. Documented process. Different outcome. |
| 📊 The Result Zero client complaints in the 90 days since the rebuild. His office manager recovered 6 hours a week. The client who left came back. The tool Marcus used the second time was the same tool he used the first time. What changed wasn't the technology. What changed was that he finally understood his own process clearly enough to let a system run it. That two-page document? It also onboarded his next hire in a single afternoon instead of the usual two weeks of shadowing. The documentation paid for itself before the automation even went live again. | |
| ⬡ The Process Readiness Test · 4 Questions Before You Automate Anything | |
| Before you hand any process to a tool — AI-powered or otherwise — it has to pass this test. If you can't answer all four, the process isn't ready. Document it first. Then automate. ① Can you describe it in writing clearly enough that a new hire could follow it without asking questions? If the answer is no — or if the written version doesn't match what actually happens — you have an undocumented process, not an automatable one. ② What are the three most common exceptions — and what's the right response to each? Every process has edge cases. If those exception rules live only in someone's head, the automation will handle them wrong. Every time. Consistently. ③ What does a good outcome look like — and how will you measure it in 30 days? Marcus couldn't answer this before the first launch. He knew the tool was "working" — but he hadn't defined what success looked like. Zero complaints. Correct technician assignment. These are measurable. "Better scheduling" is not. ④ Where does a human need to stay in the loop — and is that clearly defined? Full autonomy isn't the goal. The goal is removing the tasks that shouldn't require human judgment while keeping humans exactly where their judgment matters. If you haven't drawn that line before you deploy, the tool draws it for you. And it draws it wrong. | |
| 💡 The One Thing The tool is never the problem. The undocumented process it inherited is. Every business has processes that run on institutional memory — the stuff that works because one person knows all the unwritten rules. That's not a flaw. It's how small businesses move fast. The flaw is trying to automate those processes before translating that memory into something a system can read. Jordan's job isn't to recommend a tool. It's to ask the questions that surface what's actually going on — before anyone spends money on software. That's the part most AI tools skip. It's the part that matters most. | |
| 📬 Tomorrow Thursday Tip Stack: 73% of CEOs are stressed about AI right now. Here's the data on what the other 27% are doing differently — five decisions that separate the businesses winning with AI from the ones drowning in the conversation about it. Have a process that might be ready to automate — or one that might not be? Jordan will tell you honestly which one it is → thepromptory.com | |