How do you distinguish a problem AI solves from a problem AI merely touches?

Bicuspid builds the scheduling and reminder software a dental practice runs its day on, including a model that scores every booked appointment for no-show risk. Lorand Kirkpatrick owns that model. Oswin Sunderland runs growth, and he just closed a nine-location renewal with Fettle Dental Partners by telling them Bicuspid's AI fixes their no-show problem. The model does something real. It was never built to do that.

How to answer this, stage by stage

Nobody in the room is grading whether you sound thoughtful about "AI limitations." They're grading whether you can point at the exact seam between a correct model and a finished product.

Let's learn

Five steps, and the whole argument sits inside the fourth one: what happens between the model being right and the chair actually filling.

Bicuspid runs the schedule for Fettle Dental Partners, nine dental clinics under one ownership group. Its biggest and busiest location, Kestbridge, is where the pilot started and where most of the model's training history came from. Book an appointment anywhere in that network, and Bicuspid's model quietly scores it: how likely is this specific patient, at this specific time, to not show up.

Before any of this, Fettle's no-show rate sat at 21% network-wide. Roughly one in five booked chairs, empty, about 71 a day across nine locations, and a dental chair that sits empty for thirty minutes can't be filled after the fact, that revenue is just gone. Fettle had been living with that number for years, the ordinary cost of running a busy practice.

Once Bicuspid's model went live, and Oswin sold it as the fix, front desks got a new tile on the dashboard every morning: about 51 names, flagged red, the ones most likely to skip. Nothing else changed for those patients. Same reminder text, same call script, same slot. The rate held at 19%.

The list changed which names got a red flag. It never changed what happened to the person wearing one.

Here's the turn. The model wasn't wrong. When it said a patient was high risk, it was right about 62% of the time. Being right was never the problem. The problem was that nobody had built anything that happened differently once the model was right. A correct guess with no action behind it doesn't fill a chair.

What I would leave alone: Fettle's clinical director also sees the raw risk score on an internal staffing dashboard, purely to plan chair capacity for the week ahead. Nobody promised that dashboard would fix anything. It's honest about being a clue, and a clue is exactly what it's for. That one stays exactly as it is.

The lesson: a model's output being correct and a product being finished are two different claims, and it's easy to let the first stand in for the second because they feel like the same kind of good news. They aren't. Only one of them means the customer's actual problem went away.

Now here is the same thing as a story

The short version above is what you'd actually say out loud in the room. Read this one for what it cost to find out the slow way.

Lorand Kirkpatrick has spent four years building scoring models for Bicuspid, the kind that don't do anything flashy, they just quietly rank things: which claim needs review first, which lead is worth a call, which appointment is about to become an empty chair. He is good at the part everyone skips, checking whether a model's confidence number actually means what it claims to mean before anyone ships it.

The no-show model was his best work yet. Trained on two years of Fettle's own booking history, it could look at a Tuesday 7:40am slot, booked by a patient with two prior no-shows and no insurance on file, and say, correctly about 71% of the time, that the chair was about to sit empty.

Oswin Sunderland runs growth at Bicuspid, and he'd been chasing the Fettle renewal for two quarters. Nine locations, a real logo, the kind of deal that gets a mention in the all-hands. When Lorand's model cleared its accuracy bar in March, Oswin built it straight into the pitch: Bicuspid's AI now fixes your no-show problem. Nobody in the room pushed back. The number really was good.

For the first few weeks after signing, it felt like it was working, in the vague way these things always feel like they're working right after a deal closes. Fettle's ops team got a new tile on their dashboard every morning, 51 names, flagged red. People liked looking at it. It felt like control.

Then the weeks kept passing, and the number underneath the tile didn't move. Week four, still 20%. Week eight, still 19%. Lorand noticed it before anyone at Fettle said a word, the way you notice a metric that's gone quiet in exactly the way it shouldn't.

He didn't chase it right away. There was always something else that quarter.

Thirteen quiet weeks, then one sentence in a screen-share, then six weeks to build the thing that should have shipped with the pitch.

The trigger, when it came, was small. Fettle's quarterly business review, week thirteen, a screen-share and a spreadsheet. Their ops director scrolled to the no-show line, paused, and said, mostly to herself: "You said this fixes no-shows. All it did was put a color on a name we already both knew was going to skip."

Nobody argued with her. She wasn't wrong. Lorand sat there doing the math in his head: thirteen weeks, fifty-one names a day, and not one of them had gotten anything different because the model flagged them. Same text. Same call script. Same chair, empty at 7:40.

I want to say the model was the problem. It wasn't. The model was doing exactly what a risk score does, sitting there, correct, waiting for someone to act on it. Nobody had built the acting-on-it part. Oswin's deck had promised a finished thing. Lorand's model had shipped a clue.

Neither of them was lying about what they were holding. The contract was real. So was the score. They just weren't the same thing.

Months earlier, in the release meeting where the model cleared its bar, someone had asked, almost as an aside, "so what happens differently for a flagged patient?" The honest answer at the time was: nothing yet, that's phase two. It got written down as a note for later, and the deck went out anyway, because the Fettle pitch was two weeks out and the accuracy number was too good not to use.

I would take that back. Not the model. The sentence. I'd hold the word "fixes" until phase two actually existed, and sell phase one for exactly what it was: a flag good enough to build a real fix on top of.

Here's the replay. Six weeks after the QBR, phase two shipped: flagged patients get their reminder a day earlier, a one-tap button to a guaranteed alternate slot, and if they haven't confirmed by 24 hours out, the seat goes to the next name on a standby list automatically, no front-desk phone call required. Same model, same 51 names a day. No-show rate at week fourteen: still 19%. Week sixteen: 15%. Week twenty: 9%.

One version of this story sells "fixes no-shows" in March and spends the next two quarters explaining a flat line to an increasingly unhappy client. The other spends six weeks building the part that was always going to be phase two, and gets to say "solved" honestly, four months later than the deck claimed, but true when it finally landed.

What I'd tell my past self, sitting in that release meeting: a good number is not the same thing as a finished product, and the two feel identical for about thirteen weeks, right up until someone asks what actually changed.

PICK, for the day a right answer gets sold as a finished one

Not a script for staying calm when someone spots the gap. PICK only pays off if it makes you name, before anyone asks, the one test that tells solved from touched.

One path costs a slightly smaller deal today. The other already sent Bicuspid its real bill, in a screen-share, thirteen weeks in.

The score was step one all along. Solved needed the other four parts wired to it.

The trade worth saying out loud: building the real action loop before promising it meant Bicuspid couldn't say "solved" back in March, when the deal was hot and everyone wanted that exact sentence. It's worth paying, because a risk score with nothing behind it doesn't fill a chair, and a client who hears "fixes" and gets "flags" stops trusting every number you show them next, not just this one.

And if you want to be sure it really works, try it somewhere else

Same four letters, a truck instead of a dental chair, and the missing piece is a part number instead of a phone call.

Ironvent runs dispatch software for HVAC field service companies, including a model that scores every scheduled repair for callback risk: how likely a technician is to have to drive back out because the first visit didn't actually fix the problem. Mid-way through a growth push, someone on Ironvent's team proposes selling that callback score as "AI that eliminates repeat visits."

Same shape as Fettle's flagged list: a correct warning, still leaving the technician to guess.

Position: a problem AI solves is one where the model's output is the finished thing, here, the actual part sitting on the truck before the technician needs it. A problem AI merely touches is one where the output is a warning with nothing behind it, here, a callback-risk score that tells dispatch "this one might come back" while the technician still drives out guessing which part to bring. Impact: sell the score alone as a fix, and technicians keep making blind guesses on high-risk jobs, they just now know, uselessly, that they were about to guess wrong. Cost asymmetry: scoping the pitch as "flags likely callbacks" costs a smaller first rollout, cheap, three depots instead of twelve. Selling "eliminates callbacks" and shipping only a bare score costs a technician a wasted second truck roll on a homeowner's roof in July, expensive and visible to the customer, when the real fix means arriving the first time with the part that should already have been on the truck. Kill criteria: does the technician still have to guess which part to bring after the model runs? Today, yes, on every flagged job. Ironvent ships "flags likely callbacks" today, and holds "eliminates callbacks" until the predicted-failure-to-part-order pipeline actually exists.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: name the test, does the person still do the hard part after the model runs, before anything else.
Cost: no time to build the real action layer before a deadline. Fine, but sell the honest label for the piece that exists, and hold the bigger word for the piece that doesn't.
The model got better, for real: say precision climbs to 95%. Still doesn't solve anything on its own. A more accurate clue is still a clue until something acts on it.

Where people run it wrong.
They let a strong accuracy number get translated into a strong outcome claim, without checking whether anything downstream actually changed.
They do eventually build the action layer, but leave the oversold sentence sitting in every deck until then, so the trust is already spent before the real fix ships.
They treat "showing the user more information" as the same product as "doing the hard part for them," when those are two different builds with two different promises.

How to use it live. If you're ever asked whether a feature "solves" something, buy yourself a second with one plain question: "after it runs, does the person still have to do the hard part themselves?" That question is the whole method, asked out loud instead of stated.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0