Transform the first workflow that combines meaningful operational drag, repeatable decisions, accessible evidence and a safe path to deployment. Do not begin with the department making the loudest AI request or the demo with the greatest spectacle. Begin where completed work can improve a commercial constraint and where you can prove, within a defined boundary, that the new route is better than the old one.
The purpose of a workflow audit is not to produce a long list of automation ideas. It is to choose a credible starting point.
Why most AI opportunity lists are too shallow
A typical workshop asks teams what they would like AI to do. The answers are predictable: write content, answer support, analyse data, qualify leads, create reports and automate follow-up.
Those are capability categories, not implementation briefs. They omit the operating facts that determine whether a workflow can move safely:
- where the input originates;
- which record is authoritative;
- how complete and structured the data is;
- which decisions repeat and which require judgment;
- what the system may read, draft, change or send;
- who owns an exception;
- what evidence proves completion;
- whether the team will actually use the result.
An audit makes those facts visible before the business commits to architecture.
Begin with the work, not the organization chart
Departments are useful for ownership, but work rarely stays inside one box. A new lead may cross advertising, CRM, qualification, sales and reporting. A client report may cross accounting data, analysis, explanation, approval and delivery.
Choose a work item that has a clear beginning and end:
- a lead arrives and receives a disposition;
- a new client completes onboarding and becomes delivery-ready;
- an order-status enquiry receives an approved response;
- a monthly reporting period becomes a reviewed client explanation;
- a clinic prospect becomes a verified recruitment contact with a next action.
The unit of analysis is not “sales” or “operations.” It is one object moving through a sequence of decisions.
Step 1: write the completion condition
Before mapping the current process, finish this sentence:
This workflow is complete when __________, and we can prove it because __________.
Examples:
- A lead is complete when it is disqualified, scheduled for retry or transferred to a human closer, and the CRM contains the disposition and call record.
- A financial review is complete when the client has a period-specific view, unanswered questions are routed to the bookkeeping team and no unauthorized write has occurred.
- A clinic research task is complete when the authoritative recruitment record is confirmed, the next outreach action is approved and follow-up is recorded.
If the team cannot agree on completion, it is too early to automate the route. The current process itself is not settled.
Step 2: map the current path without improving it
Use actual recent examples. Follow the work as it happened, including the awkward steps. A useful map has seven columns:
| Stage | Input | Person or system acting | Decision | Tool or source | Output | Failure or delay |
|---|---|---|---|---|---|---|
| Arrival | What appears? | Who notices it? | Is it eligible? | Inbox, CRM, form | Accepted or rejected item | Missed, duplicate, incomplete |
| Context | What must be known? | Who finds it? | Which account or rule applies? | Files, CRM, memory | Working context | Wrong source, stale data |
| Action | What changes? | Who performs it? | What route is allowed? | Provider or internal system | Draft, update, call, analysis | Provider error, uncertainty |
| Approval | What is consequential? | Who owns the gate? | Approve, edit, reject? | Review surface | Authorized next step | Queue, unclear owner |
| Record | What proves completion? | Who writes it? | Is follow-up needed? | System of record | Durable state | Notes missing, state split |
Do not clean the map while documenting it. The manual workarounds reveal where the business is carrying hidden logic.
Step 3: separate rules from judgment
For every decision, use one of three labels:
- Deterministic: the same valid inputs should produce the same action. Examples include required-field checks, business-hour controls, routing by account and stopping a retry after a terminal disposition.
- Model-assisted: language or unstructured context matters, but the output can be reviewed or constrained. Examples include summarising a call, drafting a support reply or explaining a financial variance.
- Human-owned: the consequence, ambiguity or relationship requires accountable judgment. Examples may include approving spend, changing a financial record, sending sensitive outreach or closing a complex sale.
This classification prevents two opposite design failures: using a model where a rule would be safer, and forcing a person to repeat a decision that could be encoded reliably.
Step 4: score readiness without false precision
The audit should support a decision, not create a mathematical costume for one. Use red, amber or green for each factor and record the reason.
Commercial relevance
- Green: the workflow constrains response time, capacity, delivery quality, margin potential or revenue conversion.
- Amber: the work is useful but the commercial effect is indirect.
- Red: the project is mainly demonstrative or cosmetic.
Frequency and queue pressure
- Green: the same class of work recurs and creates a visible queue.
- Amber: recurrence exists but volume is irregular.
- Red: the task is rare or materially different each time.
Rule clarity
- Green: eligibility, routing, stop conditions and exceptions can be stated.
- Amber: most rules are known but important edge cases remain.
- Red: experienced people disagree on how the work should be done.
Source access
- Green: authoritative records and provider routes are available for a controlled proof.
- Amber: access exists but credentials, ownership or data quality need work.
- Red: the workflow depends on inaccessible, unowned or unreliable data.
Consequence and reversibility
- Green: the first version can be read-only, draft-first or easily reversed.
- Amber: actions are consequential but a clear approval gate is available.
- Red: errors would be material and there is no reliable review or rollback.
Evidence quality
- Green: completion and failure can be observed in retained records.
- Amber: evidence exists but is spread across systems.
- Red: the team cannot tell whether the workflow succeeded without asking the operator.
Adoption ownership
- Green: one named operator owns rollout, exceptions and feedback.
- Amber: leadership supports the work but daily ownership is unclear.
- Red: the project belongs to “the AI team” and no operating user is accountable.
A strong first workflow is mostly green, with amber items that can become explicit launch gates. One red item does not always disqualify the project, but it must be solved in the scope rather than hidden in the promise.
Step 5: draw the human gate before the automation
Do not add “human in the loop” at the end of the diagram. Place the person at the exact decision where authority changes.
Define:
- Trigger: What makes review necessary?
- Owner: Which role receives it?
- Evidence: What can the reviewer see?
- Choices: Approve, edit, reject, request more context or reroute?
- Timeout: What happens if nobody acts?
- Record: Where is the decision retained?
For a read-only finance portal, the gate may sit before any write or external send. For a lead qualification workflow, it may sit when a qualified prospect is transferred to a closer. For recruitment outreach, it may sit before a pilot call or consequential message.
The human gate is not a failure of automation. It is the point where the system hands accountable judgment to the person who owns it.
Step 6: define the smallest production proof
A proof should be narrow enough to understand but real enough to matter. Specify:
- one workflow and one completion condition;
- the real system of record;
- a limited input set or operating period;
- permitted read, draft and write actions;
- the human gate;
- at least three expected failure cases;
- the evidence captured for every run;
- the criterion for expanding, revising or stopping.
Avoid two weak substitutes:
- The sandbox-only demo: visually convincing, but it never encounters real provider state, incomplete data or user behavior.
- The broad pilot: so many workflows enter scope that no one can identify which change produced the result.
The smallest production proof should answer one useful question: can this work item move through the new route under real controls?
Three different first transformations
Linda's Care: response speed and repetitive qualification
Linda's Care had a clear work item: an eligible lead. It had a commercial constraint: fast follow-up. It had repeatable qualification fields, a visible CRM record and a natural human gate at the qualified transfer.
The resulting bridge called, captured structured answers, updated GoHighLevel, governed retries and routed qualified conversations to a human closer. The client reported an $800 deal in the first week. That is an attributed client report, not a promise that the same workflow will create the same result elsewhere.
Plutify: client understanding without write risk
Plutify Bookkeeping had current QuickBooks data but a static client review experience. A read-only CFO portal was a credible first transformation because the system could create value before receiving authority to edit financial records.
The live read path and protected APIs were evidenced. Writes, exports, schedules and sends remained gated. The first production proof improved the review surface while preserving the accounting source of truth.
Care Networks: live administration, staged voice
Care Networks had several provider routes and a potential clinic-calling workflow. The audit did not collapse them into one claim. Recruitment administration and authoritative JobAdder access formed the working lane; voice remained staged behind phone, caller-ID, script, pilot-list and webhook decisions.
This is often the right result of an audit: not “no,” but “this lane first, that lane after its gates are real.”
Step 7: establish the baseline before claiming improvement
Capture the current state using records the business can actually maintain. Depending on the workflow, that may include:
- queue size and age;
- time from arrival to first action;
- completion and exception counts;
- rework or reopened items;
- percentage requiring human intervention;
- missing-data frequency;
- user adoption;
- downstream commercial result, with an explicit attribution method.
Do not invent an hourly saving because a task looks faster in a demo. Do not translate activity into adoption. Do not translate technical deployment into financial return.
If a financial result is client-reported, label it. If a workflow was verified live but routine use was not measured, say so. Precision makes a case more credible, not less impressive.
Observation, inference and evidence
- Observation: The complete 25-case register spans five evidence states: verified live, live with supervision, provider-ready, pilot and built with adoption pending. The most credible first scope changed with access, consequence and evidence.
- Inference: A workflow with a clear completion record and reversible first action is generally easier to prove than a broad “AI employee” mandate.
- Evidence: Deployment states and case claims on this site cite retained documents, live checks or client reports. The audit rubric in this article is RECAST's practical method; it is guidance, not a claim that every business will rank opportunities identically.
A 30-minute audit you can run now
Choose one recurring work item and set a timer.
Minutes 0-5: name the work
Write the trigger, completion condition and proof record.
Minutes 5-15: follow one real example
List every person, tool, decision, copy-paste, wait and exception from arrival to completion.
Minutes 15-20: assign authority
Mark each action as read, draft, recommend, approve, write or send. Circle the first consequential action.
Minutes 20-25: rate readiness
Use red, amber or green for commercial relevance, frequency, rule clarity, source access, reversibility, evidence and adoption ownership.
Minutes 25-30: write the proof scope
Define the smallest real input set, human gate, expected failures and expansion criterion.
At the end, you should have one of three honest conclusions:
- Ready to prove: the workflow is valuable, bounded and observable.
- Prepare first: access, rules or ownership must be resolved before implementation.
- Choose another workflow: the proposed scope is too rare, ambiguous or risky to become the first transformation.
All three conclusions are useful. The audit has prevented the business from automating uncertainty.
Sources
- RECAST,
OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, Linda's Care (page 4), Care Networks (page 9) and Plutify Bookkeeping (page 22). - RECAST,
RECAST_CASE_STUDIES_2026_UPDATED.pdf, Linda's Care (page 2), Care Networks (page 5) and Plutify Bookkeeping (page 18). - NIST AI Risk Management Framework Core - Govern, Map, Measure and Manage functions for lifecycle risk management.
- NIST AI RMF Playbook - voluntary suggested actions supporting the framework's outcomes.
- UK Information Commissioner's Office AI and data protection risk toolkit - practical risk assessment support for organizations using AI systems.
Get your AI blueprint
The free AI audit applies this method to your operation. We identify the first workflow, define the controls and show what a credible proof would require. You receive the verbal plan on the call and a written blueprint afterward. Book your audit.