Bring the messy workflow, not an AI wish list

Many AI conversations begin at the wrong end. A team arrives with model names, a list of features, and a broad instruction to “find some use cases.” The meeting produces ideas, but not an operating decision.

A better starting point is smaller and more concrete: one workflow that repeats, one handoff that causes friction, and the people who live with the result. The goal of an assessment is not to force AI into that process. It is to determine whether the work is ready for repair, observation, assistance, bounded automation—or no AI at all.

Bring the person who owns the outcome

The workflow owner is not always the person who performs every step. It is the person accountable when the work is late, incomplete, incorrect, or returned. That owner can explain which result matters and which failure would be unacceptable.

Also include at least one person who does the work. Process documents often describe the intended route. Operators know the actual route: the spreadsheet copied from an inbox, the phone call that resolves an exception, and the judgment that never made it into the procedure.

Bring one recent case from beginning to end

A real case is more useful than a polished diagram. Follow the request from the first signal through every queue, person, system, approval, and correction. Mark where information is re-entered, where someone waits, and where a decision depends on context outside the system of record.

Use a completed case when possible. It reveals the result, the recovery work, and the true cycle time. Remove personal or confidential information that is not needed for the assessment.

Bring the exceptions, not only the happy path

The ordinary path may look easy to automate. The operating risk usually lives in the exceptions: missing documents, conflicting records, urgent customers, policy limits, unavailable approvers, and actions that cannot be reversed.

List the conditions that must stop the workflow or route it to a named person. These stop conditions are design inputs. They help define the smallest safe pilot and prevent an attractive demo from becoming an unbounded operating promise.

Bring a baseline you can defend

An assessment needs a starting point. Count volume, elapsed time, touches, rework, escalation, backlog, and the cost of delay where the organization can measure them honestly. If those measures are unavailable, say so and define how a short discovery period will collect them.

The baseline does not need to be sophisticated. It needs to be specific enough to answer a practical question later: did the pilot improve this workflow without moving risk or work somewhere else?

Bring the authority boundary

Name what software may observe, draft, classify, recommend, or execute. Then name what still requires accountable human approval. A customer communication, payment decision, financial commitment, or irreversible update deserves a different boundary than an internal summary.

In workrr Studio, the operating progression is Discover → Shadow → Assist → Bounded Automation. The workflow earns additional authority through evidence. It does not receive authority simply because a model can produce a plausible answer.

Leave with a decision, not a backlog of ideas

A useful first assessment should end with the current workflow map, the measurable problem, the data and authority boundaries, the evaluation set, the stop conditions, and the smallest pilot that can answer the next question. It should also identify the owner and the next review decision.

If the meeting cannot name those outputs, it is still brainstorming. That may be worthwhile, but it is not yet a plan for operational AI.