The Cost of Not Solving: Making Process Pain Visible

PathPatron Use-Case Canvas series — 5 of 7

The process map has shown what happens. This next step asks what happens because it continues to happen.

That is not an invitation to build an inflated ROI slide. It is a way to turn a real, mapped pattern—waiting, rework, late control checks, status chasing and constrained expert attention—into an honest decision about whether this pain deserves the next piece of organisational energy.

Continue the same case: the map starts to carry a cost

Return to the supplier onboarding request mapped in the previous article. At 09:07, Procurement receives an incomplete request. Legal later finds the missing clause. Finance sees bank details only the next day and fails a validation check. The business owner asks for a date that nobody can safely promise.

At first, this looks like a small collection of inconveniences. The map changes that. It shows one route returning to Procurement, one queue waiting for Finance and a business dependency held up by an uncertain activation date.

Now add a second layer to the same cards:

• Time: Procurement spends 18 minutes chasing the missing clause; Finance spends 12 minutes locating and rechecking bank data; the requester spends 10 minutes asking for a status update.
• Repeatability: in a sample of 12 recent requests, five arrived incomplete and four required a second Finance check.
• Consequence: the delayed supplier activation moves a project task, but it does not yet prove lost revenue.
• Confidence: the timestamps and sample counts are evidence; the impact on the project plan is a hypothesis for the business owner to validate.

The cost of not solving is not one dramatic number hiding in a spreadsheet. It is an evidence ledger that makes the visible and invisible consequences comparable.

What belongs in the cost picture

Use the map to capture five kinds of cost. Do not force every category into euros. Some should remain a count, a range or a clearly named risk.

1. Direct effort and waiting

Count the work that is genuinely repeated: chasing information, copying data, rechecking, drafting updates and reconstructing status. Keep work time separate from elapsed waiting time. A case that waits three days is not the same as three days of staff cost, but the delay may still block a customer, project or control.

In our procurement case, this means: 18 minutes chasing the missing clause and 12 minutes locating and rechecking bank details: 30 minutes of direct, avoidable cross-functional effort. The separate 10-minute status request is tracked as service friction, not included in the direct-effort proxy. The next-day Finance queue is a delay to record—not 24 hours of staff cost.

2. Rework and quality loss

Look for requests returned, documents rewritten, data re-entered, duplicate checks, escalations and corrections. The important question is not only “how much time?” but what creates the repeat? Missing information, unclear decision rights and inconsistent source material usually deserve attention before automation.

In our procurement case, this means: five of 12 requests arrived without the information Legal needed, and four needed a second Finance check. The repeat is caused by incomplete intake—not by either team working too slowly.

3. Risk and control exposure

Record credible failure modes: an untraceable approval, late detection of incorrect bank details, a missed contractual requirement or inconsistent customer information. Do not price an unlikely incident as if it happens every week. State the failure mode, current control, likelihood evidence and owner who can validate severity.

In our procurement case, this means: bank details reach Finance late enough to trigger a second validation. Record that control exposure and ask the control owner to assess its severity; do not convert it into a recurring incident cost without evidence.

4. Opportunity and service impact

If expert time is absorbed by routine coordination, name the higher-value work displaced. If a delay affects a project milestone or a customer response, name the dependency. Avoid the lazy leap from “time saved” to “revenue created.” Value exists only when the released capacity or faster outcome has a credible use.

In our procurement case, this means: the business owner cannot safely promise a supplier-activation date, so a dependent project task waits. That is a named planning constraint—not yet a claim of lost revenue.

5. Change load—the comparison that comes next

The cost of not solving must eventually be compared with the cost of solving: process redesign, integration, licences, data clean-up, controls, training and ongoing ownership. That comparison belongs in the next future-state article. Here, the job is to make today’s burden credible enough to decide whether the comparison is worth doing.

In our procurement case, this means: do not select a tool yet. First decide whether the evidence justifies modelling options such as a better intake gate, a workflow hand-off or a bounded AI assist—and then include their integration, control and ownership load.

Where to find the information—and who should validate it

Do not ask one manager for “the cost.” The useful evidence is normally distributed across the operating system.

What you need	Likely source	Best validation owner
Case volume, timestamps, queue time and reopen rate	Ticketing, CRM, workflow, inbox or ERP reports	Process owner or operations analyst
Steps, workarounds and hidden review	The people who completed recent cases	Frontline practitioner plus team lead
Cost-rate assumption or salary band	Existing finance/HR planning rates, approved cost bands	Finance partner or HR/people analytics
Errors, exceptions and controls	Audit findings, incident logs, quality reviews, policy records	Risk, compliance or control owner
Project, customer or service consequence	Delivery plan, account notes, service metrics	Business owner or customer/service lead

Start with internal sources of record. Google and AI can help find public benchmarks, interpret a report structure or generate a list of questions—but not establish your organisation’s financial truth. If an external benchmark is used, record the source, geography, date, role definition and why it is only a provisional proxy.

Use proxy values without pretending they are facts

Often the exact data do not exist yet. That should not stop a decision, but it should change the language of the estimate.

For the supplier case, a transparent proxy might look like this:

In the observed sample, an incomplete request creates 30 minutes of avoidable cross-functional effort: 18 minutes of Procurement follow-up and 12 minutes of Finance rechecking. The separate 10-minute status request is tracked as service friction, not included in this proxy. Finance provides an approved planning range of €45–€65 per fully loaded hour for the roles involved. At 40 similar cases per month, the direct-effort proxy is €900–€1,300 per month. This excludes waiting time, project delay and risk; those remain separate evidence lines, not hidden inside the total.

The arithmetic is simple:

avoidable minutes per case ÷ 60 × approved hourly-cost range × monthly affected cases

The discipline is in the labels. Every estimate should carry:

• source: where the observation or rate came from;
• basis: sample size, date range and role definition;
• confidence: observed, proxy or hypothesis;
• exclusions: what is not included;
• validation owner and date: who will confirm, replace or retire it.

Use ranges where the data warrant ranges. A €900–€1,300 direct-effort proxy is stronger than a theatrical €1,127.43. It tells a leader what is known and what still needs checking.

The anti-hype rules: how not to manufacture a business case

Do not make the number larger because a sponsor wants the use case funded. That does not make the initiative easier to approve; it makes the team less credible when the first live cases do not match the slide.

Avoid these traps:

• treating three exceptional cases as the normal monthly volume;
• counting the same delay as both staff cost and revenue loss without evidence;
• converting every minute “saved” into cash value when no capacity will actually be removed or redeployed;
• presenting a public salary benchmark as an approved internal cost rate;
• assuming an AI output removes review, exceptions, monitoring or recovery work;
• hiding uncertainty in a single precise total;
• ignoring the cost and ownership of the change itself.

The right answer may be: the pain is real, but the evidence is not yet strong enough to fund a solution. That is useful. It tells the team what to measure next and protects scarce delivery capacity.

A light-touch evidence session—not automatically another workshop

This does not need to become a recurring room full of sticky notes. Use the lightest format that can validate the uncertainty.

Default: prepare asynchronously, validate the material points

A facilitator or approved AI assistant can create a one-page evidence pack from the Work Map, de-identified case notes and permitted operational reports. It should separate observed evidence, proxy, hypothesis and information gap. Send it to the process owner, finance/contact-rate owner and business owner for short comments. A 20-minute decision check is enough when the route is understood and disagreements are minor.

Use a 45-minute session only when the evidence crosses boundaries

Bring people together—physically or in Mural/Miro—when the cost depends on several teams, a control owner disputes the risk, or an impact is blocked by conflicting views. The task is not to produce a perfect ROI. It is to agree which two or three assumptions matter, who owns validation and whether the case merits future-state modelling.

What AI may prepare, and what people must decide

An approved AI tool may structure notes, calculate an explicitly supplied range, find duplicate observations, draft neutral questions and make the evidence pack readable. It may not invent a rate, infer a regulatory consequence, declare a risk likely, decide which work is avoidable or approve the estimate. Those are stakeholder decisions.

Use this as a locked background. Add the organisation’s cards on top and keep the confidence label visible on every number.

Time	Facilitation move	Tangible output
0–5 min	Reconfirm the single mapped case and the decision it must inform.	Bounded scope; no solution assumed.
5–13 min	Read the evidence ledger: steps, waits, rework and exceptions.	Shared facts and named gaps.
13–22 min	Add direct effort, delay, risk and opportunity cards.	Cost categories without double-counting.
22–31 min	Turn only the credible items into ranges or proxy values.	Sources, exclusions and confidence labels.
31–39 min	Challenge the estimate: normal case or outlier; rate owner; real capacity use; control impact.	Assumptions removed, narrowed or assigned.
39–45 min	Decide: validate further, move to future-state options or stop for now.	Named owners, date and decision record.

Make the evidence ledger a leadership practice

Set up once:

• one short evidence-ledger format attached to material workflow, automation and AI proposals;
• an agreed source directory: which reports, planning rates, service measures and control records are considered usable;
• named validation roles for process, finance, business consequence and control risk;
• a portfolio rule: an estimate cannot become more precise as it travels upward unless its evidence becomes stronger.

Use repeatedly:

• ask for the same five cost categories whenever a candidate reaches a material value or risk threshold;
• compare candidates on the quality of their evidence as well as the apparent size of their pain;
• review the estimates after the first normal cases and the first meaningful exception;
• keep decision records when a team decides not to solve a problem yet.

This is PathPatron’s role in the sequence: not a proprietary ROI model, but a reusable evidence-to-priority practice. The People lens asks whose time, trust or outcome is affected. The Process lens traces where the burden arises. The Power/Techniques lens keeps the eventual intervention and its controls honest.

What this article does not do

It does not approve a budget, promise savings, replace finance modelling or settle whether a specific tool should be bought. It makes the cost of the current state visible enough to earn—or decline—the next decision.

In the next article, the team compares credible future-state options and their cost, control burden and change load. That is where “do nothing,” standardise, automate stable work and add bounded AI assistance can be evaluated honestly against the evidence collected here.

Continue the PathPatron Use-Case Canvas

• 1/7: People, Stakeholders and Targets: Whose Problem Are You Solving?
• 2/7: Map Power, Interest and Pain Before You Pitch AI: The Stakeholder-Pain Map
• 3/7: From Pain Point to a Real Use Case
• 4/7: Map the Work Before You Automate It
• 5/7: The Cost of Not Solving: Making Process Pain Visible — you are here.
• 6/7: From Current State to a Credible Future State: Cost, Control & Change
• 7/7: Requirements Engineering for AI-Enabled Work