PFV-EZ. The 2-Minute Process Check
The elevator ask — two questions, fifteen seconds
How many tickets, changes, or findings are open right now? How many finish in a week? Divide the first by the second — that’s how long each one really takes. Does that cycle time work for your business? If not, the two minutes below show you where the time goes.
Process Flow Visibility · Start here

Where is your process waiting — and what is it costing you?

Most operational risk hides in the time work spends waiting, not working.

PFV finds the days of delay buried inside a process you think takes hours, scores the exposure that delay creates, and tells you what to fix first. Three inputs to start. No login.

01
Where are we waiting?
02
How much risk does that create?
03
What is it costing us?
04
What should we improve first?
The assessment

List the steps. We’ll find the waiting.

Name a process and its steps. For each step, enter the active work time and how long it typically waits before someone picks it up. That’s enough to score your exposure — everything else is optional.

Step Work time (hrs) Wait time (days) Owner Rework % Waits on
These numbers are:

Optional · refines rework, handoff, dependency & cost analysis

Optional, and the number that matters most — what you have promised a customer, an auditor, or an SLA. The result is judged against this, not only against generic bands.
Defaults are the shared PFV bands (30% healthy, 15% floor, after George’s Lean Six Sigma table). Override them if your domain justifies a different standard — the rating then reflects your definition, and says so.
Enter your own — $85/hr is a modelled placeholder. Fully-loaded rate, used for cost of delay & rework.
You measure this; the tool never computes it — 500 is a modelled placeholder, and loading a sample fills in that sample’s modelled figure. How many of these you finish in a year (the same item you counted as ‘open’, as a yearly rate); the cross-check and all costs scale from it.
Your own figure — the suggested number is only a modelled estimate. How many are open at once on a normal day; cross-checks your queue estimate via Little’s Law.
IBM 2025 average is $4.44M. Adjust to your figure.
Verizon DBIR baseline ~30%. The breach-risk figure is a scenario bound, not a forecast.
Off by default. The breach-risk figure appears only when the process is one an attacker would traverse (detection, response, vulnerability remediation). Otherwise the delay is recoverable cost and capacity, not attacker exposure.

Thresholds default to the shared PFV bands (Healthy / Constrained / High Exposure). They are deliberately generic — judge the result against your own SLA expectations.

— productive — end to end — live preview · press the button for the full read
Your result

Operational exposure read

Estimate — unverified inputs · a two-minute read from your entries, not measured logs · what these numbers can support →

The Exposure Score reflects how much of this process is spent waiting — the recoverable time and the window it opens. It is not a breach-probability estimate.

— Exposure /100
—

—

—

— —
active work queue + handoff 25% world-class benchmark
Top delay driver
—
Estimated exposure window
—
Biggest improvement opportunity
—
—

What your results suggest

The numbers behind it

—
PCE
—
Lead time
—
Active work
—
Queue
—
vs 181-day MTTI

Read the exposure framing where this process sits on the attacker’s path — detection, response, vulnerability remediation. For purely operational processes, the same delay is recoverable cost and capacity, not attacker exposure.

Advanced analysis
All depth retained — open what you need.

Cost of delay, rework, and recovered-capacity figures follow directly from the time you entered. The breach-risk figure is a conditional scenario — it holds only where this process sits on the breach path, not for every process.

Want the full worksheet & business case? Ask me →