Before They Ask

THE AUTOMATION EDGE

Go look at your inbox right now and count how many messages are somebody asking for a status update.

Where's my order. Did you get my file. Is this still happening Thursday. Any word on the quote. When should I expect to hear back.

Every one of those is a customer doing your job for you, and paying for the privilege with their patience.

Here's what makes it worse. Each of those messages costs you twice. Once when somebody reads it and goes looking for the answer, and once in the small deposit of doubt it leaves in the customer's head. Because by the time somebody asks where their thing is, they've already spent a few minutes wondering. The wondering is the damage. Your reply doesn't undo it, it just stops it getting worse.

The businesses that feel effortless to deal with are not the ones with the fastest replies. They're the ones you never have to ask.

That's the build for today. Not a chatbot to answer questions faster. A system that fires the answer before the question forms.

Before you build anything, you need to know what people actually ask. Not what you think they ask.

Go back through the last sixty days of customer messages. Every channel. Email, texts, DMs, the contact form, whatever comes through the phone that somebody wrote down.

Pull out every message that is fundamentally a request for information you already had. Not the real questions, not the "can you also do X" or the complaints. Just the ones where the customer wanted a fact that existed somewhere in your business and they couldn't see it.

Group them. You'll find they collapse into a handful of buckets fast, and the same buckets show up in almost every business I look at.

The first is timing. When will this happen, has it happened, is it still on schedule. This is usually the biggest bucket by a wide margin.

The second is receipt. Did you get the thing I sent. This one is pure anxiety and it's the cheapest to eliminate.

The third is next step. What happens now, what do you need from me, whose turn is it. This one is expensive because when customers don't know it's their turn, everything stalls and they blame you for the stall.

The fourth is money. What do I owe, did my payment go through, when's the next one.

Count them. Put a rough number on each bucket. That number is your build order, and it's almost never the order you'd have guessed.

The standard response to this problem is to write better onboarding. A nice welcome email that explains the whole process, sets expectations, tells them what to expect and when.

Everybody does this. It helps a little. It does not solve the problem, and it's worth understanding why, because otherwise you'll write a longer welcome email and be confused when nothing changes.

Information given at the start does not survive contact with time. You tell someone on day one that the proof arrives on day nine. On day seven they have no memory of that. They have a vague feeling that something was supposed to happen and an uncertainty about whether it's late. So they ask.

Expectations are not set once. They decay. The fix isn't a better initial explanation, it's a heartbeat.

The other reason the welcome email fails: it describes the general process, but customers care about their specific instance. "Proofs typically take five to seven business days" does not answer "where is mine." Generic information cannot answer a specific anxiety, and every status question is a specific anxiety.

So the build has two properties. It's recurring, and it's specific.

Here's the shape, and then the pieces.

For each stage of your customer's journey, there's a moment where the customer's mental model and reality drift apart. Your job is to identify those moments and put a message there.

Not a message that says "we're still working on it." That's noise and people learn to ignore it. A message that contains a fact they didn't have.

Let me make this concrete with the timing bucket, since it's the biggest.

Take your main delivery process. Write down its stages. Say it's: order received, in production, quality check, shipped, delivered. Five stages.

Now for each transition between stages, ask two questions. Does the customer currently find out this happened? And if they don't, when do they start wondering?

You'll usually find that customers get told about stage one and stage five, and the entire middle is a black box. Which is exactly where all your status questions come from. Not a coincidence.

The build is a trigger on each stage change that sends a short, specific message. Not a template with the stage name in it. A message that tells them what just happened, what happens next, and when.

Three sentences. It moved to this. Next is that. You'll hear from us by then.

That's it. That's the whole thing, and it eliminates most of the timing bucket on its own.

THE AI WORKFLOW BLUEPRINT • $47

The Blueprint includes the proactive communication map: the stages where customers reliably start wondering, the message that belongs at each one, and the trigger logic to fire it. It's the difference between building this from scratch and adapting something that already works.

The mechanics are simpler than people expect, and the trap is making them complicated.

You need three things. A place where stage changes get recorded, a trigger that notices the change, and a sender.

If you already run a CRM or a project tool, the stage changes are probably already being recorded, because somebody drags a card or updates a status field as part of their normal work. That's your signal. You don't need a new process, you need to listen to the one you have.

Make handles the middle piece well. Watch for the field change, look up the customer, format the message, send it. It's the least glamorous automation you will ever build and it will outperform most of the clever ones.

For the sending, use whatever channel the customer already uses with you. This matters more than it sounds. A text about an order lands. An email about an order goes to promotions. If your customers text you, and they increasingly do whether you invited it or not, send there.

One rule that will save you: send from a place that accepts replies. The single fastest way to poison a proactive update system is to send it from noreply. You've just told the customer that you'll talk at them but not to them, and the whole point of this exercise is to reduce the feeling that they're shouting into a void.

Most of what I've described is rules and pipes. No intelligence required, and adding intelligence would make it worse. You want a status update to be identical every time. Consistency is the feature.

There are two places where AI earns its keep in this build.

The first is writing the messages in the first place. Feed a model your last two hundred customer messages and ask it to identify the questions being asked, cluster them, and rank them by frequency. That's the question inventory from the top of this piece, done in an afternoon instead of a week. It's genuinely good at this, because it's pattern finding across a pile of unstructured text, which is the thing it's actually built for.

The second is handling the replies. Once you start sending proactive updates, you'll get responses. Most of them are fine, a few need a human. Sorting which is which is a real job and a model does it well. Route the "thanks" and the "great" straight to an archive. Route anything with a question or a negative tone to a person, fast.

What AI should not do here is generate each individual status message. You'll get variation you don't want, a small ongoing cost, and a nonzero chance that one day it tells a customer something imaginative about their order. Rules for facts, models for mess.

If you want the fastest win on this list, do this one first.

Every place a customer can send you something, they should get an immediate confirmation that contains a specific detail proving a human system received the specific thing.

Not "thanks, we got your message." That reads as automated and reassures nobody. Something closer to: we received your file, it's the one named quarterly draft, it's with the design team, you'll hear back by Thursday.

The specificity is the entire trick. A generic acknowledgment and no acknowledgment produce almost the same amount of follow up. A specific one produces almost none.

This is a one hour build in most stacks and it will visibly reduce your inbound volume within a week.

Here's the bucket most people skip, and it's the one with the longest tail.

The next step bucket. The moments where the ball is in the customer's court and they don't know it.

Every business has these. You sent the proof and you're waiting on approval. You need a document before you can proceed. There's a decision that's theirs to make.

What happens in most businesses: silence, then a chase a week later, then an apologetic "oh I didn't realize you were waiting on me."

That week cost you real money and it cost the customer a week of their own timeline, which they will remember as you being slow. You got blamed for their delay. That's how it always goes.

The build: whenever a stage change puts the ball in the customer's court, that message says so explicitly, and a reminder fires if nothing happens in a set window. Two days, usually. Then again at five with a slightly different tone.

The reminder is the part people find uncomfortable and it's the part that works. You are not nagging. You are preventing a situation where both parties are waiting for each other, which is the single most common way projects quietly die.

Pull sixty days of messages and build the question inventory. An afternoon.

Build the receipt confirmations. An hour, and it starts working immediately.

Map your main delivery process and put a specific message at every stage transition the customer currently can't see. A day, maybe two.

Add the ball in your court reminders on anything that waits on the customer. Half a day.

Then leave it alone for a month and watch your inbound status questions. If you built it right, that bucket drops by most of its volume, and the messages you do get are the interesting ones, the real questions, the ones worth your attention.

The goal was never to answer faster. It was to make the question unnecessary.

THE AI BUSINESS ACCELERATOR • $97

Eight weeks of building this into your business properly. We inventory the questions, map the stages, build the triggers, and write the messages in your voice. By the end your customers stop asking where things are, because they already know.

Jordan

The AI Newsroom | Jordan Hale | ainewsroomdaily.com