Two things this week. One was about making our lead counts true. The other was about a report that quietly stopped showing up.

Which leads were real

Every marketing report we send has a lead count in it. That number comes from tags in the CRM, and tags drift.

A spam call gets tagged as a lead. So does a vendor pitching SEO. So does an existing customer calling about an invoice. Nobody does it on purpose. It piles up one contact at a time, and the report ends up telling you that you got more leads than you did.

If you’ve ever read a marketing report and thought “that doesn’t match my phone,” this is usually why.

So we built a lead-verification system. It reads every new contact’s calls and messages and sorts each one: a lead, spam, a vendor, a customer we already have, or nothing to go on. Then it fixes the tags the reports are built from.

The part I cared about most was the guardrails, because this thing writes to live CRMs. Every change runs as a dry run first. I approve each item before anything gets written. And before it was allowed near a new account, it had to pass a safety check proving a tag change wouldn’t set off an automation a customer would see. Flip the wrong tag and a customer could get a text that was never meant for them. That’s not a bug you get to quietly fix later.

We started with August. 495 tag changes, 495 applied, 0 errors. Then we pulled 12 of those contacts at random and checked them by hand afterward. All 12 were right.

The next day it ran live: 512 changes, 0 failures.

The number that made me sit back was the manual pile. Before we pulled call transcripts into it, 364 contacts were too thin to sort without a person reading them. After, it was 16. Most of the guessing went away once the system could read the call.

More accounts passed the safety check this week before their first write. That check comes first, every time.

My early-warning system went dark for a week

Friday, my chief-of-staff agent, sends me a daily brief that flags what’s slipping before it turns into a fire. Starting around September 15, it stopped coming.

No error. No alert. It just didn’t show up, and I didn’t notice for a week.

When we dug in, the daily brief had never been installed where the scheduler looks. It wasn’t failing. It was never running. The Monday brief had its own problem: it was stalling in silence, waiting on cloud files to download, and it didn’t have permission to read one of them. The number of sources it could pull from had slid from 8 of 11 to 6 of 11, and then to a hard fail.

A broken thing that yells is easy. A broken thing that sits there quietly costs you a week before you even know to look.

The fix: every scheduled job now checks its sources before it does anything else. If it can’t read one, it stops, names the file, and pings me. That takes about 5 seconds. Before, it was a 14-minute stall that ended in nothing. We added 13 tests for it.

Then we went after the other half. A follow-up check makes sure every scheduled job is installed and loaded where the scheduler expects it, so one can’t go missing without me hearing about it. First run: 4 of 4 jobs installed, 0 drift, covered by 20 tests.

The daily brief was back on September 22.

A number nobody checked is a guess wearing a suit. Before an automated number goes in front of a client, something has to prove it. And when a report goes quiet, I treat the quiet as a failure until it proves otherwise.