Measure the same workflow boundary before and after a change. Define its trigger, completion, review period and exceptions, then track elapsed time, hands-on effort, errors and rework separately. Compare similar cases and document other changes. An automated run count is useful for operations, but it does not prove time savings or a business outcome.
- Define start eventChoose the workflow event that starts measurement.
- Define included casesState records, incomplete cases, and supporting observations.
- Define completionState the expected end result.
- Reuse the boundaryMeasure the changed process using the same definition.
Different definitions of onboarding time produce different measures.
Define what you are measuring
Choose the start and end events of the workflow. “Onboarding time” could mean accepted proposal to kickoff, form submission to project creation or first inquiry to a ready delivery team. Those are different measures.
Write the definition before collecting a baseline. Identify which records are included, how incomplete cases are handled and which dates or observations support the measure. Use the same boundary when evaluating the changed process.
Keep different measures separate
| Measure | What it describes | Important distinction |
|---|---|---|
| Elapsed time | Time between defined start and completion | Includes waiting |
| Hands-on effort | Time people spend performing the work | Requires an actual effort record |
| Completion | Cases reaching the expected result | Define what counts as done |
| Exceptions | Cases requiring recovery or clarification | Include manual rescues |
| Rework | Work repeated to correct a result | Can offset apparent speed |
| Business outcome | Qualified call, retained client or other goal | Has influences beyond the workflow |
Do not subtract elapsed time and call the difference labor saved. A day spent waiting for a client is not a day of staff effort.
- Elapsed timeMeasure defined start to completion, including waiting.
- Hands-on effortUse actual records of staff effort.
- Exceptions and reworkInclude manual rescues and repeated corrective work.
- Business outcomeKeep broader outcomes separate from workflow activity.
Elapsed waiting time is not automatically labor saved.
Collect a usable baseline
Review a representative set of cases under the current process. Record the source and any missing information. If timestamps are unreliable, say so and improve collection before making a strong comparison.
For an illustrative approval workflow, collect the date a version was ready, when review was requested, when feedback arrived and when the final decision was recorded. This shows whether delay occurs in agency preparation, client review or revision. One total duration hides those differences.
Use observations your team can maintain. A complex measurement sheet that nobody updates will not produce a reliable baseline.
Compare similar work
Account for differences in project type, complexity, client responsiveness and team availability. A small engagement before the change and a complicated engagement afterward do not isolate the effect of automation.
- Project complexityAccount for different project types and complexity.
- Client responsivenessAccount for different response patterns.
- Team availabilityAccount for staffing differences.
- Other changesDocument revised forms, owners, or integrations.
Report combined operational change when several changes occurred together.
Document other changes introduced at the same time. A revised intake form, a new owner and a new integration may together improve the result. You can report the combined operational change without claiming that one tool caused all of it.
Include the cost of exceptions
Track failed runs, corrections, duplicate work and time spent maintaining the workflow. Automatic steps that save routine effort can still create substantial repair work when inputs are inconsistent.
- Failed runsRecord technical failures requiring recovery.
- CorrectionsRecord work correcting incomplete or incorrect results.
- Duplicate workRecord duplicated records or repeated activity.
- Workflow maintenanceRecord effort needed to maintain the workflow.
Routine automatic steps can still create substantial repair work.
The exception handling guide gives each recovery a record and owner. That record can support measurement, provided it captures actual events rather than assumptions about what probably happened.
Use results to choose the next improvement
Look for the largest unresolved source of delay or rework within the defined workflow. If client decisions remain the main blocker, adding another automatic internal task may have little effect on completion time.
Report the measure, period, included cases and known limitations together. A comparison can be useful without a dramatic percentage. The purpose is to understand whether the process produces more reliable work and where to act next, rather than to justify a technology choice after the fact.
Questions and answers
How do we calculate time saved by agency automation?
Define the workflow boundary and collect actual hands-on effort before and after the change, including exceptions and maintenance. Keep that separate from elapsed time. Without comparable observations, treat savings as a hypothesis rather than a measured result.
Are successful run counts a useful measure?
They show activity in the tool. Pair them with the expected business result, completion, errors and rework. A successful technical run can still produce an incomplete or duplicated record, so run volume alone does not establish operational value.
How soon can we compare the changed process?
Use enough comparable cases to assess routine work and relevant exceptions. The appropriate period depends on workflow frequency and variation. State the period and limitations; there is no universal number of days that makes a comparison reliable.