How do you map a workflow before adding Super Intelligence? Start by documenting how the work already moves from trigger to accepted outcome. Record the inputs, people, systems, decisions, waiting, handoffs, exceptions, verification and real-world closure before deciding where machine intelligence belongs.
This article begins Part II of the eduKateSG workplace series: Finding the Right Work for Super Intelligence. The earlier article Where Does Super Intelligence Fit Inside a Workflow? explains possible SI positions after the process is understood. This page owns the prerequisite: how to map the current workflow itself so the organisation does not automate a process it has never actually seen.
The short answer is: Trigger → Intake → Context → Tasks → Decisions → Handoffs → Verification → Action → Closure → Learning. For each state, write what arrives, who owns it, what system holds the authoritative information, how long the step takes, what can go wrong and what proves the work is ready to move forward.
Why Map the Workflow Before Adding SI?
Without a workflow map, teams tend to automate the most visible task. A report appears expensive because writing takes thirty minutes, so they add a writing assistant. The map may reveal that two hours are spent gathering inconsistent updates and resolving missing dates. The true bottleneck is upstream.
A workflow map turns “use AI somewhere” into a diagnosis. It shows where information is lost, where queues grow, where decisions repeat, where employees search, where specialist time is consumed by preparation and where the same correction happens again and again.
A Workflow Is a State-Change System
A workflow moves an object through states. The object might be a customer request, project update, invoice, application, document, support ticket, code change or learning task. The states describe what is true about that object as work progresses.
Mapping the states is stronger than listing job duties because it reveals dependencies. A support case cannot be resolved until identity and entitlement are known. A report cannot be approved until figures are reconciled. A code change cannot be released until tests pass.
Step 1 — Name the Object
What is moving through the workflow? Be concrete. “Customer support” is too broad. “A customer request for a billing correction” is a workable object. “Reporting” is broad. “The weekly project-status pack” is better.
One workflow can contain several objects, but start with the primary one. Mapping becomes confused when the team switches between customer, document and project without noticing.
Step 2 — Name the Trigger
What event creates the work? A message arrives, a form is submitted, a deadline occurs, a record changes, a meeting ends, a customer places an order or an employee requests access.
The trigger should be observable. “When someone thinks we need a report” is not a stable trigger. “Every Thursday at 15:00” or “when the project update form is submitted” is clearer.
Step 3 — Name the Accepted Outcome
What must be true when the workflow is finished? A message was sent and recorded. A payment was approved and settled. A report was accepted. A support case was resolved. A code change reached production and passed monitoring.
Do not define completion as “AI generated an answer”. The accepted outcome should exist in the real work system.
Step 4 — List the States Between Trigger and Outcome
Write the major states in sequence. Do not worry about software notation yet. A line of boxes is enough.
Example: Request received → Customer identified → Account context retrieved → Issue classified → Policy found → Response drafted → Response verified → Response sent → Case recorded → Follow-up monitored → Case closed.
The map becomes more useful when each state describes something observable rather than an activity such as “work on case”.
Step 5 — Identify the Owner of Each State
Who is responsible for moving the object forward? The owner may be a person, team or system. Ownership should not disappear at a handoff.
If everyone assumes another team owns a state, the map has already found a source of delay.
Step 6 — Identify the Systems of Record
For every important fact, note the authoritative system. Customer status may live in CRM. Financial figures may live in accounting software. Project milestones may live in the project system. Code state lives in version control.
This prevents SI from becoming the accidental source of truth simply because it produces readable language.
Step 7 — Identify Context Sources
What additional information does a capable worker need? Policies, examples, history, specifications, previous decisions and current constraints may live outside the system of record.
Mark whether each source is current, owned and accessible. Context problems often appear here.
Step 8 — Identify the Decisions
Mark every point where the workflow chooses a path. Does the case qualify? Is information sufficient? Is approval required? Is the amount above a threshold? Does the request need a specialist?
Separate deterministic decisions from judgment. “Amount above $1,000” can be a rule. “Is this exception commercially sensible?” may require human judgment.
Step 9 — Identify Handoffs
A handoff occurs when responsibility or system changes. Handoffs are common sources of friction because context can be lost and work can wait in queues.
For each handoff, record what the receiver needs: current state, evidence, unresolved issues and next action.
Step 10 — Identify Waiting
Workflows are often dominated by waiting rather than active labour. A report waits for updates. A support case waits for customer information. A purchase waits for approval.
Record queue and wait time separately from active touch time. SI may not reduce the total cycle time if the real bottleneck is waiting for another party.
Step 11 — Identify Search
Mark every point where employees hunt for information. Search is a strong SI and knowledge-management opportunity because repeated retrieval can consume large amounts of invisible time.
Also record whether the search result is trustworthy. Finding information quickly is not useful if nobody knows whether it is current.
Step 12 — Identify Copying and Reformatting
People often move data between systems, turn notes into reports, convert one document format to another or re-enter information. These transitions may be suitable for conventional integration, SI transformation or both.
Do not assume SI is required. If exact fields can move through an API or deterministic automation, use that mechanism.
Step 13 — Identify Verification
Where does the workflow check correctness? A person reviews the report. A formula reconciles figures. A test suite checks code. A policy rule validates eligibility.
Verification is part of the current process even if employees do it informally. Make it visible before redesigning the workflow.
Step 14 — Identify Exceptions
Which cases do not fit the normal path? Missing data, unusual customers, high-value transactions, conflicting records, security concerns and policy exceptions may all require a different route.
Exceptions should be mapped because automation that ignores them tends to fail exactly where consequence is highest.
Step 15 — Identify the Closure Signal
What proves the workflow finished? A status changed, a recipient acknowledged, a record updated, a payment settled or a deployment passed monitoring.
Closure is the anchor for measurement because it separates production from completion.
The Basic Workflow Map
A useful first map can use nine columns: State, Owner, Input, Source, Action, Decision, Output, Wait Time and Failure. Add more only when the workflow needs them.
- State: what is true now?
- Owner: who moves it forward?
- Input: what arrives?
- Source: where does authoritative information come from?
- Action: what work occurs?
- Decision: what route is chosen?
- Output: what leaves the state?
- Wait: how long does work sit?
- Failure: what commonly goes wrong?
Do Not Start With a Perfect Diagram
The purpose of the first map is shared understanding, not visual beauty. A whiteboard, table or simple text sequence is enough. Sophisticated process-modelling notation can come later if the organisation already uses it.
Teams often delay mapping because they imagine a major consulting exercise. Most useful SI pilots need only enough detail to identify the object, states, sources, decisions, handoffs and failure points.
Map What Actually Happens, Not What the SOP Says
Official procedure may differ from real work. Employees may use spreadsheets, private notes, messaging apps or informal workarounds because the documented process is slow or incomplete.
The map should record reality first. Later, the team can decide which workarounds should be removed, formalised or supported.
Interview the People Who Do the Work
Managers may know the official process but not the hidden friction. Ask frontline workers where they wait, search, copy, correct and chase. Ask what they do when the case is unusual.
The most important workflow knowledge is often buried in phrases such as “normally we…” or “unless the customer…”
Observe Real Cases
Memory tends to compress process. Watching several real cases reveals loops, interruptions and exceptions that interviews miss.
Select normal and difficult cases. Record timestamps where practical. The goal is not surveillance; it is to understand the actual operating path.
Separate Active Time From Elapsed Time
Active time is employee effort. Elapsed time includes waiting. Both matter. SI can reduce active time dramatically while leaving elapsed time unchanged if the work still waits for an external approval.
Map both to avoid exaggerated productivity claims.
Separate Rework From New Work
If a downstream team sends an output back for correction, mark that loop. Rework is often a hidden cost caused by poor upstream context or unclear acceptance criteria.
An SI system that produces faster first drafts but increases rework is not necessarily improving the workflow.
Separate Facts From Decisions
A workflow may spend time discovering facts and time deciding what those facts mean. SI can help with both, but the control requirements differ.
Retrieving an account balance is different from deciding whether to waive a fee. Mapping them separately protects authority boundaries.
Separate Rules From Judgment
Explicit rules are good candidates for deterministic software. Judgment involves trade-offs, incomplete evidence, values or context. A workflow map should show the difference before teams delegate decisions to SI.
Separate Production From Approval
Drafting a document and approving it are separate states. Preparing a payment and authorising it are separate states. Generating code and deploying it are separate states.
This separation creates safer intermediate automation options.
Map the Receiver
Every output has a receiver. The receiver may be a customer, manager, system or downstream team. Record what the receiver needs to act.
Receiver effort is a key metric. A faster upstream task can still create more downstream work.
Map the Evidence
For material claims or decisions, note what evidence supports them. A policy passage, database record, calculation, test result or professional judgment may be required.
This becomes the foundation for later SI verification.
Map the Permission Boundary
Record who may view, edit, approve or execute at each state. Existing permissions often reveal where SI action should remain limited.
A system that can read a record need not automatically receive permission to change it.
Map the Exception Owner
Every branch that leaves the normal path should arrive somewhere. Name the person, role or queue. “Escalate” without a destination creates hidden backlog.
Map the Fallback
What happens when the normal system is unavailable? Critical workflows may have a manual or alternate path. Knowing the fallback helps later when SI becomes a dependency.
Map the Learning Loop
Where do recurring errors go? Does a policy owner update documentation? Does the team change a template? Does a software defect become an issue?
A workflow that never learns forces employees to repair the same problem indefinitely.
What This Article Owns
This page owns the current-state workflow map. It teaches how to make existing work visible before adding SI. The earlier workflow-position article asks where SI can fit after the map exists. Later articles will decompose jobs, identify high-leverage use cases and diagnose bottlenecks.
The deletion test is simple: if this page disappeared, the series would lose the method for turning invisible work into an explicit map that can be analysed before automation.
The Workflow Mapping Worksheet
A practical map can be built as a table. Each row is one state or transition. The columns force the team to expose what is usually hidden in memory.
- State: What is true about the work now?
- Owner: Who is responsible for moving it forward?
- Trigger: What causes this state to begin?
- Input: What arrives?
- Source: Where does authoritative information come from?
- Action: What work is performed?
- Decision: What choice changes the route?
- Output: What leaves the state?
- Receiver: Who or what receives it?
- Active time: How much human or system effort occurs?
- Wait time: How long does it sit?
- Verification: How is correctness checked?
- Exception: What conditions break the normal path?
- Permission: What authority is required?
- Failure: What commonly goes wrong?
- Closure: What proves the state completed?
The worksheet is deliberately more operational than a generic process diagram. It creates the variables that later determine whether SI should retrieve, interpret, draft, classify, monitor or act.
Map the Normal Path First
Begin with the most common case. If the first map tries to include every rare exception, it becomes unreadable. Write the ordinary sequence from trigger to closure, then add exception branches.
This creates a stable backbone. Exceptions can be compared with the normal path rather than treated as entirely separate processes.
Then Add the Top Five Exceptions
Ask frontline workers which cases most often break the normal sequence. Missing information, wrong customer identity, policy conflict, high-value transactions, unusual technical errors and manager escalation are common examples.
The first five exceptions usually reveal most of the operational complexity. More can be added later if they materially affect SI design.
Map the Handoff Packet
Every handoff should specify the minimum packet the next person or system needs. A good packet includes current state, evidence, unresolved issues and expected next action.
If the receiver must search email or ask the previous owner what happened, the handoff is incomplete. Handoff friction is often a stronger SI opportunity than the visible production task.
Map the Queue
A queue is where work waits for attention. Note who owns the queue, how items are prioritised, how long they wait and what happens when capacity is exceeded.
Queues matter because automation can move the bottleneck. SI may create drafts faster than reviewers can inspect them. The map should show that review is itself a state with capacity.
Map the Bottleneck
The bottleneck is the state that constrains throughput or creates the largest delay. It may be a scarce specialist, a slow approval, repeated search or missing data.
Do not assume the bottleneck is the step that feels annoying. Use observed wait time, active time, backlog and rework.
Map Rework Loops
When output returns to an earlier state for correction, draw the loop. Rework often reveals unclear acceptance criteria or poor context.
For example, a report may be rewritten several times because the manager expected risks to be prioritised. The problem may not be writing speed; it may be an unstated acceptance standard.
Map Information Loss
Ask what disappears at each handoff. A meeting decision may lose its rationale. A support case may lose customer history. A project update may lose the difference between confirmed and planned dates.
Information-loss points are natural candidates for structured SI handoff packets, but only after the team knows which information matters.
Map Duplicate Work
Look for the same information being entered, reformatted or checked multiple times. Duplicate work may be caused by systems that do not connect, inconsistent formats or a lack of trust in upstream data.
The repair may be API integration, a shared schema or source governance rather than generative AI.
Map Search Friction
Record what people search for, where they search and whether they trust what they find. Repeated search across documents and systems is a strong signal for retrieval or knowledge-base work.
Also map failed search. If employees repeatedly ask colleagues because the formal repository is unreliable, that is a knowledge problem that SI alone cannot solve.
Map Interpretation Work
Interpretation converts raw information into meaning: classify the request, identify the issue, summarise the case, compare the options or detect the anomaly.
This is often where SI creates strong leverage because language and unstructured information are involved. But the map should show what evidence the interpretation uses and what happens when confidence is low.
Map Deterministic Work
Some work follows explicit rules or exact calculations. Mark it separately. This helps the redesign use deterministic software for what deterministic software does best.
A formula, threshold, schema or database rule should not be replaced with model inference simply because SI is present.
Map Judgment Work
Judgment involves trade-offs, incomplete evidence, values, relationships or professional authority. It may remain human-led even after other states are automated.
The map should name the judgment rather than hide it under “review”. For example: decide whether the customer merits an exception, decide whether the evidence supports release, decide whether the recommendation aligns with strategy.
Map Approval Work
Approval should be distinct from preparation. The person who prepares evidence may not be the person who has authority to approve.
This separation later allows SI to automate preparation without accidentally inheriting approval authority.
Map External Actions
External actions change state in another system or affect another person. Send message, issue refund, update record, grant access, publish content, deploy code or schedule event.
Mark whether the action is reversible and what evidence confirms completion.
Map World Return
For each external action, identify the return signal from the real system: message ID, transaction state, deployment status, calendar event or updated record.
This is essential later for agentic workflows because the model’s statement that it acted is not evidence that the external system accepted the change.
Map Permissions
Record the authority required for each state. View, edit, approve, send, deploy, pay, grant access and delete are different permissions.
This map becomes the foundation for least-privilege SI integration.
Map Data Sensitivity
Mark where personal, confidential, privileged or security-sensitive information enters. The workflow may be technically suitable for SI while the data-handling environment is not.
Data sensitivity should influence tool choice, access and logging before integration.
Map Time Sensitivity
Some facts become stale quickly. A policy may remain current for months; inventory or market state may change constantly. Mark which information must be refreshed before action.
This prevents SI from acting on context that was correct earlier in the workflow but stale at execution.
Map Volume
How many cases occur per hour, day or week? Volume determines whether small savings compound and whether review queues can handle automated output.
A workflow that processes ten cases can use manual review differently from one that processes ten thousand.
Map Variability
How similar are the cases? High variability increases the need for interpretation and exceptions. Low variability may favour deterministic automation.
Do not infer variability from anecdotes. Review representative cases.
Map Frequency
Frequency affects return on integration. A task performed every hour may justify connectors and automation. A task performed twice a year may remain better as guided assistance.
Map Consequence
What happens when this state is wrong? A weak internal draft is low consequence. A wrong payment, access decision or safety instruction can be high consequence.
Consequence later determines where verification and human checkpoints belong.
Map Reversibility
Can an error be corrected before harm? Drafts and internal classifications are easy to reverse. Public commitments, destructive actions and privileged access may be much harder.
Reversibility is one of the strongest clues for autonomy design.
Map Review Capacity
If every case needs human review, estimate how many cases reviewers can meaningfully inspect. Review is a resource and can become the new bottleneck.
This calculation prevents teams from creating automation that simply produces a growing approval queue.
Map the Current Baseline
- Total elapsed time from trigger to closure
- Active human touch time
- Number of handoffs
- Wait time by state
- Rework frequency
- Error rate
- Exception rate
- Search time
- Number of systems touched
- Receiver effort
- Cost where measurable
The baseline does not need laboratory precision. It needs enough consistency to compare the redesigned workflow with the current one.
A Swimlane Map
When several roles or systems are involved, use swimlanes. Each lane represents a person, team or system. Move the workflow horizontally through time and vertically across owners.
Swimlanes make handoffs visible. A process that looks simple as a list may cross six teams and four systems.
A State Map
A state map focuses on what is true about the object rather than who performs the action. This is useful for automation because software needs observable conditions.
For example: Unverified request → Verified identity → Eligible case → Draft prepared → Approved → Sent → Closed.
A Decision Map
A decision map focuses on branching logic. It is useful when one workflow contains many conditional routes.
Mark each decision as rule-based, evidence-based judgment or policy exception. This distinction later determines whether code, SI or a human should decide.
A Data-Lineage Map
For information-sensitive workflows, map where each material field comes from and where it goes. This helps identify duplicate entry, stale copies and systems that are incorrectly treated as authoritative.
A Failure Map
Add a failure layer over the normal map. Where can input be missing, source data conflict, a tool fail, review be skipped or action remain uncertain?
The failure map creates the raw material for later exception handling and incident design.
A Control Map
Mark existing controls: approvals, thresholds, tests, reconciliations, access rules, audits and monitoring. SI should fit around these controls rather than silently bypass them.
A Knowledge Map
Mark every document, database and expert source the workflow relies on. Then classify each as authoritative, reference, example or informal.
This prevents a style example from being mistaken for current policy when retrieval is introduced.
Worked Map 1 — Weekly Management Report
Trigger: Thursday reporting deadline. Intake: team updates arrive. Context: current milestones and prior risks. Tasks: normalise updates, compare commitments, identify blockers, draft narrative. Decision: which issues need escalation. Verification: reconcile figures. Action: publish report. Closure: leadership receives accepted report and owners exist for follow-up.
The map often reveals that collecting and reconciling updates consumes more time than writing. SI should therefore target context assembly and comparison before prose generation.
Worked Map 2 — Customer Support Request
Trigger: incoming message. Intake: identify customer and request. Context: account state and policy. Interpretation: classify issue. Decision: routine or exception. Production: prepare response. Verification: check policy and current state. Action: send. Handoff: record case. Closure: customer receives next step and case reaches correct status.
This map reveals several potential SI positions but also shows where authority and live customer state matter.
Worked Map 3 — Supplier Comparison
Trigger: proposals received. Intake: collect documents. Context: procurement requirements. Tasks: extract terms, normalise pricing, compare scope. Decision: shortlist or request clarification. Verification: source-check fields. Action: route decision packet. Closure: authorised procurement decision recorded.
The map often exposes incomparable terms as the real problem. SI can structure the evidence but should not rank before the basis is normalised.
Worked Map 4 — Software Change
Trigger: issue approved. Intake: requirements and repository state. Context: codebase, tests and architecture. Tasks: implement change, generate tests. Verification: automated tests, review and staging. Decision: release or rework. Action: deploy. Closure: production state healthy.
The map makes it easy to separate code generation from merge and deployment authority.
Worked Map 5 — Sales Follow-Up
Trigger: customer meeting ends. Intake: meeting notes and account state. Context: prior commitments, open opportunities, product information and relationship history. Tasks: identify commitments, draft follow-up, create next steps. Decision: whether any commercial promise requires approval. Verification: confirm customer-specific facts. Action: send message and update CRM. Closure: customer receives the agreed next step and CRM reflects the current state.
The map often shows that the difficult part is not email writing. It is reconstructing account context and preserving commitments. SI should therefore help upstream with continuity before the organisation automates sending.
Worked Map 6 — Finance Management Commentary
Trigger: reporting period closes. Intake: approved financial figures. Context: budget, prior period, known business events. Tasks: calculate variances, identify material movements, investigate causes, draft commentary. Decision: which movements require explanation or escalation. Verification: reconcile figures against the source system. Action: publish commentary. Closure: management receives an accepted report whose numbers match the authoritative records.
The map separates deterministic calculation from probabilistic explanation. SI may support interpretation and drafting while financial systems preserve exactness.
Worked Map 7 — Employee Onboarding
Trigger: new employee start date confirmed. Intake: role, manager, location and access needs. Context: policy, systems, training and team responsibilities. Tasks: create access requests, provide learning material, schedule introductions, answer routine questions. Decision: which access or exceptions require approval. Verification: confirm required accounts and training. Closure: employee can perform the core role safely and knows where to find current guidance.
This workflow reveals opportunities for knowledge retrieval and coordination, but also security and access boundaries that should remain governed.
Worked Map 8 — Internal Research Brief
Trigger: management asks a question. Intake: scope, decision, deadline and audience. Context: approved source types and existing internal knowledge. Tasks: search, collect, extract, compare, synthesise and cite. Decision: whether evidence is sufficient. Verification: inspect sources and calculations. Action: deliver brief. Closure: decision-maker receives a traceable synthesis and unresolved uncertainty is visible.
The map prevents a research assistant from becoming an oracle. It makes source quality and uncertainty part of the workflow.
Worked Map 9 — Marketing Content
Trigger: campaign brief approved. Intake: objective, audience, offer and brand constraints. Context: product facts, previous campaigns and current legal or regulatory restrictions. Tasks: generate ideas, draft variants, review claims, select, edit and publish. Decision: which claims or messages are acceptable. Verification: factual and brand review. Closure: approved content is published to the intended channel and performance is tracked.
The map distinguishes creative generation from claim authority and publication rights.
Worked Map 10 — Education Feedback
Trigger: learner submits work. Intake: response, rubric and learning objective. Context: previous errors, curriculum and expected standard. Tasks: identify misconception, classify error, draft feedback and select next practice. Decision: whether the learner needs reteaching or independent practice. Verification: educator checks correctness and fit. Closure: learner receives feedback and demonstrates the target capability later.
The closure signal is learning, not generation. This makes the workflow stronger than a simple feedback-writing task.
Current-State Map vs Target-State Map
Keep the current-state map separate from the target-state design. The current map records reality. The target map shows how the workflow might operate after simplification or SI integration.
Combining them too early creates confirmation bias: teams start describing what they hope the process will become and lose evidence about the actual bottleneck.
The Current-State Map
Document the process as it operates now, including workarounds, informal tools, waiting, rework and exception handling. Do not clean it up for presentation.
The ugliness is useful. It reveals where time, information and responsibility are actually lost.
The Simplified Map
Before adding SI, create a simplified version. Remove steps that no longer need to exist. Standardise formats where ordinary process improvement can solve the problem. Connect deterministic systems where straightforward integration is enough.
This protects the organisation from automating unnecessary work.
The SI-Enabled Target Map
Only after simplification should the team place SI. Mark where machine intelligence retrieves, interprets, drafts, compares, recommends, monitors or acts. Keep human decisions, deterministic checks and systems of record explicit.
The target map should be simpler or more capable than the current map, not merely more technological.
The Pilot Map
Create a pilot version between current and target. It may keep manual approval or manual data transfer while the team tests the cognitive operation. This reduces risk and helps isolate whether SI itself creates value.
A pilot map should be small enough that failures can be traced to a specific transition.
Map the First Weak Link
When a workflow performs poorly, find the earliest state that becomes unreliable. A bad final report may originate in missing input. A wrong response may originate in stale policy. A slow process may originate in a queue several steps before drafting.
Repairing the first weak link prevents downstream automation from polishing symptoms.
Map the First Irreversible Step
Identify the earliest point where error becomes difficult to undo: message sent, payment issued, access granted, contract signed, code deployed or public content published.
This state deserves stronger pre-action verification than earlier reversible preparation steps.
Map the First Human-Judgment Step
Identify where trade-offs, values, professional authority, relationship knowledge or incomplete evidence require judgment. That step may remain human even if surrounding preparation becomes automated.
Naming the judgment prevents the system from inheriting authority by accident.
Map the First Structured Step
Once unstructured input has been interpreted into reliable structured fields, later processing may become easier to automate deterministically. Mapping this boundary helps the team avoid using a language model for every downstream operation.
Map the First Untrusted Input
External messages, documents and websites may contain incorrect or malicious instructions. Mark where untrusted content enters the workflow, especially if agents later receive tool access.
This becomes important for prompt-injection and security design.
Map the First Sensitive-Data State
Mark where personal, confidential, legal, medical, financial or security-sensitive information appears. This state may determine which tools and environments are approved for the workflow.
Map the Last Responsible Human
For consequential actions, identify the last human or governed decision point before the action occurs. The person should have enough evidence and real authority to reject or alter the action.
If the human is present only nominally, the map should show that weakness.
Map the Last Trusted Source
Before action, identify which source provides the authoritative current fact. The workflow should refresh that source if the information can change quickly.
This is particularly important for prices, permissions, account state, inventory and deadlines.
Map the Last Verification Step
Where is the final check before irreversible action? If critical information can change after that point, the verification may be positioned too early.
Map the Failure Recovery Path
When a tool fails, a record is wrong or an action becomes uncertain, where does the workflow go? The recovery path should not depend on improvisation during an incident.
Map rollback, manual fallback and reconciliation where consequence justifies them.
Map the Communication Path
Some workflows fail because people do not know the state of the work. Map who needs status, when they need it and what information should be communicated.
SI can help prepare status updates, but the state itself should come from the workflow rather than from guesswork.
Map the Workload Shape
Volume may be steady, seasonal, bursty or unpredictable. Queue design and review capacity should reflect the real shape.
A reviewer who can handle average volume may still fail during peaks. Mapping workload shape matters before automation increases throughput.
Map the SLA or Expected Time
If the workflow has a service-level expectation or informal deadline, record it by state. This helps reveal which delays actually matter to users.
Reducing a step from ten minutes to one minute has little value if the work then waits two days for approval.
Map the Cost of Error
Estimate consequence by state. Some errors create minor rework; others create customer harm, financial loss, security exposure or legal consequence.
The cost map later informs where human or deterministic controls should sit.
Map the Frequency of Error
High-cost rare errors and low-cost frequent errors require different controls. Record both likelihood and consequence rather than using one generic “risk” label.
Map the Detectability of Error
Some errors are easy to catch before action; others look plausible and remain hidden. Low detectability argues for stronger upstream evidence or lower autonomy.
Map the Reversibility of Error
If a mistake can be corrected with one edit, experimentation is easier. If it creates an irreversible commitment, deployment should be more conservative.
Map the Human Skill Dependency
Record which expertise the workflow relies on. Does a specialist recognise an exception? Does a manager know relationship history? Does an engineer understand architecture?
This reveals which skills must be externalised into context and which must remain human capabilities.
Map Tacit Knowledge
Ask experienced workers what they notice that is not written down. Tacit knowledge may include warning signs, sequencing, exceptions and relationship context.
Not all tacit knowledge can or should be automated. The map should make its existence visible so designers do not assume the system has it.
Map Policy vs Practice
Compare the official SOP with observed work. Where they differ, ask why. The workaround may reveal a broken policy or an unsafe shortcut.
Do not automate either version until the organisation decides which behaviour should become the future standard.
Map Tool Switching
Count how many applications employees move through. Tool switching creates cognitive load and copying errors. Some SI value may come from bringing context together rather than automating the task itself.
Map Authentication and Access Friction
Employees may wait for access, share credentials or create workarounds because permissions are slow. This is a security and process issue that can become worse if agents inherit the workaround.
Map Batch Work
Some tasks are processed in batches because setup cost is high or systems are scheduled. SI may change whether batching remains useful.
Map why the batch exists before converting it into real-time automation.
Map Notifications
Too many notifications can become another queue. Record which alerts matter, who receives them and what action follows.
Monitoring automation should reduce manual checking without creating alert fatigue.
The 30-Minute Workflow Map
- Name one object and outcome.
- Write the trigger.
- List 5–12 major states.
- Name the owner of each state.
- Mark the authoritative source.
- Circle decisions.
- Underline handoffs.
- Star the biggest waits.
- Mark the top three failures.
- Identify the first irreversible action.
- Write the closure signal.
- Choose one bottleneck to investigate.
This map is sufficient for an early SI conversation. It can be deepened only where the proposed redesign requires more detail.
The Half-Day Mapping Workshop
Bring the process owner, two frontline users, one downstream receiver and any technical or governance role required for the workflow. Map a normal case first, then two difficult cases.
Use real examples and timestamps where available. End the workshop with a current-state map, top three bottlenecks, top three failure modes and a short list of candidate improvements. Do not begin the workshop by choosing an AI tool.
The One-Day Evidence Build
After mapping, collect representative artefacts: forms, messages, reports, screenshots, policies, error examples and queue data. These become the evidence pack for redesign.
The evidence pack helps SI builders understand the real inputs and lets reviewers test whether the target workflow preserves necessary information.
The Workflow Interview Questions
- What starts this work?
- What do you need before you can begin?
- Where do you find that information?
- What is hardest to find?
- What do you do that the SOP does not mention?
- Where do cases wait?
- What comes back for correction?
- What types of cases make you stop and ask someone?
- What can you approve yourself?
- What requires another person’s authority?
- What is the most expensive mistake?
- How do you know the work is really finished?
- What do you wish the previous person had included in the handoff?
- What do you check even when nobody asks you to?
- What part of the process would you remove if you could?
The Receiver Interview Questions
- What do you need from the upstream team?
- What is usually missing?
- What makes you ask for clarification?
- What information do you distrust?
- What format is easiest to use?
- What decision or action does this output enable?
- What mistakes create the most rework?
- What proves the upstream work is complete?
Receiver interviews prevent a workflow redesign from optimising the producer while increasing downstream effort.
The Map-to-SI Decision Gate
Once the current-state map exists, classify each state. Remove, simplify, standardise, integrate deterministically, assist with SI, collaborate with SI, automate with SI or keep human-led.
Do not place SI into every state. The map exists to make selective design possible.
Remove
Delete steps that exist only because of legacy habits or duplicate controls that no longer serve a purpose.
Simplify
Reduce unnecessary formats, approvals or handoffs before introducing intelligence.
Standardise
Create common fields, definitions, templates and acceptance criteria where variation adds no value.
Integrate Deterministically
Use APIs, formulas, rules, database logic or ordinary automation for exact and predictable transitions.
Assist With SI
Use SI for local help where the human remains close to the task.
Collaborate With SI
Give SI a meaningful bounded portion of work while the human provides judgment and review.
Automate With SI
Use trigger-based SI where the path is stable, exceptions are known and controls are strong.
Keep Human-Led
Preserve human ownership where trust, values, authority, relationship context or high consequence make it important.
Workflow Mapping Anti-Pattern 1: Drawing Only the Happy Path
A map that ignores exceptions will produce automation that fails on the cases that matter most. Always add at least the most common and most consequential exceptions.
Workflow Mapping Anti-Pattern 2: Mapping Job Descriptions
Job descriptions say what people are responsible for, not how work moves. Map the object and state transitions instead.
Workflow Mapping Anti-Pattern 3: Ignoring Waiting
A process can look efficient if only active steps are recorded. Include queues, approvals and external waits.
Workflow Mapping Anti-Pattern 4: Ignoring Systems of Record
If the map does not show where authoritative facts live, later SI integration can accidentally create parallel truth.
Workflow Mapping Anti-Pattern 5: Treating Every Decision as Judgment
Some decisions are exact rules and should remain deterministic. Separate them from genuine discretionary judgment.
Workflow Mapping Anti-Pattern 6: Treating Every Review as Human
Some verification is better automated through calculations, schemas or tests. Map the error type before assigning the reviewer.
Workflow Mapping Anti-Pattern 7: Optimising One Step
A faster production step can worsen total flow if it overwhelms review or downstream teams. Measure the whole workflow.
Workflow Mapping Anti-Pattern 8: Mapping the Ideal Process
If the current map hides workarounds, the redesign will fail in real use. Document reality first, then design the target.
Workflow Mapping Anti-Pattern 9: No Owner
A beautiful diagram without an accountable process owner will not improve itself. Name who can change the workflow.
Workflow Mapping Anti-Pattern 10: AI Before Diagnosis
Starting with a product feature list biases the map toward places the tool can fit. Start with friction and outcome, then choose the mechanism.
The Mapping Baseline
Before redesign, record enough current metrics to evaluate improvement: elapsed time, touch time, wait time, rework, error, exceptions, queue size and receiver effort.
If exact measurement is expensive, sample representative cases. Approximate evidence is better than no baseline.
The Map Review
Ask one frontline worker and one downstream receiver to challenge the map. They should identify missing steps, hidden context and unrealistic assumptions.
A map that survives this review is usually good enough for early redesign.
The Map Version
Date the current-state map and record the scope. Workflows change. A map used to design automation months later should be checked for drift.
The Map Ownership
The process owner should approve the current-state map even if another team facilitates it. Technical builders should not become accidental owners of business logic simply because they drew the diagram.
The Map as LLM-Readable Documentation
A structured workflow map is useful to both humans and intelligent systems. Stable names for states, owners, sources, decisions and exceptions make later retrieval and automation easier.
This is another reason to prefer explicit definitions over vague prose when documenting operational work.
The Reader’s Mapping Exercise
Choose one repeated task you perform this week. Write the object, trigger, outcome and ten or fewer states. Add owner, source, wait, verification and failure beside each state. Circle the state with the largest queue or repeated correction.
Only then ask where Super Intelligence might help. You may discover that the best intervention is retrieval, a better form, a deterministic integration, a new handoff or no SI at all.
Frequently Asked Questions
How detailed should a workflow map be?
Detailed enough to reveal states, owners, sources, decisions, handoffs, waits, exceptions and closure. Start coarse and deepen only where the redesign requires it.
Do I need BPMN or specialist software?
No. A table, whiteboard or numbered sequence is enough for most early SI work. Use formal notation if your organisation already benefits from it.
Should I map the current process or the ideal process?
Current first. Then simplify and create a target map. Mixing them hides the evidence about real friction.
How many cases should I observe?
Enough to see the normal path and meaningful variation. For a small pilot, several ordinary cases plus difficult exceptions can reveal most hidden steps. Higher-volume or high-risk workflows need more evidence.
What if nobody agrees on the process?
That disagreement is a readiness finding. Do not automate the ambiguity. Resolve ownership, definitions and exception rules first.
What is the most important thing to map?
The state changes and handoffs around the real bottleneck. Those reveal where intelligence, integration or process repair can create leverage.
Should every step receive SI?
No. Remove, simplify and use deterministic software where possible. Use SI only where its cognitive capabilities improve the transition.
How do I map human judgment?
Name the judgment explicitly, identify the evidence it uses and record who has legitimate authority to make it.
How do I map verification?
State which claim or action is checked, which mechanism checks it and what happens when the check fails.
What should I read next?
Continue to How to Break a Job into Tasks SI Can Help With. Workflow mapping shows how work moves; task decomposition shows how to divide the human role into units that can be evaluated for SI fit.
The Core Mapping Rule
Map the work before you map the intelligence. Make the current states, sources, decisions, handoffs, waits, exceptions and closure visible. Simplify what should disappear. Preserve what must remain authoritative. Only then decide where Super Intelligence belongs.
A good workflow map prevents the organisation from automating confusion. It turns SI adoption from a search for impressive tools into a controlled redesign of real work.
How to Choose the Bottleneck From the Map
A workflow can contain many slow steps, but only some constrain the outcome. Compare backlog, wait time, scarce expertise, rework and dependency. The bottleneck is the point whose improvement would most change the throughput or quality of the whole process.
If the bottleneck is a specialist approval, faster drafting upstream may merely increase the queue. If the bottleneck is repeated search, an excellent writing assistant may create little end-to-end value. The map protects the team from improving the wrong step.
Queue Math for Workflow Mapping
Simple queue arithmetic can expose hidden limits. If SI can prepare sixty cases per hour but human review capacity is twenty, the review queue grows by forty cases per hour. No model improvement fixes that arithmetic.
The organisation can narrow eligibility, automate more verification, increase review capacity or keep the process at a lower throughput. Mapping capacity alongside states makes these choices visible before rollout.
Map Arrival Rate and Service Rate
For high-volume workflows, note how quickly cases arrive and how quickly each state can process them. A state whose average service rate is below the arrival rate will accumulate backlog.
This is especially important when automation accelerates one stage. The next stage may become the new constraint.
Map Peak Load
Average volume can hide peaks. Payroll deadlines, admissions windows, incidents, product launches and seasonal demand can create bursts that overwhelm review or exception teams.
Mark the peak load and how the workflow behaves under it. A system that works during quiet periods may fail at exactly the time the organisation needs it most.
Map the Failure Radius
For each state, ask how many people, records or systems one error can affect. A wrong draft may affect one employee. A bad shared source can affect hundreds of workflows. A broad tool permission can change many records.
Failure radius helps determine where stronger controls, staged rollout and monitoring belong.
Map Detection Time
How quickly will the organisation know an error occurred? Some failures are immediate; others remain hidden until a customer complains or an audit detects them.
Slow detection argues for stronger pre-action verification and lower autonomy.
Map Recovery Time
If a failure occurs, how long does it take to restore a safe state? Recovery may require one edit, a rollback, a data reconciliation or specialist investigation.
The product of failure radius, detection delay and recovery difficulty is a useful qualitative signal for how conservative the redesign should be.
Map Dependency Chains
A workflow may depend on several upstream systems: identity, customer data, policy retrieval, a model service and an external tool. Draw the chain when one failure can propagate downstream.
Dependency mapping becomes more important as SI moves from a local assistant into shared infrastructure.
Map the Human Attention Budget
Human attention is finite. Mark where workers must read, decide, check or negotiate. Do not assume every saved production minute can be replaced with review.
A good redesign reduces the amount of attention required per accepted outcome and concentrates attention where human judgment has high value.
Map Cognitive Load
Some states are slow not because they require many minutes but because they require holding many pieces of context in working memory. Comparing proposals, reconstructing a case history or preparing a complex meeting are examples.
SI can create leverage by assembling or structuring context even when total active time appears modest.
Map Coordination Load
Count how many people or teams must coordinate before the state can progress. A process with many small approvals may suffer more from coordination than from any individual task.
The redesign may need fewer handoffs rather than more intelligent processing.
Map Uncertainty
At each state, ask what is unknown and whether the workflow must resolve it. Some uncertainty can remain visible; other uncertainty blocks action.
SI systems should not be designed to eliminate uncertainty rhetorically. The map should show where abstention or escalation is a valid result.
Map Assumptions
Write the material assumptions that workers use: all figures are in the same currency, the policy version is current, the customer is the account owner, the requested date means calendar days.
Hidden assumptions are common causes of disagreement between humans and SI. Making them visible improves both workflow design and later prompting.
Map Definitions
Different departments may use the same word differently. “Active customer”, “urgent”, “approved”, “complete” or “high risk” may have local meanings.
Record operational definitions so SI does not have to infer them from general language.
Map Thresholds
Many workflows change route at thresholds: amount, risk score, deadline, confidence, customer tier or number of failed attempts.
Explicit thresholds are often better implemented deterministically. Mapping them prevents vague model judgment from replacing known rules.
Map Escalation Thresholds
Separately record when the system must stop normal processing and send the case to a person. Escalation thresholds may be based on missing evidence, high consequence, conflicting sources or tool failure.
Map Currentness Requirements
For every time-sensitive fact, record how fresh it must be at the moment of use. The required freshness for a policy may differ from inventory, customer entitlement or market price.
This becomes a design requirement for retrieval and pre-action refresh.
Map Evidence Provenance
Where did each material claim originate? A ready workflow can trace the report figure, contract clause, customer status or research claim back to a source.
Provenance mapping is especially important if SI will later synthesise several sources.
Map Structured and Unstructured Inputs
Separate natural-language documents and messages from structured fields. SI is often strongest on unstructured interpretation, while deterministic systems are strongest on structured validation and state.
The map helps designers combine the two rather than forcing one technology to do everything.
Map the System Boundary
Decide where the workflow begins and ends for the current analysis. A customer journey can be enormous; a pilot may map only the billing-correction path.
A clear boundary keeps the map useful while preserving interfaces to upstream and downstream processes.
Map Upstream Quality
If inputs are poor, later intelligence inherits the problem. Record missing fields, inconsistent formats and stale data at the boundary.
Sometimes the best SI project is upstream intake improvement rather than downstream generation.
Map Downstream Requirements
Ask what the next system or person requires. A structured downstream API may need exact fields; a manager may need risks and recommendations; a customer may need a clear promise.
The output format should serve the receiver rather than reflect what the model prefers to generate.
Worked Map 11 — Access Request
Trigger: employee requests access. Intake: identity, role and resource. Context: policy, manager, current permissions. Decision: eligible, needs approval or prohibited. Verification: confirm identity and requested scope. Action: grant access. Closure: system-of-record shows permission and requester receives confirmation.
The map reveals why SI can help classify and prepare evidence but should not automatically inherit privileged authority.
Worked Map 12 — Incident Communication
Trigger: material incident declared. Intake: affected services and initial evidence. Context: logs, customer impact and incident owner. Tasks: build timeline, separate confirmed facts from hypotheses, draft updates. Decision: what is safe to publish. Verification: incident lead confirms current facts. Action: communicate. Closure: stakeholders receive the approved update and next update time is recorded.
The map separates fast drafting from factual authority.
Worked Map 13 — Hiring Administration
Trigger: role approved. Intake: job criteria and applications. Context: hiring policy and schedule. Tasks: organise applications, schedule interviews, prepare notes. Decision: selection remains under authorised human process. Verification: candidate data and criteria. Closure: decision and communication are recorded.
The map reveals where SI can reduce administration without becoming the unexamined decision-maker.
Worked Map 14 — Contract Intake
Trigger: new agreement received. Intake: parties, document and business owner. Context: standard template, playbook and current legal requirements. Tasks: extract changed clauses, compare with standard, prepare issue list. Decision: which deviations require legal or commercial approval. Closure: authorised decision recorded and final version stored.
The map keeps clause processing separate from legal authority.
Worked Map 15 — Marketing Campaign
Trigger: campaign objective approved. Intake: audience, offer, channels and budget. Context: product facts, brand rules and prior evidence. Tasks: research, concept generation, drafting, claim review, asset preparation. Decision: which creative and claims are approved. Closure: campaign is published and performance feedback enters the next cycle.
The map shows where generative breadth is useful and where factual and brand controls belong.
Worked Map 16 — Student Learning Recovery
Trigger: assessment reveals a misconception. Intake: learner response and rubric. Context: prerequisite skills, previous errors and curriculum. Tasks: diagnose error, choose explanation, assign practice, retest. Decision: ready to progress or needs repair. Closure: learner demonstrates the target skill independently.
The map keeps the outcome anchored to learning rather than generated material.
The Workflow Map and Super Intelligence Readiness
A current-state map is one of the strongest readiness artefacts because it exposes whether the organisation understands its own work. If states, sources and owners cannot be named, deeper integration should wait.
Use the Super Intelligence-Ready Workplace article to assess the wider organisational conditions around the map.
The Workflow Map and Delegation Boundaries
The map makes high-consequence states visible. Mark where rights, money, security, safety or irreversible actions occur. Those states deserve stronger controls and may remain human-authorised even when upstream tasks are automated.
Use What Work Should Never Be Delegated Blindly to Super Intelligence? for the boundary framework.
The Workflow Map and Integration
Once the current process is visible, the team can decide which repeated context, tools and handoffs deserve integration. Do not connect systems before the map proves that manual transfer is a real bottleneck.
Use From AI Tools to Super Intelligence Systems for the integration stack.
The Workflow Map and the Four Levels
The same map can support Assist, Collaborate, Automate or Operate. The level changes how much of the sequence SI can perform without direct initiation; it does not change the need to understand the states.
Use The Four Levels of Workplace Super Intelligence for the autonomy model.
Map Update Triggers
- The workflow gains a new system or data source.
- A policy or regulation changes.
- A model or tool changes materially.
- Permission boundaries change.
- A new case type enters the workflow.
- Exception volume rises.
- An incident exposes an unknown path.
- Ownership changes.
- The business outcome changes.
- The current map no longer matches observed work.
A workflow map is a maintained artefact, not a museum diagram.
The Mapping Governance Rule
The process owner should approve the business logic in the map. Technical teams can facilitate, instrument and implement, but they should not become accidental policy owners because they built the automation.
The Mapping Data Rule
Map only the data the workflow actually needs. Do not assume SI should receive every available field. Data minimisation improves privacy, security and often relevance.
The Mapping Security Rule
Mark untrusted content, privileged actions and secret-bearing states. These become design inputs for prompt-injection defences, sandboxing and least privilege.
The Mapping Measurement Rule
Every target map should predict what metric will change and why. If no outcome, latency, quality, capacity or risk variable is expected to improve, the redesign may not be worth doing.
The Mapping Simplicity Rule
A target map should normally remove friction or expand capability. If it introduces more states, more handoffs and more monitoring than the old process, ask whether the complexity pays for itself.
The Final Workflow Mapping Checklist
- Primary work object is named.
- Trigger is observable.
- Accepted outcome is explicit.
- Normal states are mapped.
- Top exceptions are mapped.
- Owners are named.
- Systems of record are identified.
- Context sources are classified.
- Decisions are separated into rules and judgment.
- Handoffs and receiver needs are visible.
- Wait time and active time are separated.
- Rework loops are shown.
- Search and copying friction are marked.
- Verification is explicit.
- Permissions and sensitive data are marked.
- First irreversible action is identified.
- World-return signal is defined.
- Fallback and recovery are known.
- Baseline metrics exist.
- Process owner has reviewed the map.
If the checklist is mostly complete, the workflow is ready for the next Part II question: how to break the work into tasks and decide which tasks actually fit SI.
The Mapping Rule in One Sentence
Do not automate the story people tell about the workflow; automate only after you have mapped the states the work actually passes through.
When the map is accurate, SI opportunities become much easier to see. The organisation can remove unnecessary steps, preserve authoritative systems, protect human judgment and place machine intelligence exactly where it changes the outcome.
The Map Should Show the Difference Between Current and Target Work
Before approving a new design, compare the current map and the proposed map state by state. Which manual search disappears? Which handoff becomes structured? Which decision remains human? Which new verification appears? Which queue moves? The comparison should explain the mechanism of improvement.
A useful redesign normally contains several categories at once: some steps are removed, some simplified, some connected through ordinary software, some supported by Super Intelligence, and some deliberately preserved as human judgment.
Removed steps
Delete work that exists only because of legacy duplication, obsolete approvals or repeated copying. SI should not preserve unnecessary work merely because it can perform it faster.
Simplified steps
Standardise formats, definitions and acceptance criteria where variation creates no value. Better structure often improves the workflow before any model is added.
Connected steps
Where exact data must move between systems, ordinary integration may be better than generative processing. Use reliable software for reliable transfer.
SI-supported steps
Use SI where interpretation, retrieval, comparison, drafting or explanation genuinely reduces cognitive effort.
Human-preserved steps
Keep human ownership where trust, context, negotiation, responsibility or institutional judgment is central to the outcome.
The Map Should Preserve Good Existing Controls
A redesign does not start from zero. Existing approval thresholds, test suites, reconciliations, access rules, quality checks and source-of-record systems may already be strong. Mark them clearly so the SI project does not remove useful control by accident.
The best target workflow often combines existing deterministic controls with new machine intelligence rather than replacing everything with one model.
The Map Should Reveal New Dependencies
A target workflow may remove manual effort while creating new dependencies on model availability, retrieval quality, connectors, review queues or shared services. Add those dependencies to the target map so the organisation can plan support and continuity.
A system is not automatically better because it contains fewer human steps. It is better when the total workflow becomes more useful, reliable or efficient.
The Map Should Include a Rollback State
For important workflows, identify the safe state the process can return to when the target design is unavailable or unreliable. This may be a manual queue, a previous workflow, read-only mode or a review-all mode.
Rollback is easier to design while the current process is still understood. Once the old path disappears completely, recovery may become harder.
The Map Should Include a Promotion Gate
Write what evidence is required before the workflow gains more autonomy. The gate may include representative case volume, acceptable correction rates, stable exception handling, sufficient review capacity and successful testing after tool or source changes.
Promotion gates prevent autonomy from expanding informally just because users become comfortable with the system.
The Map Should Include a Demotion Gate
Also define what reduces autonomy: rising errors, stale knowledge, overloaded review, changed permissions, major system updates or a process change. Moving back toward greater human control is an ordinary operating decision, not a failure.
Frequently Asked Questions About Workflow Mapping
Should every task be mapped before using SI?
No. One-off, low-risk personal tasks may not justify formal mapping. Map repeated or consequential work when the surrounding handoffs, sources and decisions determine whether SI creates real value.
How detailed should the first map be?
Usually five to fifteen major states are enough. Begin coarse, then deepen only the transitions relevant to the redesign.
Who should build the map?
The process owner should sponsor it, frontline workers should describe real operations, downstream receivers should challenge handoffs, and technical teams should identify systems and data. No single role sees the whole workflow.
What if nobody agrees on how the process works?
That disagreement is itself a finding. Resolve definitions, ownership and exceptions before deep automation.
How do I know the map is good enough?
The team can explain the normal path, major exceptions, sources, owners, bottleneck, verification, decision points and completion state well enough to make the next design choice.
What comes after mapping?
Continue to How to Break a Job into Tasks SI Can Help With. Workflow mapping shows how work moves; task decomposition shows which cognitive units inside the workflow are suitable for SI.
The Final Map-to-SI Gate
Before placing SI, the team should be able to say: this is the object, this is the trigger, these are the states, these are the authoritative sources, this is the bottleneck, these decisions are rules, these decisions are judgment, these exceptions have owners and this is how completion is proven.
If those statements are available, the SI design can be selective and testable. If they are missing, the next task is still process discovery.
The Final Mapping Principle
The workflow map is the control surface between human intent and machine action. It makes hidden work visible enough to simplify, measure and redesign. It protects the organisation from treating a model as the workflow and from measuring generated output as if it were completed work.
Map first. Remove what should disappear. Standardise what should be stable. Preserve what must remain authoritative. Then add Super Intelligence only to the transitions where its capabilities change the outcome.
The Workflow Map Review Meeting
Before the map becomes the basis for an SI project, hold one review with four perspectives: the process owner, a frontline operator, a downstream receiver and the technical or governance role relevant to the proposed change. Their job is not to approve the diagram politely. Their job is to find the parts that do not match reality.
The process owner checks whether the map reflects the intended outcome and decision rights. The frontline operator checks the hidden work: searching, copying, waiting, workarounds and exceptions. The downstream receiver checks whether the handoff contains what is actually needed. The technical or governance participant checks sources, systems, permissions and controls.
A map that survives these four perspectives is usually strong enough for a bounded SI pilot. A map that triggers disagreement has already created value because the organisation has found ambiguity before automating it.
The Three Questions Before SI Enters
- What is the real bottleneck? Identify the state whose improvement would change the whole workflow rather than one local task.
- What mechanism fixes it? Remove, simplify, standardise, integrate deterministically, retrieve with SI, generate with SI, automate or keep human-led.
- What evidence would prove improvement? Name the metric and the return signal before deployment.
These questions prevent a workflow map from becoming documentation for its own sake. The map exists to support a better operating decision.
The Workflow Evidence Pack
Keep the artefacts used to build the map: representative inputs, accepted outputs, policy documents, screenshots, error examples, queue data and several exception cases. These materials become the test set for later redesign.
If an SI builder sees only the diagram, they may miss the language, ambiguity and edge cases that make the real workflow difficult. The evidence pack preserves operational texture.
The Map Quality Tests
- Substitution test: Can another authorised employee follow the map and understand the process?
- Receiver test: Does the downstream user agree that the mapped handoff reflects what they need?
- Exception test: Do the common difficult cases have a visible route?
- Authority test: Are preparation, decision, approval and action separated where needed?
- Source test: Can important facts be traced to an authoritative system or document?
- Closure test: Does the map end in an observable real-world state rather than a generated artefact?
- Measurement test: Can the team identify what should improve if the redesign works?
- Simplicity test: Would ordinary process improvement solve the bottleneck more cleanly than SI?
A map does not have to pass every test perfectly before experimentation. The tests identify which uncertainties belong inside the pilot and which weaknesses must be repaired first.
The Map Refresh Rule
Refresh the map when the process, policy, source system, ownership, model, permissions or exception pattern changes materially. A workflow map can become stale just like a policy document.
For important automated workflows, the map should be reviewed after incidents or repeated exceptions because those events often reveal states that the original design omitted.
The Mapping Rule for Scale
Do not scale a workflow from one team to another until the receiving team maps its own current state. The labels may match while the operating conditions differ. Two departments can both have a “weekly report” while using different sources, approval rules, receivers and consequences.
Transfer the mechanism—such as structured retrieval or exception routing—only after the new map shows that the same mechanism fits.
The Final Workflow-Mapping Return
A completed map should return the team to a concrete decision: which step should be removed, simplified, connected, assisted, automated or preserved as human judgment? If the map does not make that decision easier, deepen the bottleneck and receiver analysis rather than adding more boxes.
The purpose of mapping is not to describe work beautifully. It is to make the next operating choice testable. Once that choice is visible, the workplace can move into task decomposition without confusing jobs, tools and workflows.