Enterprise Workflow, Business Value, and ROI

After this lesson, you will be able to map a customer's workflow from the first trigger to the final outcome, identify points where people lose time or work around a system, and write a value hypothesis that can be tested. You will get a workflow map and a value hypothesis template. NorthPort Freight is fictional, and every detail about its operations is an example, not a claim about a real company.

A customer may ask for an AI assistant, a dashboard, or an integration. Those requests describe possible solutions. To understand what the work is worth, first follow the task through the people and systems involved. A useful map makes it easier to see where the delay or failure occurs, what evidence exists, and which result the customer would value.

Map the work as it happens

A workflow is the sequence of actions people and systems take to reach an outcome. Start with a specific task and its trigger. Follow it until the user or business has the result they need. Keep the map at the level of actual work, including steps that happen in email, a spreadsheet, a phone call, or someone's memory.

For a fictional NorthPort example, a dispatcher notices an order mismatch before assigning a truck. They compare a reference in the ordering system with a reference in the dispatch tool, ask a coordinator to confirm unclear cases, and then decide whether to hold or release the order. The map should record what the people do and which tools they use. It should not begin with an assumption that an AI feature is needed.

GOV.UK's guidance on creating an experience map recommends showing how a person experiences a service over time, including pain points and dependencies. Its guidance is written for public services, but the mapping technique can help a team understand a commercial workflow too. Check the customer's own terminology and process before reusing any example.

A map becomes useful when a person who does the work can correct it. Ask the dispatcher to walk through a recent example, with permission and using approved records. Ask what starts the task, what they look at, what they do when information conflicts, who can approve an exception, and how they know the work is finished. Include another role when a handoff crosses teams. A manager's description may explain a policy; the operator's description shows how the policy works in practice.

Do not fill gaps with a neat process diagram. Mark an unknown when the team has not observed or confirmed a step. Distinguish a written procedure from what people actually do. If a person uses a private spreadsheet because the official tool lacks a needed field, that workaround is part of the current workflow. Record it with care and do not copy personal or sensitive data into a shared map.

Find the points that make work harder

A pain point is a step where the user has trouble completing the task or where the organization sees delay, rework, error, risk, or extra cost. Name the observation before proposing a cause. “The dispatcher checks two screens” is an observation. “The screens are poorly designed” is an explanation that needs evidence.

Look for repeated entry, waiting for another person, unclear ownership, conflicting information, failed handoffs, and cases that leave the normal path. Ask how often each issue occurs and what happens next. One difficult story can reveal a failure mode, but it does not establish how common that failure is. Compare interviews with available records or measurements when the customer permits it.

A workaround can keep the business moving. Removing it may create a new problem if the workaround carries important context or if the official system is not updated. Ask what the workaround protects and who depends on it. A technical change should preserve the useful parts or give the people involved a safe replacement.

Include the business context

Business acumen means understanding how an organization works well enough to connect a technical change to its goals, costs, constraints, and decisions. You do not need to know every department's accounting. You do need to ask which outcome matters, who owns it, what trade-offs they face, and what evidence they use to judge a change.

The person doing the task may value fewer interruptions. A team lead may care about queue age or service commitments. Finance may ask whether operating costs changed. These are different views of value. Write down who will use the result and who can approve the measure before you promise that one metric represents the whole business.

Time-to-value is the time between starting an effort and delivering a result that the customer can use. Agree what counts as usable. A demo can help a team learn, but it may not be an operational result if it uses mock records, skips approvals, or cannot fit the real workflow. A narrow result that a user can safely try may provide earlier evidence than a large build with unresolved dependencies.

Measure a change against a baseline

A baseline is a measurement of the current process before a change. Choose it before rollout, or identify a reliable historical period if you cannot measure prospectively. Record how the measure is defined, where its data comes from, who owns it, and what period it covers. Then use the same definition and collection method after the change. If the definition or source changes, explain that before comparing the results.

GOV.UK's service success guidance recommends identifying measures that indicate whether a service solves its intended problem and tracking performance over time. Its measurement introduction describes using performance data to assess whether people can complete a task and whether the service is cost efficient. These are government service standards and examples, not a mandatory scorecard for every customer. Choose measures that reflect the workflow and the customer's priorities.

For the NorthPort example, possible measures might include time from mismatch detection to a decision, the share of cases sent for manual review, or the number of orders held for clarification. These are candidates, not proven indicators of value. The dispatcher and process owner should decide which one reflects a meaningful outcome. A faster decision could be harmful if the system sends more incorrect orders onward, so pair a speed measure with an accuracy or safety check where that risk applies.

Separate activity from outcome. The number of alerts produced describes system activity. It does not show that dispatchers resolved cases sooner or made better decisions. A measure should answer a decision the team needs to make. If the customer wants fewer delays, define what counts as a delay and where the current evidence is recorded.

Write a value hypothesis

A value hypothesis is a testable statement about how a proposed change may affect an outcome for a particular user. It includes an expected mechanism and a way to check it. For example: “If dispatchers can compare the two approved references in one review step, the process owner expects less time spent switching between systems. We will compare the median review time for eligible cases before and after a limited rollout, while tracking incorrect releases.” This is a hypothesis, not a result. The customer must validate the workflow, access, measure, and acceptable risk.

Return on investment (ROI) compares the value attributed to an investment with its cost. The term sounds precise, but the result depends on what the organization counts as a benefit, which costs it includes, and how it attributes a change. A simple expression is:

ROI = (measured benefit - total cost) / total cost

That expression does not decide what “benefit” means. It may include time saved, fewer rework cases, avoided service costs, or another outcome the customer can measure and value. Costs may include engineering, licenses, infrastructure, training, support, review, and the operational work needed to keep the solution safe. Agree on the categories and time period with the customer before calculating anything. Do not present a hypothetical saving as realized value.

If a credible baseline is unavailable, say so. The next step may be to collect a baseline, run a time-limited pilot, or choose a different measure. A missing baseline is not a reason to make up a number. It is a limitation to include in the decision record.

Copyable templates

Use the workflow map to record what people and systems do today. Keep observations separate from explanations and proposals. “Evidence” can name an approved interview note, procedure, report, or system owner. Avoid putting raw customer records or personal details in the template.

A value hypothesis makes the proposed change reviewable. Complete it with the customer and the people who own the process and measurement. Leave a field unresolved when the team does not yet know the answer.

Mistakes beginners make

1. Mapping the proposed product instead of the current task. Start with a user and a real example, then mark where a change might help.
2. Treating a manager's description as the complete workflow. Ask the people who perform the work and check procedures or records when access permits.
3. Labeling every inconvenience as a business problem. Record the observation and ask who is affected and what consequence follows.
4. Choosing a metric because the system can easily count it. Tie the measure to a user outcome and add a guardrail for likely harms.
5. Comparing a post-change result with a different baseline definition or period. Keep the method consistent or state why comparison is limited.
6. Claiming ROI from a projected benefit. Label projections as assumptions and wait for observed evidence before reporting realized value.
7. Ignoring the people and costs around the software. Include training, review, support, and handoffs when they are part of operating the change.

Recap and try it yourself

Map a task from its trigger through the final outcome. Ask the people doing it to correct the steps, tools, handoffs, workarounds, and pain points. Choose an outcome the customer values, define a baseline, and plan to measure the same thing after a change. A value hypothesis describes what you expect and how to check it; it does not prove the change has worked. ROI depends on agreed benefit and cost definitions, plus evidence the customer accepts.

Try it: use the workflow template to map the fictional NorthPort mismatch review. Mark each item as observed, documented, assumed, or unknown. Then fill the value hypothesis template for one possible improvement. Do not invent baseline values. If the example does not give you enough evidence to complete a field, write the question you would take to the dispatcher or process owner.

Sources

Checked on 5 November 2026. The GOV.UK sources describe public service practice. Adapt their guidance to the customer's setting, policies, and goals.

• Creating an experience map, for mapping a user's experience, pain points, and dependencies.
• Define what success looks like and publish performance data, for defining outcome measures and tracking performance after changes.
• Using performance data to improve your service, for connecting user needs, task completion, cost efficiency, and service measures.