Automation metrics: assess completed work and its cost

Your automated workflow reports plenty of activity. Files have been processed, tasks started and events recorded. As a business leader, you may still have one unanswered question: did the company complete more usable work, or simply create more activity? A few carefully defined measures help more here than a long list of technical counters.

You need a basis for deciding whether a workflow should continue, receive a targeted improvement or handle a larger workload. Assess completed results, active staff time, error-related rework and allocated costs together. None of these figures alone describes the whole benefit. Fast processing has little value when the resulting work must subsequently be recreated.

This article develops a usable measurement sheet for one bounded automation case: preparing internal service reports. Every quantity, time and amount is hypothetical, and describes neither webRichtung performance nor its prices. The proposed calculation is an operational method for your business, rather than a promise of a built-in financial report.

Count a usable result rather than arbitrary activity

First decide which work outcome you want to count. In the example, it is a service report that the responsible colleague can use without further content correction. A started processing run does not count as a finished report. Multiple attempts on the same report must not become multiple completed results either. Otherwise the measure rewards repetition rather than progress.

Write the completion criterion so that two people judge the same case consistently. “Report processed” might mean only that a file has arrived. “Report usable for the next task” requires an operational definition: the correct case, necessary information present, and no outstanding correction preventing use. The precise requirements depend on the service and the person receiving the report.

Count incoming and open cases alongside completions. Looking only at finished results could hide a growing backlog. Record which cases belong to the group under review and which are still unfinished at the end. An incoming case, a technical event and a usable outcome are three different things. Keeping them separate makes later interpretation much easier.

Visit the cockpit module page to see how webRichtung brings platform metrics and events together, and create your account. Use that overview as a starting point for identifying the outcome that actually matters in your own workflow.

Compare the same work scope and quality requirement

Choose a clearly bounded group of similar cases. A simple standard report is not directly comparable with an extensive special case. If the automation trial includes only easy cases, a better average time may reflect that different work mix alone. Your comparison must make such a difference visible before drawing a conclusion about the process.

Define where the measured step begins and ends. In the example, measurement starts when all agreed input information is available. It ends when the report satisfies the completion criterion. Time spent performing the underlying service is excluded here. If required information is missing, describe that waiting cause separately rather than treating it as a calculation error in the automated step.

Apply the same quality requirement before and after the change. A carefully prepared old report must not be treated as equivalent to unchecked new output. If the trial introduces an extra review, make that visible too. Otherwise, you cannot tell which effort belongs to the workflow itself and which belongs to evaluating the trial.

A small, comparable group can support an initial decision better than a large, mixed monthly total. State the boundary openly and extend the finding only to similar work. The trial should enable a sensible next decision. It does not need to explain every conceivable situation in the entire business on its first run.

Measure active time separately from elapsed time

Active working time describes how long people actually spend on the cases. It includes preparation, review, necessary intervention and later correction. Elapsed time describes the interval between the defined start and the usable outcome. Both can matter, but they answer different management questions and should not be combined into one ambiguous number.

A report may require only a few minutes of staff work and still wait until the next day. The bottleneck could be missing information or the timing of a handover. Conversely, a report handled immediately may finish quickly while consuming substantial staff time. Mixing the two measures makes the cause of delay much harder to identify reliably.

For the initial record, an understandable allocation within your existing workflow is sufficient. Note active time and important waiting periods for each case or clearly bounded batch. Avoid false precision if only rough estimates are available. Mark estimated values and replace them with better observation in the next comparable group instead of treating an early assumption as permanent evidence.

Include the reviewer’s time as well. Automation that saves effort for the author but makes the recipient repeat the same work has not produced the corresponding reduction for the business. For costing, sum the relevant active time of all roles. For elapsed time, do not simply add activities that happened in parallel.

Record error-related rework as a separate effort

Rework starts when an outcome initially fails the agreed completion criterion and needs correction. Distinguish this from a customer’s additional request made later. Both consume time, but their causes differ. A newly requested service should not automatically increase the error rate attributed to the original workflow.

Record the number of affected cases separately from the time spent correcting them. Ten minor corrections may require less effort than one complete rewrite. The case rate shows how often something goes wrong; rework time shows part of the operational consequence. Together they help you prioritise an improvement rather than reacting to the most visible count alone.

Count each corrected report once as an affected case, even if it required two correction steps. Still count all correction time. This rule keeps the rate from changing merely because someone wrote separate notes for each attempt. If correction does not succeed and the report remains open, it has not yet become a usable outcome.

Add a brief reason, such as an incorrect case association or missing required information. You do not need a comprehensive error database. The reason should support the next concrete decision. If almost all rework comes from the same missing input, improving how that information is obtained may be more effective than redesigning the entire automation.

A measurement sheet with a complete worked example

In our hypothetical example, both the old and new process handle 40 comparable service reports. All 40 reach the same completion criterion after any necessary correction. Previously, normal active work takes 360 minutes and error-related rework takes 120 minutes. The total is 480 minutes, or eight hours of staff time.

The new process needs 120 minutes for preparation and regular review. Ten reports additionally need six minutes of correction each, giving 60 minutes of rework. Total active time is therefore 180 minutes, or three hours. After successful correction, each of those ten cases counts once as a usable result, rather than as an extra report.

Both processes use an illustrative internal cost rate of 40 euros per hour. The previous active work costs 320 euros in the calculation. New active work costs 120 euros. We also assume 80 euros of allocated recurring automation costs for the new group. Its total measured cost is therefore 200 euros. The 80-euro assumption is explicitly not a webRichtung price.

The following sheet summarises the basis of the new workflow. Its labels and calculations provide a practical template for your own evaluation. Populate the values from your actual process and cost allocation rather than copying the illustrative figures into a business forecast.

Measure	Example
Usable reports	40
Total active time	180 minutes
Cases with rework	10 of 40
Rework time	60 minutes
Recurring total cost	200 euros
Cost per outcome	5 euros

The rework case rate is ten divided by 40, or 25 percent. Rework’s share of total active time is 60 divided by 180, approximately 33.3 percent. Those figures describe different facts. One quarter of the cases accounts for one third of the human handling time in this example.

Active time per usable report falls from twelve to 4.5 minutes: 480 divided by 40 compared with 180 divided by 40. The recurring cost being measured falls from eight to five euros per outcome: 320 divided by 40 compared with 200 divided by 40. The group has a measured cost difference of 120 euros. That covers the included items and is not a complete profit calculation.

Allocate costs before deciding whether the workflow pays

A recurring improvement must also cover setup. Suppose the one-time preparation costs 600 euros in this example. If volume, quality and cost difference remain unchanged in comparable groups, the 600 euros would be mathematically recovered after five groups saving 120 euros each. This is a scenario calculation, not a promised payback within a particular period.

Establish which costs are actually additional and which existing capacity is being used. Released working time is initially available capacity. It does not automatically produce an equivalent reduction in payroll. The business benefit may be the ability to prepare more reports with the same team or free time for customer work. Identify that use instead of immediately treating every minute as incoming cash.

Allocate shared recurring costs using an understandable rule. If several workflows use the same service, each should not carry the full cost, and none should ignore it completely. A documented allocation can be sufficient for a bounded trial. Keep the same basis in later comparisons or state why it has changed so the result remains interpretable.

Also calculate a version with fewer usable results. If recurring spending stays at 200 euros but only 25 reports finish, the cost becomes eight euros per outcome. The advantage over the previous model’s eight euros has disappeared on this measure. The remaining 15 cases stay visibly open. A higher activity counter would not make up for that gap.

Derive a concrete next action

Before reviewing the sheet, identify the decision at hand. Should the workflow remain unchanged, should a specific error cause be addressed, or should the workload increase? The measures are useful when they help distinguish those actions. A collection of positive figures without a decision can quickly become another reporting obligation for the team.

In the example, cost per outcome is lower, but one third of active time goes into rework. A useful next investigation therefore concerns the causes of those ten cases. If the same missing information recurs, a clearer input requirement might help. After the change, review the affected cause and also check that all required usable outcomes are still being produced.

If open cases increase while active minutes per completed report fall, look at the outstanding workload. Easy tasks may be finishing quickly while difficult ones remain untouched. A general expansion would then be premature. The next decision should account for unfinished cases before sending more incoming work into the same process.

Record the decision, its basis and the next useful review point. Where possible, change the part whose effect you can subsequently understand. If input, quality criterion and cost allocation all change together, the new value becomes hard to compare with the old one. A small, traceable learning step often helps management more than rebuilding the entire measurement system.

Connect platform visibility with your business assessment

webRichtung cockpit brings platform usage metrics and events together in a dashboard. The module page describes a read-only overview: cockpit shows what happened on the platform and does not intervene itself. This provides an entry point for observing workflows without separately collecting information from multiple modules.

Your measurement sheet adds the business meaning of an outcome and the chosen calculation basis. You decide which costs to allocate, how to assess rework and when a service report is actually usable in your process. The financial and time calculations proposed here are not presented as existing automatic cockpit reports. They are the method you use to interpret the operational evidence.

Start with one workflow, one comparable case group and one concrete question. Define completion, active time, rework and costs so a colleague can reproduce the calculation. Then decide what the evidence supports: continue the process, improve an identified cause or expand based on the results. The figures will serve the work your business needs to accomplish.

Explore cockpit for platform metrics and events, and create your account on the module page. Bring your first clearly defined work outcome so that an overview becomes a reasoned decision for your business and a practical next step for the team.