A workflow catalogue is the durable record of the product behaviours a team has decided are important enough to define and maintain.
It is not a list of screens and it is not a backlog of tracking requests. Each item should explain why the workflow matters, where it begins and ends, what one instance represents, which evidence supports it and who is responsible for keeping the definition current.
Toolkit relationship map
Which artefact owns which definition
The catalogues hold durable meaning. A delivery-specific instrumentation specification references them when a product or measurement change must be implemented.
Workflow catalogue
defines behavioural context
-
Owns Purpose, unit, boundary, routes, evidence needs, limitations and stewardship.
Event catalogue
defines observable evidence
-
Owns Claims, fire rules, sources, properties, interpretation limits and validation expectations.
Metric catalogue
defines reusable measures
-
Owns Questions, units, populations, calculations, windows, limitations and owners.
Instrumentation specification
references all three for one change
-
Owns Implementation detail, schema change, rollout, tests, reconciliation and acceptance for a delivery item.
Template and example
Workflow catalogue template
The blank version defines the fields. The filled service-quotes example shows how to handle multiple actors, repeated activity, off-platform evidence and digital completion without forcing the workflow into a funnel.
Blank template
Workflow catalogue item
Define one important workflow, its boundaries and the decisions its measurement should support.
1. Purpose and identity
[Plain-language verb phrase]
Name the behaviour, not the feature, page or team.
[What the team needs to understand]
[What may change once the team has the evidence]
Be specific: monitor, diagnose, evaluate, prioritise, improve, maintain or retire.
[What the person or organisation is trying to achieve]
Ground this in research and context. Do not infer intent from events alone.
[Who participates, and what one workflow instance represents]
Examples: one customer request, one application, one account or one organisation-level plan.
2. Boundaries and routes
[Observable condition that makes an instance eligible]
Define the start for this question rather than relying on a convenient page view.
[Condition that counts as completion for this question]
Separate digital completion from later real-world value where necessary.
[How long an instance has to reach the completion condition]
- [Required step or state change]
- [Optional, repeated or conditional route]
- [Shared or external step]
- [Expected pause or waiting state]
- [Exit, withdrawal or blocked state]
- [Relevant activity the product may not observe]
3. Evidence and metrics
-
[event.name] -
[operational or research evidence]
- [Headline or outcome measure]
- [Diagnostic or guardrail measure]
[What the workflow measurement cannot observe or conclude]
4. Ownership and review
[Person, role or team accountable for the question and use]
[Person, role or team maintaining the workflow definition]
- [Product, policy or service change]
- [Instrumentation or metric change]
- [Confidence, ownership or decision change]
Filled example
Workflow catalogue item: Request, compare and accept service quotes
This example defines a multi-sided workflow without collapsing customers, providers, quotes and jobs into one unit.
1. Purpose and identity
Request, compare and accept service quotes
The name describes the customer outcome rather than a marketplace page or feature.
Can customers publish an eligible request, receive useful choice and accept a suitable quote?
Decide whether to improve request quality, provider coverage, quote comparison, customer-provider communication or the acceptance experience.
The customer wants to find a suitable provider and agree to proceed with a service. Providers want to assess opportunities and submit viable offers.
Customer, one or more providers and the platform. One workflow instance is one eligible service request, not one quote or message.
2. Boundaries and routes
A service request passes eligibility checks and is published to suitable providers.
The customer accepts one valid quote and the acceptance state is persisted.
This is digital workflow completion, not proof that work was scheduled, completed or satisfactory.
Thirty days from request publication for the example completion metric. Recent requests remain incomplete cohorts until the window closes.
- Publish an eligible service request.
- Notify and match suitable providers.
- Receive, revise or withdraw one or more quotes.
- Ask questions, compare offers and arrange any required visit.
- Accept one valid quote or close the request without acceptance.
- Providers may decline, wait for more information or not respond.
- Customers may pause, withdraw the request or reject every quote.
- Telephone calls, site visits and price discussions may happen outside the platform.
- Accepted work may later be cancelled or fail to deliver value.
3. Evidence and metrics
-
service_request.published -
quote.submitted -
quote.revised -
quote.withdrawn -
conversation.message_sent -
quote.accepted -
Customer and provider research -
Operational records about scheduling, cancellation and reported completion
- Quote coverage rate
- Multi-quote coverage rate
- Median and 90th percentile time to first valid quote
- 30-day request acceptance rate
- Reported downstream outcome rate
The platform may not observe off-platform conversations or independently verify completed work. Quote acceptance records a digital agreement, not service quality or customer confidence.
4. Ownership and review
Marketplace product lead accountable for the customer decision and improvement priorities.
Product and analytics representatives maintaining the workflow boundary, units and completion rule.
- Matching, eligibility or quote-comparison changes.
- New provider routes, off-platform integrations or acceptance states.
- Changes to the 30-day window, eligible-request rule or downstream outcome evidence.
- A material loss of confidence in request, quote or acceptance data.
What belongs in the catalogue
Catalogue the workflow when it supports an important decision, outcome, risk or shared definition. The artefact should make five things clear:
- Purpose — the question and decision that make measurement worthwhile.
- Boundary — the eligible entry condition, meaningful routes, completion rule and time window.
- Unit — what one workflow instance represents and which actors may participate.
- Evidence — the events, operational records and research that can support interpretation.
- Stewardship — who owns the use, who maintains the definition and what should trigger review.
A catalogue item does not need every interface interaction. It should be stable enough to survive small product changes while remaining specific enough to guide event and metric design.
Catalogue, workflow map or instrumentation specification?
These artefacts solve different problems.
| Artefact | Main job | Expected lifespan |
|---|---|---|
| Workflow catalogue | Maintains the durable definition and importance of a workflow | As long as the workflow remains relevant |
| Workflow map | Shows the steps, branches, pauses and hand-offs needed for a particular discussion | Updated whenever the workflow or question requires more detail |
| Instrumentation specification | Defines how a specific measurement change will be implemented and tested | Normally tied to a delivery change or release |
The catalogue can link to a more detailed map and to current specifications. It should not absorb all their detail.
Define the unit before linking metrics
The unit is easy to overlook in a simple single-user flow. It becomes essential in marketplaces, applications and organisational products.
For the service-quotes example, one workflow instance is one eligible service request. Several providers may respond, and each may submit or revise several quotes. Counting quotes as workflow instances would reward repeated provider activity even when no additional customer reaches a decision.
State the unit plainly before attaching events or metrics. Useful units might be:
- one account-creation attempt
- one eligible service request
- one application
- one organisation-level plan
- one support case
The unit should match the decision being supported, not whichever identifier is easiest to query.
Keep completion and value separate
The catalogue should state what counts as completion for the selected question. That does not make completion identical to value.
In the service-quotes workflow, quote.accepted is a defensible digital completion point. The product can observe that a customer and provider reached a recorded agreement. It cannot conclude from that event alone that work was scheduled, completed well or valued by the customer.
Make the distinction visible through the completion condition, known limitations and related downstream evidence.
Maintain by trigger, not by habit alone
Review a workflow item when:
- the question or decision changes;
- entry, eligibility, steps or completion rules change;
- a new role, route, hand-off or off-platform dependency appears;
- source events or related metrics change;
- the unit or time window is disputed;
- confidence drops;
- ownership changes;
- the workflow or its measurement should be retired.
A quarterly catalogue review can help, but it should not be the only safeguard. Product changes are stronger triggers than the calendar.
Keep the catalogue selective
Do not catalogue every interaction before the team can use the first item. Start with workflows that carry meaningful value, cost, risk or uncertainty.
A small catalogue that informs decisions is healthier than a comprehensive inventory that nobody trusts. Retire entries when the workflow no longer matters, but preserve enough history to explain which definitions and metrics were valid at a given time.
The catalogue earns its place when another team can understand the workflow boundary, find the relevant evidence and know who to speak to without reconstructing the original project conversation.