heurema
The request usually arrives as a solution. Automate support. Connect the CRM. Build an agent for documents. The current cost, owner, and acceptance condition are still missing.
I use five checks before calling the work a pilot candidate. They are a decision aid, not proof that automation will help.
1. The current cost is visible
There should be a concrete problem to compare with the intervention. Useful signals include waiting time, queue size, manual hours, repeated corrections, missed requests, and operational risk.
A vague wish to use AI gives no baseline. Without a baseline, any working demo can look like progress.
2. One person owns the result
The owner decides what counts as acceptable, which exceptions matter, and when the work must stop. Ownership can be shared operationally, but the final decision needs one clear place.
An ownerless process usually contains several conflicting versions of the rule. Automation preserves that conflict unless the team resolves it first.
3. The source of truth is known
The current state may live in a repository, CRM record, policy document, inbox, database, or queue. The team should know which source wins when two systems disagree.
This check often changes the proposed work. A data cleanup or system configuration may have more value than a new agent.
4. The first action is bounded and reversible
Prefer work that can be inspected before it reaches a customer, production system, payment, or legal commitment. Drafting, checking, classifying, and preparing a change are easier first steps than direct execution.
Write the stop condition early. Missing data, an unknown exception, a failed check, or scope drift should return the task to a person.
5. The outcome can be compared
Choose one primary outcome and a few guardrails. The primary measure may be time to an accepted result or reduction in a queue. Guardrails may cover rework, escaped errors, review time, and cost per accepted result.
Runs, tokens, drafts, and commits show activity. They do not show that the work became better.
Record the decision on one page
A small review note is enough.
- current problem and baseline
- owner and source of truth
- proposed intervention
- smaller alternative
- allowed actions and exclusions
- checks, stop condition, and rollback
- result that would justify continuation
The note can end with a pilot, a process change, a configuration fix, or no action. That decision is the useful output. The pilot begins only when its boundary is clearer than the enthusiasm around it.