The workflow decides whether AI can help

A model cannot repair unclear ownership, conflicting procedures, missing source authority, or a handoff nobody manages. Those conditions have to be surfaced before technology selection.

Starting with the workflow separates problems that may benefit from AI from problems that first need process stabilization, knowledge repair, integration, or training.

Map what actually happens

The useful map follows a real case from trigger to outcome. It records people, systems, documents, waits, approvals, re-entry, exceptions, and the decisions that require judgment.

  • What triggers the work
  • Who owns each decision
  • Which system or document is authoritative
  • Where work waits or returns
  • How exceptions are identified and escalated

Name the operating consequence

A vague goal such as ‘use AI’ cannot guide design. A consequence such as late quotes, inconsistent quality review, slow project status, or preventable rework creates a decision boundary and a basis for measurement.

The consequence also helps leadership decide whether the problem is important enough to fund.

Define the human and system boundary

Once the workflow is visible, leaders can decide what should be standardized, integrated, automated, assisted by AI, or deliberately left to human judgment.

The boundary must include review, escalation, access, auditability, and continuity when a system or output is unavailable.

Model-first and workflow-first are different decisions

A model-first approach begins with a tool and searches for somewhere to use it. Requirements emerge late, and teams can mistake a convincing demonstration for evidence that the operation is ready.

A workflow-first approach begins with a costly operating problem and selects the smallest responsible combination of process, system, integration, automation, AI, and human change needed to improve it.

  • Name the outcome that must improve
  • Map the real work and failure points
  • Identify authoritative information and human judgment
  • Design exceptions and accountability
  • Choose technology against the operating requirement
  • Measure the result against the baseline

Select technology last

Technology selection becomes easier when requirements come from the future-state workflow. The team can compare tools against real source, integration, control, cost, and reliability needs.

The model is then one component in an owned operating design, not the organizing principle for the project.

Trace one quote from request to approved response

This illustrative map describes business coordination, not an automated pricing or engineering decision. Follow one ordinary request and one exception before choosing a tool.

  • Trigger and boundary: a complete quote request arrives; the mapped journey ends when an approved response is ready to send.
  • Source and first handoff: the coordinator checks the current customer requirement and hands the request to the estimator with a case identifier and due date.
  • Decision and authority: the estimator resolves scope; engineering approves technical assumptions; the commercial owner approves the commitment.
  • Exception: two requirement versions disagree. Hold the affected draft, identify the governing version with the source owner and record the resolution.
  • Baseline: record receipt, completeness, assignment and approval times separately. Distinguish hands-on effort from waiting for an answer.

Complete a workflow observation worksheet

For each step, write the trigger, input source, owner, action, output, receiving role, wait reason and exception path. Add the evidence location beside every claimed delay. Do not upload confidential examples to a public form.

Review the map with the people who do the work. If the main delay is an unowned approval, assign the decision first. If people re-enter an agreed field between systems, assess integration. Evaluate AI only where interpretation or retrieval remains useful after those prerequisites are clear.