The Automation Log
Treat your systems like employees: job descriptions, reviews, and firings
Learn how to write job descriptions, set KPIs, run reviews, and fire automations that stop performing — the management discipline most operators skip.
Every automation in your business holds a job. Most operators never write down what that job is — and then wonder why their stack feels like a mess six months later. Treat each system exactly as you would a hire: define the role before you build it, measure performance on a cadence, and terminate without sentiment when it stops earning its place.
What does a job description for an automation actually look like?
A job description for an automation answers the same questions you would ask about a new employee: What is this role responsible for? What does success look like in 90 days? Who does it report to (i.e., which human reviews its output)? What is it explicitly not responsible for?
For a lead-intake automation, that might read:
| Field | Detail |
|---|---|
| Role name | Lead intake router |
| Trigger | New form submission on contact page |
| Responsibilities | Qualify lead, log to CRM, send confirmation, notify owner if hot |
| Out of scope | Pricing conversations, contract generation |
| Owner | Kristian (reviewed weekly) |
| Success metric | 100% of submissions logged; owner notified within 5 minutes |
Writing this down takes 15 minutes. Not writing it down costs you hours of debugging later when the automation drifts from its original purpose or someone edits a step without understanding the full role.
This is the same discipline covered in delegating to systems instead of people — the job description is the delegation memo.
How do you set KPIs for a system that isn’t human?
KPIs for automations are the same concept as KPIs for employees: measurable outputs that tell you whether the role is being performed. The difference is that software can surface these numbers automatically if you build the logging in from the start.
Useful automation KPIs by category:
- Reliability — completion rate (jobs finished vs. triggered), error rate, manual intervention rate
- Speed — time from trigger to output (e.g., seconds from form submit to CRM entry)
- Business impact — leads touched, appointments booked, follow-ups sent, dollars in pipeline influenced
- Cost — API calls consumed, tool subscription cost per task completed
Run a simple model for yourself: if a follow-up automation is supposed to send a sequence to every new lead, and you see it only fired on a fraction of records last month, that gap has a dollar value. Multiply your average deal size by your close rate by the number of missed sequences. That number tells you whether a fix is worth prioritizing this week or next quarter. (These are illustrative inputs — plug in your own numbers.)
For a deeper look at which numbers to surface, the owner’s dashboard post covers the reporting layer that makes this practical.
The review cadence: scheduled, not reactive
Most operators only look at an automation when it breaks. That is reactive maintenance, not management. A scheduled review forces you to ask a harder question: is this still the right system for this job, even if it has not broken?
A lightweight review template:
- Pull the KPI numbers since the last review.
- Compare against the targets in the job description.
- Check for process drift — has the upstream input changed (new form fields, new CRM, new team member) that the automation does not know about?
- Ask: if I were hiring for this role today, would I hire this system again?
Quarterly is the right default cadence for most workflows. Monthly for anything touching revenue or customer experience directly — a voice agent, a booking flow, a payment reminder sequence.
In the businesses I run — including a real-estate brand and an AI receptionist platform — every active automation has a written role definition and sits on a quarterly review schedule, as of August 2026. The review is not about whether the tool is technically running; it is about whether the role still makes sense, whether the KPIs are being hit, and whether the system would survive a hiring review if I were filling the position today. The ones that would not survive get terminated. This discipline has kept my stack at a manageable size and prevented the accumulation of zombie workflows that quietly consume cost and attention without producing measurable output.
When — and how — to fire an automation
Termination conditions should be written into the job description upfront. Examples:
- Error rate exceeds a defined threshold for two consecutive review periods
- The upstream process it serves has been eliminated
- A better tool now exists and migration cost is justified by the improvement
- The business problem it solved no longer exists
Firing an automation is not just turning it off. Do it properly:
- Document the decision — why it was retired, what it was replaced with (or why nothing replaced it)
- Revoke credentials and API keys it held
- Remove or archive the workflow so it cannot be accidentally re-triggered
- Update any documentation that referenced it
Skipping these steps creates security exposure and confusion. A zombie workflow with live credentials is a liability.
This is the governance layer that most small operators skip entirely. If you want a structured way to build and enforce it, working with a Fractional Chief Automation Officer is how operators get this discipline installed without building it from scratch alone.
Building the habit
The management discipline here is not technical — it is operational. You already know how to manage people. Apply the same rigor to software.
- Write the job description before you build the automation
- Set KPIs at the same time, not after
- Put the review on your calendar the day you deploy
- Define the termination condition in the job description
If you run Business Runner or any other automation platform, these principles apply to every active workflow in your account. The tools do not manage themselves. You are still the manager — the org chart just looks different now.
For a fuller picture of how this fits into a one-person operating model, how one operator runs multiple companies without an office shows the stack in practice.
Want to talk through how to audit and manage the automations already running in your business? Start a conversation with the voice agent on this site.
Questions people ask
How do I know if an automation is underperforming?
Compare its actual output against the KPIs you set when you built it — completion rate, error rate, time saved, or revenue touched. If it consistently misses those benchmarks or requires frequent manual fixes, it is underperforming. Schedule a review rather than waiting for a visible failure.
How often should I review my automations?
A quarterly review cadence works well for most small operators. High-volume or revenue-critical automations — like a lead intake flow or an AI phone agent — warrant a monthly check. The review should take under 30 minutes if your KPIs are already defined.
What does it mean to 'fire' an automation?
Firing an automation means deliberately decommissioning it: turning it off, removing its credentials, and documenting why it was retired. This prevents zombie workflows from running in the background, consuming API calls, and creating data inconsistencies no one notices until something breaks.