What is a workflow?

A workflow is a bounded sequence of behaviour through which a person or organisation tries to achieve a meaningful outcome.

That makes it a useful unit for product measurement. It is larger than a click or screen, but more specific than a broad journey such as “becoming a customer”. It gives the team something concrete enough to define, observe and improve.

Examples include:

register for an account
complete checkout
submit a mortgage application
upload the documents required for a decision
choose and set up a subscription
request, compare and accept service quotes

The common thread is not perfect linear progress. It is a recognisable attempt to achieve something.

A workflow needs a purpose and a boundary

A workflow does not decide what the product team should care about. The product question or decision gives measurement its purpose. The workflow provides the behavioural structure needed to design the evidence.

Purpose

Question or decision The understanding or action that makes measurement worthwhile.
User or organisational intent What the person or organisation is trying to achieve, informed by research and context.

Boundary

Entry and eligibility The observable condition and population that begin one workflow instance.
Completion rule The condition and time boundary that count as completion for this question.

Routes

Meaningful steps Actions and state changes that represent progress.
Branches, repeats and hand-offs Optional routes, repeated attempts, multiple roles and offline activity.

Limits

Pauses, exits and blocks Where progress waits, leaves the product or cannot continue.
What the product cannot observe Evidence gaps that require operational data, research or explicit uncertainty.

The map should describe real behaviour. It should not force every workflow into a linear funnel.

This anatomy turns an ambiguous area into something a cross-functional team can discuss without pretending the whole experience is simple.

Workflows are not always funnels

Registration can often be drawn as a sequence. Many important workflows cannot.

A customer requesting service quotes may revise the requirements, wait for providers to respond, receive several quotes in no fixed order, ask questions, arrange an offline visit, receive a revised price and return weeks later to choose. Providers perform their own review and response work. The marketplace can observe only the activity that passes through it.

A workflow can therefore include:

optional steps
repeated attempts
branching routes
long pauses
multiple people or roles
manual or offline activity
completion partly outside the product

The map should describe the behaviour the team needs to understand. It should not force that behaviour into a funnel merely because funnels are easy to chart.

Why workflows are useful for measurement

Many teams measure what is easy to count: page views, sessions, button clicks, downloads and isolated feature usage. Those measures can be useful, but they often describe activity rather than progress.

A workflow changes the question. Instead of asking whether users viewed a registration form, the team asks whether people who started account creation reached the product. Instead of asking how many quotes were sent, the team asks whether service requests attracted enough suitable responses for customers to make a choice.

That shift connects measurement to an outcome the product team can recognise and act on.

Choose workflows deliberately

Not every workflow deserves detailed instrumentation, a dashboard and an operating process.

Prioritise a workflow when one or more of these conditions is true:

an important product decision is blocked by weak evidence
user, service or organisational value depends on the workflow
failure creates meaningful cost, risk or harm
the workflow is changing and the team needs to evaluate it
the current evidence is disputed, incomplete or difficult to explain
several teams need a shared definition of what success means

A low-risk workflow with no current decision may need only a clear definition and a small number of health checks. Measurement effort should follow the value of the decision, not the visibility of the feature.

Name the behaviour, not the interface

Use plain-language verb phrases:

Submit a mortgage application
Request, compare and accept service quotes
Choose and set up a subscription
Register for an account

Avoid labels that are too broad, such as “onboarding” or “engagement”. Avoid labels that are too narrow, such as “click continue”, unless that interaction is the behaviour being investigated.

A useful workflow sits between a broad journey and a tiny interaction. Once that boundary is clear, event and metric design becomes far less ambiguous.