Validate value / Interactive guide
Value Guide and Simulator
Edit the outlined efficiency and cost assumptions in a fictional process. The report recalculates with the same Value model used in the app.
Value SimulatorThis example is isolated from your saved work. Its prices are illustrative assumptions, not vendor quotes or live research.
Value Simulator: Try a prefilled process
The existing-process example is ready to edit. Use Change path to explore a new process.
Compare the same work
For an existing process, use the same process boundary, period, case volume and accepted-outcome rule for As-Is and To-Be. Adoption divides cases between the proposed design and the retained old route. A new process has no As-Is baseline, so its result shows expected cost and capacity without a savings claim.
Deep Dive
In the example: 100 distinct cases per month Distinct cases per month before adoption. run for 12 months. Adoption sends 80% through To-Be and keeps 20% on As-Is. The same accepted-outcome rule is applied to both routes so the modeled difference is shown only at matching quality or better.
The result is a decision estimate. It is not measured cash saved or a benefit caused solely by AI.
Who owns the inputs?
The process owner defines the case boundary, demand, acceptance rule and adoption. The mapped step owner estimates execution and review time. IT or a tool owner supplies unit rates and license terms. Creation, testing and upkeep contributors supply their hours, frequency and exclusions. Record source, date and uncertainty in a real process.
Deep Dive
In the example: the process owner enters “One approved unique request” as the acceptance definition Define the quality rule for one accepted unique case. The app does not grade outputs.. The step owner enters one minute of human review for the tool-assisted check. The process team owns the illustrative rate and source note.
A blank means unknown and can block a total. Zero means someone explicitly estimated no time, usage or charge.
People, tools and licenses
Production people cost uses the mapped execution and review minutes with their applicable rates. Tool usage uses billable units per visit and the entered rate. Creation, testing and maintenance contributions repeat once or monthly as selected; they do not multiply by cases. New dedicated seats use their full price. An existing shared license uses only its entered allocation, which is process cost rather than necessarily new cash spend.
Deep Dive
In the example: Simulation 2 (S2) uses one billable tool unit per visit Billable units for each visit to this step. at an invented $0.50 process override. Two new seats cost an invented $25 each per month. Creation is 20 hours once, testing is 10 hours once and upkeep is 4 hours monthly.
These are teaching values, not a vendor price, contract finding, rate recommendation or license discovery.
Quality, ranges and model limits
Cost per accepted outcome divides the full lifecycle amount by expected accepted unique outcomes. The low and high views are bounds chosen by you, not statistical confidence intervals. The app does not grade quality, fetch prices, discover private licenses, select a model or measure actual runtime. Summed touch time is not elapsed turnaround: queues, parallel work and rework need their own evidence.
Deep Dive
In the example: To-Be acceptance is 95% Expected share of To-Be cases meeting the quality rule., critical errors are 1%, and 5% of adopted cases need 10 extra person minutes. The planning views use 80–120 monthly cases and 80–120% of base work and usage.
A pilot should verify the quality rule, approvals, permissions, integration behavior, latency, actual billing and exception handling.