From SOP to Software: How I Map a Manual Process Before Automating It

Observe one real execution

SOPs describe the intended path. Screen recordings, run histories and operator interviews reveal the actual one: the spreadsheet used to repair missing data, the Slack question before approval and the senior employee who knows which vendor name is “close enough.”

Follow one normal case and one difficult case from trigger to completion. Record systems, data copied, active time, waiting time, decisions, workarounds and evidence used.

Define start and done

A process needs a precise trigger and completion state. “Onboard customer” is too broad. “When a deal reaches closed-won with required contract fields, create the approved records and expose unresolved setup tasks to the CSM” is testable.

Also define what is explicitly outside the workflow. Relationship work, negotiation and exceptional policy decisions may remain human even when record provisioning is automated.

Write the process as primitives

Convert narrative steps into trigger, input, lookup, decision, action, exception, approval and completion. Give each data object a source of truth and each decision an owner. Separate a rule from a habit.

For invoice intake, “check invoice” becomes required-field validation, vendor match, purchase-order lookup, arithmetic check, duplicate check and approval assignment. Each now has an observable outcome.

Classify every step

Mark steps deterministic, AI-assisted, human-owned or eliminated. A database lookup is deterministic. Interpreting a messy request may merit AI. Approving payment remains human. Copying a value between systems is eliminated.

This classification prevents “AI” from becoming a blanket over an unclear process. It also exposes policy gaps that software cannot fix.

• Deterministic: known inputs map to rules or exact system operations.

• AI-assisted: language, documents or fuzzy categories need bounded interpretation.

• Human: consequence, relationship or unresolved ambiguity justifies judgment.

• Eliminated: the target process no longer needs the step.

Model exceptions before the happy path hardens

List unavailable API, malformed input, duplicate trigger, invalid model output, rate limit, missing approver and downstream partial success. Decide whether each retries, falls back, pauses, compensates or creates human work.

The exception queue is part of the product. Name its owner, SLA, required evidence and safe resolution actions.

Establish the baseline

Measure monthly volume, minutes, rework, error rate, queue age and cycle time. Distinguish active work from waiting. These numbers determine both architecture and whether a build is worthwhile.

Record ranges and uncertainty. A transparent assumption can be validated; a precise invented number cannot.

Prototype one representative slice

Build one end-to-end path using real-shaped safe data, including one expected failure. Let operators inspect the proposed states and evidence before broad implementation. The goal is to test the process model, not impress with connector count.

After launch, compare against the baseline and inspect where humans still intervene. Expand only when observed economics and reliability support the next workflow.

The deliverable is a shared operating model

A good process map lets an operator recognise the work and an engineer identify contracts, states and failure paths. It gives leadership a measurable boundary and gives the eventual owner a runbook.

Only then should n8n, custom code, Temporal or an AI provider enter the conversation.