The second pass that kills the draft

The first version of our follow-up system texted leads at 2am. The message itself could have been fine. Friendly, short, relevant to what the lead had asked about. It still arrived at 2am, to a lead the client had paid for.

The fix was not a better prompt. It was a second step that reads every outbound draft before it goes anywhere and is allowed to say no. We call it the reviewer. It is the least exciting part of the system and probably the most valuable one.

What actually went wrong

The model had no idea what time it was where the lead lived. It wasn't asked. The send step didn't check either. Every piece did its own job, and together they texted someone in the middle of the night.

Fixing the time check was easy. The bigger lesson was that nothing in the pipeline had the job of asking whether this message should go out right now, to this person, in this form. The writer's job is to write. The sender's job is to send. Nobody was checking the whole thing.

What the reviewer checks

The reviewer runs after the model writes a draft and before anything is sent. Some of its checks are plain code and some are a second, smaller model call. The code checks come first because they're cheap and never wrong about what they test.

The code checks look at things that have one right answer. Is it between 8am and 8pm in the lead's local time? Has this lead asked to stop? Did we already send something in the last few hours? Is there a phone number or link in the draft that we didn't put there? Does the message mention a price, a date, or a property that isn't in the lead's record? Any of these is a hard stop. The draft is held, not deleted, and the next run picks it up when the reason clears.

The model check is for things code can't judge well. Does this sound like the team's agents, or like a bot? Does it answer the question the lead actually asked? Is it pushy for where the lead is in the process? Would a person reading it think the sender had forgotten the last conversation? The reviewer gets the draft, the lead's recent history, and a short list of what the team considers off. It returns pass or fail with one sentence of reasoning. A fail sends the draft back for one rewrite. A second fail goes to a human with the reason attached.

What it catches

Most rejections are boring. A message that repeats a question the lead already answered. A follow up that's too eager for someone who said they're six months out. A draft that mentions a showing time that's already passed.

The ones that matter are rarer and worse. A draft that mixes up two leads with the same first name and mentions the wrong house. A message that promises a rate the team never quoted. A cheerful check in to someone who told a human agent on the phone that they needed some time for a family reason. If that call note is in the CRM, the reviewer reads it. The writer has the same notes and can still miss it. The reviewer reads the draft and the history at the same time with one question in mind, and that's why it catches what the writer misses.

What it costs

The reviewer adds a few seconds and a small model call to every message. On an account sending a few hundred texts a week, that's a rounding error on the bill. It also delays some messages, which bothers people the first week. The team sees drafts held for review and wonders why the system is slow.

The real cost is that a reviewer makes a system feel less autonomous. When you show it to a client, you have to explain that some messages wait. Some prospects want a system that just sends. I get it. But the message that should not have gone out gets screenshotted and shared, and nobody screenshots the three thousand that went out fine.

Where to put one

If you're building anything that sends messages to real people on its own, put a reviewer between the writer and the send button. Start with plain code checks for time, opt outs, frequency, and anything that has to match the record exactly. Add a model check for tone and context once those are solid. Hold drafts instead of deleting them, and log every rejection with its reason so you can read them on Friday afternoon.

Those rejection logs are how you find the next bug before a lead finds it at 2am.