Resources · automationagenciessystems
Automate your best thinking first, before the person who owns it leaves
The way you spot a bad account or a not-ready draft lives in one head. Usually yours, sometimes your best account manager's. Nobody ever wrote down how it works, and the day that person leaves, the skill goes with them.
This post is the step-by-step way to fix that for one judgment call: how to get the call out of the head, onto paper, and into a check a machine runs every morning. It takes about a week of small steps, and you need no technical skills for the first four of them.
Why does automating a judgment call beat automating a task?#
Task automation copies your hands. This copies the judgment, which is worth more and is at bigger risk, because the problems worth catching are the ones only your best people notice today.
There is also a hiring angle. When the judgment is written down, the next hire learns it in a week instead of a year, and you stop paying senior prices for work that has become a checklist.
How does a judgment call become a machine check?#
Four steps. The whole pipeline looks like this:
The technology is the easy part. Steps one and two are the hard part, because they force you to be honest about how you actually decide.
Step 1 - Which call do you pick first?#
Pick one call, and only one. Score your candidates against three questions:
| Question | You want |
|---|---|
| Does this call get made every week? | Yes - rare calls are not worth automating yet |
| Does getting it wrong cost real money? | Yes - a missed at-risk account, a bad quote approved |
| Does it live in exactly one head? | Yes - that is the risk you are removing |
"This account is at risk", "this lead is worth a call", and "this draft is not ready to send" are the three we see most in agencies.
Step 2 - How do you write the reasons down?#
Interview yourself, or sit with the person who owns the call, and ask the same four questions:
- Think of the last time you made this call. What did you notice first?
- What would have changed your mind?
- What do you check that others skip?
- What is the earliest sign, the one you see weeks before everyone else?
Write the answers as plain sentences with the why attached: "No reply in three weeks means the champion has stopped fighting for us internally." One page is enough. If it runs longer, you are documenting two calls, not one.
Step 3 - How do you turn reasons into rules?#
Each written reason becomes a question a machine can answer from your tools. The translation looks like this:
| The reason, in your words | The rule a machine can check |
|---|---|
| "They stopped replying" | Last reply older than 21 days |
| "They use it less than they used to" | Usage this month down 30% from their average |
| "Meetings keep slipping" | Same meeting moved twice in a row |
| "The invoice suddenly gets questioned" | Any billing thread opened in the last 14 days |
Some reasons resist translation - "the tone of their emails changed" needs an AI reading the thread, not a simple filter. Keep those in the rules table anyway and mark them. That is exactly the layer where a custom agent earns its keep over an off-the-shelf tool.
Step 4 - How do you test the rules before trusting them?#
Run the rules backward before you run them forward. Pull the last ten times the call was made - five where things went wrong, five where they were fine - and check each one against your rules table.
How do we wire the rules into your tools?#
The build we run once the rules table exists, on a recent client system:
- The rules live in one plain document, not in code. The owner can open it, change "21 days" to "14 days," and the check behaves differently the next morning. The judgment stays editable by the person who owns it.
- We connected the agent read-only to the tools that hold the evidence: the CRM for activity, the inbox for reply gaps, the calendar for slipped meetings. Read-only means it can never edit a record or send a message.
- We ran the backtest from step 4 inside the system - the agent scored the last ten known cases, and we tuned the rules until it caught the real problems without crying wolf.
- The output goes where the team already looks: one Slack message each morning naming the matching accounts, the rule each one tripped, and a link to the record.
Nothing in this build touches a client. The agent informs your team; your team acts. And because the rules are a document, the day you disagree with a flag, you edit a sentence - you do not call a developer.
What does the daily judgment check look like once it runs?#
A check reads your CRM, inbox, and project tool against the rules and posts one short message: "2 accounts match your risk rules today, here is why." A person still decides what to do - the machine only makes sure the call gets considered every day, on every account, including the ones nobody had time to look at.
That daily read-everything pass is the same pattern as the outbound stack one part-time person runs: machines watch everything, humans act on what gets flagged.
How do you start this week?#
Monday, pick the call using the three-question table. Tuesday, run the four interview questions and write the one page. Wednesday, translate it into the rules table. Thursday, test against the last ten cases. Friday, decide whether a filter in your existing tools can run it, or whether it needs a built check.
Even if you never automate it, you now own a page your business did not have on Monday: how your best judgment actually works.