Is this workflow ready for AI?

Score the process, not the pitch

Teams often start with a model or a vendor demo. The more useful first question is whether the workflow can absorb machine help without losing ownership of the result.

AI can draft, classify, propose and sometimes execute. It cannot invent a clear handoff, invent an exception owner or invent a recovery path that does not exist. When those operating facts are vague, the model’s output looks productive while the business still depends on informal judgment that never made it into the design.

Treat readiness as a score against operating facts. Named handoffs. Owned exceptions. Visible state. Defined recovery. Clear authority to approve changes. If you cannot answer those questions for one real process, you are not choosing an AI capability yet—you are still clarifying how the work runs.

This note delivers the TWIMCO AI Workflow Readiness Rubric: five dimensions, three scores each (ready / not yet / blocked), and failure modes we see when teams skip a dimension. Print it, fill it for one workflow and keep the worksheet. Or run the same judgment online with our free AI workflow readiness assessment—eight questions, about three minutes, answers stay in your browser.

Five dimensions that decide readiness

Score each dimension as ready, not yet or blocked. Ready means you could describe the fact to a new teammate without inventing it. Not yet means the fact is known to a few people but not written or shared. Blocked means the process currently depends on ambiguity—no one can name the owner, the evidence or the recovery without arguing.

1. Named handoffs. Who receives work from whom, in what form, and what “accepted” means. Ready: you can point to a concrete transfer (message, ticket, record change) and the next person who acts. Not yet: the transfer happens, but only veterans know where to look. Blocked: work “just gets done” across tools with no agreed receipt.

2. Owned exceptions. Unusual cases already handled by judgment. Ready: the awkward cases have a named person, the evidence they need and a path back to a known state. Not yet: people handle them, but the pattern lives in memory. Blocked: exceptions are treated as noise, or nobody wants the pager for them.

3. Visible state. Operators can tell proposed, in progress, waiting, done and failed apart. Ready: status is observable in the system of record, not only in chat. Not yet: status lives in a spreadsheet someone updates by hand. Blocked: two systems disagree and people reconcile by feel.

4. Recovery. What happens when work stops halfway. Ready: incomplete work is findable, prior steps are known and the next safe action is clear. Not yet: recovery exists as tribal knowledge. Blocked: retrying blindly can duplicate harm, and there is no check-first path.

5. Approval authority. Who may change the process, the prompts, the permissions or the model’s allowed actions. Ready: a named role can approve scope changes and knows what they are signing. Not yet: “the team” decides informally. Blocked: no one will own a change, or everyone can change production behavior without review.

Write one sentence of evidence under each score. Evidence is a handoff name, an exception example, a screen people actually use or a role title—not a hope that AI will figure it out.

How we use the rubric in discovery

In TWIMCO discovery we walk one real workflow with the people who run it. We ask them to narrate an ordinary day and then the last time something went sideways. We listen for unnamed transfers, unspoken exceptions and moments when two people believed different states were true.

The rubric is not a personality test for the company. It is a filter for where AI help is safe to try. A process can be strategically important and still blocked on readiness. In that case the first engineering job is clarifying handoffs, state and ownership—not wiring a model into the fog.

Anonymized pattern we see often: a team wants an agent to “handle follow-ups.” Follow-ups turn out to mean three different handoffs (sales, ops, finance), two exception types that only one person recognizes and a status field that means “done” in one system and “waiting” in another. Until those facts are scored and repaired, an agent amplifies confusion with confident language.

When partnership work continues past a first slice—as with Sutton|Place—readiness questions stay useful. New AI capabilities still need named handoffs into existing deal workflows, owned exceptions when information is incomplete and clear authority for what an agent may change versus what a person must confirm.

Failure modes when you skip a dimension

These failure modes are grounded in delivery-shaped work. They are anonymized composites, not client telemetry.

Handoff skipped. The model drafts messages that sound finished, but nobody agreed who accepts the next step. Work piles in inboxes; “AI saved time” becomes “AI created more triage.”

Exception skipped. The happy path automates cleanly. The first unusual case has nowhere to go, so people invent private workarounds. The automation looks healthy while the real process fragments.

State skipped. The agent reports success based on an accepted API call. The downstream system never confirmed. Operators trust the chat reply more than the record. Recovery starts late and argumentative.

Recovery skipped. Partial failures retry blindly. Duplicate messages, duplicate tickets or duplicate charges appear. Trust collapses faster than the original manual process ever did.

Authority skipped. Prompts, tools and permissions drift because “anyone technical” can edit them. A small change expands agency without a review. When something breaks, no one can say who approved the new scope.

If any dimension scores blocked, do not treat a pilot as proof of readiness. Treat the blocked item as the next design task. AI can wait a week while ownership becomes legible; cleaning up after opaque automation usually cannot.

Worksheet: score one workflow this week

Pick one workflow you are tempted to “add AI to.” Copy the five dimensions. For each, mark ready / not yet / blocked and write one evidence line.

Then apply the decision rule:

• All five ready — a bounded pilot is reasonable. Define the job, the allowed actions and how you will inspect results in the system of record.
• Any not yet — write the missing fact before expanding agency. You can still use AI for drafting or suggestions if a person remains the actor of record.
• Any blocked — stop the AI build for that path. Fix handoff, exception, state, recovery or authority first. Re-score before reconnecting a model.

Keep the filled sheet. It becomes the brief for engineering, the checklist for a pilot review and the argument against vague “AI transformation” scope.

Prefer the interactive path? Use the free AI workflow readiness assessment. It asks eight practical questions about clarity, ownership, examples, measurement, access and recovery, then points you toward observe, define, validate or a controlled first release. Answers stay in your browser; no account and no operational data required.

Put this into practice

If you are deciding whether a process is ready for AI help, bring the workflow—not only the tool shortlist. Trace one handoff, name one exception, show where state lives and say who may approve a change.

Start with the free AI workflow readiness assessment, then bring the weak scores into the conversation.

TWIMCO builds AI applications and agents around operating jobs with clear boundaries. Our ongoing work with Sutton|Place grew from a founder’s operating problem into continued partnership on software, agents and workflows—always with visible state and human authority where consequences matter.

Contact TWIMCO with the process you want to improve and the scores you already know are weak. We can help turn the rubric into a first slice you can stand behind—or tell you plainly what to fix before AI belongs in the path.