Prove the workflow deserves AI before you automate it
A workflow should earn the right to receive AI automation.
Readiness isn't the ideal procedure in a document. It is the work the company can prove it performed across the last three observed runs.
Those runs show whether the path is stable, what people can trust, where context breaks, who can act, how failure is contained, and what the work costs. They give a COO, VP Operations, or CIO enough evidence to return one of four verdicts: cleanup first, fixed-scope pilot, human-in-loop only, or do not automate.
Define readiness from observed work
Start with one handoff and its last three completed examples. Reconstruct each run from the request, records, messages, approvals, system events, corrections, and final outcome.
Don't begin with the ideal SOP. Use it as one record among several. The operating question is whether the SOP describes what people actually did.
For each run, capture the inputs, sequence, systems touched, decisions, exception paths, owners, elapsed time, manual effort, rework, and outcome. Mark every point where the evidence is incomplete or two records disagree.
Then name the source of truth for each material fact. A CRM may control account status. A signed contract may control commercial terms. An identity system may control permissions. The workflow must also name which authority wins when records conflict. Without that rule, automation can execute the wrong record faster.
Three runs don't prove long-term stability. They provide a bounded readiness sample. If the three examples differ in ways the team can't explain, the correct verdict is cleanup first, not a broader pilot.
Apply five checks to one real handoff
Consider a customer order hold. Sales Operations gathers the order record. Finance checks credit status. Customer Success confirms contract terms. An authorized operator releases the order or escalates it.
Apply five checks to the last three holds.
- The observed path is explainable. The evidence table should show the same core inputs, decision sequence, and completion rule for routine cases. Any variation needs a reason and an owner. The process owner decides whether observed practice or the written SOP becomes the approved standard.
- Record authority and context integrity are explicit. Every decision needs the facts, history, and policy required to interpret the case correctly. The workflow must identify its source of truth and the authority that resolves conflicting records. Missing contract amendments, detached email approvals, stale customer status, or copied notes with no provenance are context failures. They require cleanup before autonomous action.
- Access follows least privilege. State which systems the automation may read, which fields it may write, which actions require approval, and which actions remain prohibited. Give access only for the approved scope and duration. Shared credentials, broad administrator rights, or an inability to attribute an action to one identity block the pilot.
- The failure boundary is containable. Define the biggest acceptable mistake before launch. The plan must show how the team will identify every affected record, pause new actions, roll back reversible changes, preserve evidence, and route recovery to a named owner. If one error can spread across an unknown set of records, the boundary isn't ready.
- The result and full cost are measurable. Record cycle time, human effort, queue delay, rework, exception volume, and failure cost for the three runs. Name the business result the workflow exists to produce. Faster handling doesn't count as improvement if review queues grow, exceptions move to another team, or recovery work rises.
The checks produce named authority. “The team” can't resolve a record conflict, approve access, stop a bad run, or own recovery.
Compare the full cost of the decision
A controllable workflow can still be a poor automation investment. Compare three cost layers before approving a pilot.
Current-work cost includes handling time, waiting time, coordination across people and systems, repeated status checks, rework, and the expected cost of known failures. Use the last three runs to establish a coordination-cost baseline. Keep elapsed time separate from labor time so a queue doesn't disappear inside an average.
Bounded cleanup and implementation cost includes reconciling the SOP with observed work, resolving conflicting records, repairing missing context, narrowing permissions, defining the failure boundary, preparing evaluation cases, and implementing the fixed scope. Treat cleanup as a visible investment, not free preparation.
Post-launch cost includes review time, exception handling, monitoring, incident response, affected-record analysis, rollback, recovery, policy updates, and periodic reevaluation. Estimate these costs for the planned volume and review depth.
Then state whether the change creates capacity or shifts work. Capacity is created only when trained people can stop doing enough current work to take on named higher-value work. If review, exception, or recovery work moves to Finance, Security, Operations, or Customer Success, the proposal shifts capacity. Put that transfer in the decision.
No universal review ratio settles this calculation. Set review depth from the observed exception mix, failure boundary, reviewer skill, and required response time.
Return one of four written verdicts
The diagnosis should end with a decision, not a readiness score.
Verdict | Use it when | Required next step |
|---|---|---|
| The work has value, but the observed path, record authority, context, permissions, failure controls, ownership, or cost baseline is incomplete. | Repair the named gaps, then examine three new runs. |
| The path is stable within a narrow boundary, access is limited, failure is containable, economics justify learning, and reviewers can cover the planned volume. | Fix scope, volume, permissions, review depth, stop conditions, recovery owner, evidence standard, and end date before launch. |
| AI can prepare, classify, retrieve, or recommend, but a trained person must make or approve the consequential decision. | Define the mandatory approval point, reviewer capacity, prohibited actions, escalation path, and audit record. |
| The work changes too often, required context can't be preserved, access can't be controlled, failure can't be bounded, or total cost exceeds the operating value. | Keep the work human-operated, redesign it, or select a different handoff. |
A fixed-scope pilot is temporary and bounded. Human-in-loop only is an operating constraint. Don't use a pilot label to avoid stating that a human decision must remain permanent.
Start with one costly handoff
Start with one handoff that creates repeated chasing, waiting, rework, or avoidable failure. Examine its last three completed examples.
Majestic Labs will return four artifacts: an evidence table for the three runs, a coordination-cost baseline, a written verdict, and a one-page executive brief covering the decision, boundaries, owners, economics, and next action.
Submit one costly handoff for the diagnostic. The result will be cleanup first, fixed-scope pilot, human-in-loop only, or do not automate.