Map the Workflow Before Buying a Workplace AI Tool

How to Map a Workflow Before Buying an AI Tool

Map one real case from its trigger to an accepted record before comparing AI products. Include the inputs, source authority, decisions, handoffs, exceptions, controls, rework, worker judgment, output, and owner. The map should reveal the constraint the team needs to change, not merely the screen where a vendor wants to appear.

flowchart LR
    A["Trigger and intake"] --> B["Evidence and source authority"]
    B --> C["Human decisions and transformations"]
    C --> D["Handoffs, queues, and exceptions"]
    D --> E["Review and acceptance"]
    E --> F["System of record and downstream work"]
    F --> G["Correction, incident, and feedback"]
    G --> B

Follow a real case

Begin with a recent, representative piece of work. Do not start with an ideal policy diagram or a vendor demonstration.

Ask the person who performed the work to reconstruct what happened. Capture the request, where the evidence came from, what judgment was required, which systems were opened, who waited for whom, what changed, and how the result became accepted.

Use artifacts where permitted: forms, tickets, source documents, messages, calendars, decision logs, templates, and the final record. Observation and artifacts can reveal steps that memory omits.

The official procedure still matters. Mark where actual practice, required policy, and workaround differ. A hidden workaround may be compensating for a broken system, or it may create a risk that should not be automated.

Define the trigger and accepted outcome

The trigger is the event that starts the work. It might be a customer request, meeting end, claim notice, code change, weekly reporting deadline, document arrival, or management decision.

The endpoint is not "AI produced text." It is the point where an accountable person accepts the result and the organization stores or acts on it.

Write the acceptance standard in operational language. An approved project update may require the correct reporting period, milestone status, named owner, decision, blocker, source, and audience. A support ticket may require reproducible steps, expected behavior, observed behavior, environment, evidence, severity, and owner.

Without a stable endpoint, the team cannot compare the current and assisted workflows.

Mark evidence and authority

For each input, record where it came from, who owns it, whether it is authoritative, how fresh it is, who may access it, and whether it can enter the proposed system.

A summary can fail because the source is stale or contradictory, not because the model is weak. AI search can make an overshared or duplicate document easier to find without resolving which record controls.

The NIST AI RMF Core includes system context, requirements, knowledge limits, data, third-party components, human oversight, and affected people. Those fields are easier to answer after the evidence path is visible.

NIST's Privacy Framework adds a lifecycle view of data processing and affected individuals. CISA's secure AI system guidance adds secure design, deployment, and operation questions that should appear at the relevant workflow step.

Separate decisions from transformations

Some steps change format. Others exercise authority or judgment.

Transcribing a recording, extracting dates, converting a template, or grouping similar requests may be a transformation. Deciding whether a contract permits an action, whether an employee met a standard, whether a claim is covered, or whether code is safe to deploy is a decision.

The line is not always clean. A summary decides what to include. A classification can route work and change priority. A generated email can create a commitment if sent.

Mark each step by consequence. Identify who can perform it, which evidence they need, and what happens when it is wrong.

Record handoffs, queues, and wait time

An AI draft may shorten one worker's active time while leaving the process delay untouched.

For every handoff, record the sender, receiver, channel, required context, queue, expected response time, and return path. Separate active effort from elapsed time.

If a report takes two hours to prepare and five days to approve, reducing drafting to one hour may not change the customer outcome. The real constraint may be reviewer capacity, unclear ownership, or competing priority.

Handoffs also create information loss. A downstream reviewer may not receive the source, uncertainty, or reason behind a recommendation. Any AI intervention should preserve the context required for acceptance.

Map exceptions before the happy path wins

Include missing inputs, contradictory records, unclear ownership, access denial, unusual terminology, absent reviewers, urgent cases, accessibility needs, system outage, policy conflict, and a request that should be refused.

Routine work makes a tool look competent. Exceptions reveal whether the workflow can remain controlled.

Ask what people do today when evidence is insufficient. The answer might be clarify, escalate, defer, request another document, use a fallback process, or stop. The AI-assisted path needs the same exit.

Identify controls and worker judgment

Record privacy, security, legal, records, quality, accessibility, safety, employment, financial, and domain controls at the step where they act.

Do not label every control "friction." A required review may prevent a harmful commitment. An access check may protect customer information. A worker may recognize a subtle exception that the procedure never documented.

The people performing the job should review the map. They can identify invisible preparation, emotional labor, coordination, workarounds, peak periods, accessibility needs, and correction burden.

Their input can also reveal when the proposed tool shifts labor instead of removing it. One team may receive faster drafts while another inherits more review.

Find the actual constraint

Once the map is complete, ask where work fails, waits, repeats, or loses evidence.

AI is one candidate intervention. A template, workflow rule, integration, training, staffing decision, or deletion of a bad step may be better.

Episode 97's [[Should This Task Be a Workflow, an Agent, or Manual]] helps choose the mechanism after the work is understood. Episode 109's [[Why AI Integration Is an Operating Model Change, Not a Plug-In]] extends the analysis to ownership and organizational change.

Produce the decision record

The final map should identify the current process, observed evidence, required policy, deviations, constraint, affected people, proposed intervention point, preserved controls, new risks, baseline, owner, and next decision.

Review it with the worker, process owner, data owner, downstream reviewer, and relevant control functions. A diagram approved only by the buyer is incomplete.

Then ask the procurement question: does the proposed product solve the documented constraint under the real data, access, review, and exception conditions?

If the answer is unclear, the team is not ready to buy. That is useful evidence.

This guide was developed with AI assistance from the preserved E019 transcript, the linked workflow record, and current NIST material. Dalton Anderson remains the author. It does not authorize data processing, procurement, workflow automation, employment action, or removal of controls. Worker, policy, privacy, security, accessibility, labor, legal, domain, records, procurement, and founder review may be required. Publication is not authorized.