The Process Cost Dashboard: Four Numbers That Tell You Where the Money Goes

The cost dashboard is the view a small-and-mid-sized business owner or the consultant working with one can put on the table in five minutes to justify an AI transformation project. Four concrete numbers, tied to the actual process, defensible on demand. That is usually what moves the conversation from "interesting idea" to "let's fund the pilot".

Ask a CFO about a business process and they will ask four questions in some order: what does it cost to run once, what does it cost us per month, what is the annual run-rate, and where in the process is the money concentrated. The cost dashboard exists because no single number answers all four, and keeping them in a shared spreadsheet that does not know about the diagram is a recipe for stale data. LucidFlow's dashboard attaches the four numbers directly to the process and recomputes them whenever you edit a KPI.

The four headline numbers: cost per execution, monthly burn rate, annual projection, and top three cost drivers: are not independent. They are different projections of the same KPI data on every task: cost per execution, duration, frequency. Get those three right on every task and the four headlines are automatically correct; get one wrong and the four headlines will tell you exactly which one.

Cost per execution is the sum of every task's cost on a single run of the process. If your process has fifteen tasks and their per-execution costs sum to $47.20, that is the cost to run the process once. This is the number to put in front of a product manager who asks "how much does one signup cost us" or a customer-service lead who asks "what does handling one ticket actually cost". It is the per-unit cost, measured in dollars and cents, rounded to two decimal places.

This number ignores frequency entirely. A task that runs once per execution and costs $5 contributes the same $5 to cost-per-execution as a task that costs $5 whether it ran once or a thousand times. Frequency enters the calculation in the next number. The deliberate design is that cost-per-execution answers a unit-economics question, not a scale question.

Monthly burn rate is the cost of actually running the process at real volume for one month. The formula is precisely: for every task, multiply its per-execution cost by its monthly frequency, then sum across all tasks. A task that costs $2 and runs 500 times per month contributes $1,000 to the burn rate. A task that costs $50 and runs 20 times per month contributes $1,000 to the burn rate. Burn is the number that matters for budget conversations because it is what the process actually consumes in a month, not per hypothetical run.

Frequency normalisation handles mixed units. A task with "5 executions per day" counts as 110 per month (22 business days × 5). A task with "2 per week" counts as roughly 8.66 per month (4.33 weeks × 2). Task frequencies entered in different units combine cleanly because they all collapse to monthly before the burn multiplication.

Annual projection is monthly burn rate multiplied by twelve. It is arithmetically trivial but rhetorically essential: monthly numbers feel manageable ($12,400 per month) while the same process at annual scale ($148,800 per year) is how executives actually think about spend. The dashboard computes it so you never have to do the mental multiplication during a conversation; it also rounds to two decimals so the number is presentable without further formatting.

Annual projection does not model seasonality, growth, or variance, it is a straight-line projection of the current month's burn. If your process has seasonal peaks (a quarterly close, a Black Friday workflow, an enrolment window) the annual projection will systematically understate in high seasons and overstate in low ones. The number is most useful as a current-state budget anchor, not as a forecast.

Top three cost drivers answers "where is the money concentrated on a single run". The dashboard ranks every task by its per-execution cost contribution and returns the top three with their percentage of the total. A typical output looks like: Task A: $18.50 (39%), Task B: $12.00 (25%), Task C: $6.75 (14%). The fourth-through-fifteenth tasks combined contribute the remaining 22%. The concentration ratio tells you a lot: if three tasks are 78% of cost, you have three clear optimisation targets; if they are 35%, the process cost is spread thin and optimisation has to hit many tasks to move the needle.

• Driver ranking is by raw cost, not by (cost × frequency). To see the high-frequency drivers, switch the heatmap to Impact mode.
• Drivers only include tasks with a cost > 0. Tasks with missing cost data do not appear in the ranking: fix the data, not the view.
• Percentages are rounded to the nearest integer for readability, so they may sum to 99% or 101% on small diagrams.
• The dashboard shows exactly three drivers even if the top four are near-tied; click into the cost detail view for the full ranked list.

Alongside the four financial numbers, the dashboard surfaces a single "bottleneck task": defined as the longest-duration task that sits on the critical path. The critical path is LucidFlow's computed longest sequence of dependent tasks through the diagram; a task only counts as a bottleneck if removing or shortening it actually shortens the process cycle time. A long-duration task on a side branch does not count because it runs in parallel with the main flow; a long-duration task on the critical path is where clock-time optimisation pays off.

Bottleneck and top cost driver are different animals. A task can be the bottleneck (longest on critical path) without being a top cost driver (highest per-execution cost); a task can be a top cost driver without being a bottleneck. The dashboard shows both so you do not confuse "expensive" with "slow", they are orthogonal process concerns and need different optimisation strategies.

When you run LucidFlow's Lean Six Sigma optimiser on a process, it produces a second diagram: same shape, different task costs (and sometimes different structure). The cost dashboard, given both diagrams, computes the delta: cost per execution on original minus cost per execution on optimised, and the percentage savings. This is the number to put on the first slide of the optimisation recommendation: "this change saves $18.40 per execution, a 39% reduction, or $22,080 per year at current volume". The three views of the same saving: per-execution, percentage, annualised: make it easy to frame for whichever audience is in the room.

The four numbers are the evidence, not the plan. For an SMB or a consultant preparing a transformation pitch, the dashboard sets the baseline that the AI transformation plan then acts on: which tasks to eliminate, which to automate, which to integrate, ranked by how much of the monthly burn they represent. The dashboard tells you the size of the problem; the transformation plan tells you how to shrink it.