Resources · automationagencies
Automation's real job is to find the problems you cannot see
Automation gets sold to you as a way to go faster. That is the smallest thing it can do. The bigger job is finding the problem you would have missed: a machine can read every client account, every ticket, and every call note at once, and hand you the one thing you cannot see.
Speed saves you an hour. Catching the problem you were about to miss saves you the client. This post covers what that looks like in practice, and the two checks that keep an automation from doing the opposite.
What can automation find that you cannot?#
The client who went quiet three weeks ago. The account that signed up and then did nothing. The project that is slowly losing money while everyone on the call says it is fine.
No person in a small agency reads everything every day. There is too much of it, spread across the CRM, the inbox, the project tool, and the call notes. A machine reads all of it in one pass, every morning, and never gets bored on account number two hundred.
What that looks like across a business, concretely:
| Area | What the machine reads | What it flags |
|---|---|---|
| Client accounts | CRM activity, email threads, meeting history | The client who went quiet three weeks ago |
| Delivery | Project tool tasks, time logs | The project quietly burning more hours than it bills |
| Pipeline | Deal stages, last-touch dates | The deal that has not moved in 30 days and nobody owns |
| Money | Invoices, payment dates, quote line items | The invoice about to go 60 days late, the quote where the math does not add up |
Each row is the same build: one source of truth to read, one rule for "this is a problem," one short message to a human every morning.
How do you test an automation idea before you build it?#
Before you automate a task, ask what it would find if it read everything at once.
If the answer is "nothing, it just does the boring step faster," you built a shortcut. That is useful, but it is small. If the answer is "it would flag the three accounts I have to call today," you built something that protects your money.
This test also sorts the four ways of buying automation. Off-the-shelf tools mostly sell the shortcut. The detection job usually needs something built around your own definition of "this account is in trouble."
Why do CRM labels break automation?#
Your CRM is full of labels that sound true and are not. An account marked "healthy, renewing" can be a client nobody has spoken to in four months. A tag that says "billing issue" can be a client who is quietly leaving.
The label got typed fast by a busy person, and everyone treated it as fact. Point automation at that data and the machine does not correct the lie. It sends the lie to more people, faster: cold emails, reports, and health scores all built on labels that were wrong from the start.
The fix is a 30-minute check you can hand to anyone on your team:
- Pull ten accounts tagged "healthy, renewing" that nobody has touched in months.
- For each one, read three things: the last three messages, the real usage numbers, and the notes from the last call.
- Write one line per account: does reality match the tag, yes or no?
- Count the noes. Two or more out of ten means the tags cannot be trusted, and any automation reading them is spreading fiction.
How do you catch AI numbers that look right but are wrong?#
A weird sentence or a made-up fact is easy to catch. The AI mistake that costs you is a clean number that looks right and is wrong.
A tool writes your quote. The headline says "50 to 75 dollars," so you approve it. Lower down, the same plan lists 14 hours at 50 an hour. That is 700 dollars of work hiding under a 75 dollar headline. Two numbers that should agree, and nobody checked.
How do we actually build a detection system?#
Here is what the build looked like on a recent client system, step by step:
- We connected the agent to the tools that hold the signals - the CRM, the inbox, and the project tool - with read-only access. It cannot change or send anything; it can only read.
- We sat with the owner for one afternoon and wrote the rules: what counts as "quiet," what counts as "slipping," which accounts matter most. The rules went into one plain document the owner can edit himself.
- We ran it in shadow mode for two weeks. The agent flagged accounts, we compared its flags to what the team already knew, and we tuned the rules that cried wolf.
- Then we plugged the output into Slack: one message every morning at 8, listing the accounts that match a rule, why they match, and a link to each record. No dashboard, no new tool to open.
The agent never contacts a client. It talks to the team, the team talks to clients. That line is wired in, not a policy hope.
Total build: weeks, not months, because the hard work was step 2 - and step 2 is thinking, not code.
What should you do this week?#
Pick one automation you already run and put it through five questions:
- What data does it actually read - one tool, or everything relevant?
- If it read everything at once, what could it flag that it does not today?
- When did anyone last check the data it reads against reality?
- Does any number it produces show its math?
- Who gets told when it finds something, and do they act on it?
Then ask the bigger question: what am I missing across all my accounts right now? The judgment for "this account is in trouble" probably lives in one person's head today - writing that judgment down and automating it is the natural next step.
That question is where the money is. It is also how the leanest setups we have reviewed work, like the agency running a team's worth of outbound on three tools: the tools watch everything, and the humans act on what gets flagged. The systems 8085 builds follow the same rule.