Workflow vs process. Different words for different jobs.

The short answer. Scope decides which word is right.

Workflow vs process comes up because the two words get used interchangeably in most offices, and that looseness causes real problems once a team tries to document how work actually happens. A process is the full, end-to-end sequence that delivers a specific business outcome: a customer onboarding process, a procure-to-pay process, a sales process from first enquiry to signed contract. A workflow sits one level down: it is the specific sequence of tasks and handoffs inside a single step of that process, often the part a tool can actually automate. Our wider guide to process mapping covers documenting the whole picture; this piece is about choosing the right word, and the right level of detail, for what you are actually trying to fix.

How they differ. Scope, ownership and what gets automated.

ISO 9000's definition of a process, a set of interrelated activities that transforms inputs into outputs, is deliberately broad, because a process can span several departments, several systems and several days or weeks. A customer onboarding process might run from a signed contract through account setup, a welcome call, training and the first invoice, touching sales, finance, customer success and product along the way. A workflow, by contrast, usually belongs to one team, one system, or even one person: the specific steps that happen when a new lead gets routed to a sales rep, or when an invoice gets approved before it is sent. Business process management exists to manage and improve the whole process; workflow management is the narrower discipline of automating and monitoring the individual task sequences inside it, which is why most workflow automation tools sit inside a single system, a CRM, a help desk, an accounting platform, rather than spanning the entire process end to end.

A concrete way to see the scope difference: a founder-led SaaS company's sales process runs from a marketing-qualified lead through discovery, proposal, negotiation and signature, several weeks, several people, several systems. Inside that same process sits a lead-routing workflow: the moment a new lead arrives, checking territory and rep availability, then assigning it, a sequence that might take four seconds and touches one system, the CRM. Fixing a slow sales process might mean changing who owns a stage, adding a proposal template, or cutting an approval step. Fixing the lead-routing workflow means changing a handful of rules inside the CRM's automation builder. Confusing the two conversations, asking for a "sales process fix" when the actual complaint is a workflow-level routing bug, sends a project down the wrong path before it starts.

Which to use and when. Match the word to the question you're actually asking.

Reach for "process" when the question is about the whole journey: does this customer onboarding process take too long, where does a sales process actually lose deals, is this procure-to-pay process compliant end to end. These are questions about sequence, ownership and outcome across the full span of the work, and they usually need a process map before anything gets fixed. Reach for "workflow" when the question is narrower and closer to a single tool: should this lead-routing workflow assign by territory or by availability, does this invoice-approval workflow need a second sign-off step. A workflow question is usually answerable by looking at one system's automation rules, not by mapping five departments.

I see this confusion most often with founder-led teams who ask for "a workflow diagram" when what they actually need is a process map, or the reverse, who ask us to "map the process" for something that is really one automation rule inside their CRM. A retail operations client once asked for help fixing their order-fulfilment workflow, when the actual problem sat three steps earlier, in a process gap between sales confirming an order and warehouse staff being notified at all. Fixing the workflow they asked about, the pick-and-pack sequence inside the warehouse system, would have improved a step that was not where orders were actually going missing. Mapping the fuller process first showed the gap sat between two systems that did not talk to each other, a problem no single workflow automation could have solved on its own.

How Lauren would decide. Start from where the pain actually is.

My rule of thumb: if the complaint spans more than one team or more than one system, start with a process map, not a workflow diagram, because the fix is likely to be structural rather than a single automation rule. If the complaint is specific to one tool, a CRM stage that keeps getting skipped, an approval that sits in someone's inbox for days, a workflow fix is usually enough, and mapping the whole surrounding process would be more work than the problem needs. Getting this distinction right at the start saves a genuine amount of time: teams that start every fix with a full process-mapping exercise, even for a narrow, single-tool problem, tend to over-invest early and lose momentum before the actual fix ships. Our guides on how to create a process map and what a workflow actually is go into the mechanics of each, once you have decided which one the problem in front of you actually needs.

A quick test before starting either piece of work: can you point to the one tool where the problem lives? If yes, it is almost certainly a workflow. Does fixing it need input from more than one department to agree the change? If yes, it is a process question, whatever word the person asking used first.

Where a workflow or process needs to be written down for others to follow exactly, that documentation becomes a standard operating procedure, a separate document type our SOP work covers, including why SOPs matter even for a single, well-run workflow.

The words are not interchangeable, and using the wrong one at the start of a project tends to scope the wrong piece of work. Ask which level the actual complaint lives at before reaching for either term.