An automation trial needs a defined task, a baseline and a way to handle exceptions. A faster successful example does not establish lower total effort or a return on investment. Use one bounded workflow to record direct handling, review and corrections, then decide whether the result supports a next step. The figures below are fictional teaching data, not a measured saving by an Estonian company.
1. Write a question the trial can answer
Choose one repeatable action within an agreed process. For example, test whether information from a synthetic request can be placed into the correct assignment fields for a person to review. Define the input, expected output, owner and actions that remain manual.
Keep unrelated changes outside the trial. A new service offer, different task mix and a revised approval process can all change the result even if the automation is unchanged. The first-month workflow plan explains how to choose a boundary; the weekly measures guide helps keep definitions consistent.
State what is being tested without promising a target saving. “Compare complete handling time and errors for this defined task type” is a question. “Cut costs by half” is an outcome that needs evidence.
2. Prepare permissions, records and a fallback
Name the trial owner and the person who accepts its output. Use synthetic data for the initial check. Confirm who can access the input and output and where the original records remain available. Use the access and recovery checklist before involving live systems.
Specify a stopping condition and a manual route. In this illustrative model, an unresolved discrepancy in the accepted output or a lost source record stops the trial. The owner restores the established manual method and records the issue. These conditions belong to the model; an actual organisation must set its own authorised limits.
Do not let a trial create payments, send customer messages or change permissions merely because those actions are technically available. Such actions need their own business authorisation and controls. This article describes planning and measurement, not instructions to activate an integration on the reader's live accounts.
3. Record the whole handling effort
For the baseline and trial, distinguish direct active handling, human review and correction effort. Count a category only once. Record unattended processing and waiting separately: a system's elapsed run time is not automatically a staff member's active work time.
Keep the number and type of assignments beside the time measures. Include failed and returned tasks under the selection rule, rather than reporting only the successful automated ones. The handover checklist provides a place to record what the next person accepted or returned.
Use the same observation boundary in both periods. If the earlier record includes correction work but the later record omits it, the comparison does not measure the same effort. If a time is missing, mark it as unknown and report the coverage instead of entering zero.
4. Read a worked example without turning it into a forecast
The fictional example compares two batches of ten assignments of the same described type. The direct-handling categories below exclude the separately stated review and correction categories.
Scroll sideways to see every column.
| Measure | Baseline batch | Trial batch |
|---|---|---|
| Assignments in the batch | 10 | 10 |
| Direct active handling | 60 minutes, including the ordinary baseline checks | 30 minutes, excluding the separate trial review below |
| Additional trial review | 0 minutes in this model; ordinary checks are already in direct handling | 20 minutes |
| Correction effort | 20 minutes | 10 minutes |
| Total active effort for the batch | 80 minutes | 60 minutes |
For the baseline, 60 + 0 + 20 = 80 minutes. For the trial, 30 + 20 + 10 = 60 minutes. The illustrative difference is 20 minutes per batch, or 2 minutes per assignment for these equally sized batches. Looking only at direct handling would overstate that difference as 30 minutes.
The zero in the additional-review row is part of this explicit fictional accounting model, not a way to fill a missing observation. The example shows no measured production result, average for Estonia or guarantee for the next batch.
5. Keep one-off and ongoing costs separate
In the same fictional model, setup takes 120 minutes and training takes 30 minutes: 150 minutes of one-off effort. These figures are not included in either batch total. Record the corresponding actual effort separately in a real trial.
List subscriptions, usage charges, support and continuing review in their own fields. No monetary subscription price or hourly labour cost is supplied in this example, so no net financial benefit or payback period is calculated. Do not replace an unknown cost with zero or insert a national salary average as if it were your actual marginal cost.
Time released from handling tasks and cash saved are different outcomes. A company's staffing commitments and use of that time need separate evidence. A batch comparison alone does not establish profitability.
6. Keep a trial log that can explain exceptions
- Period, task type and selection rule.
- Trial owner, operator and output reviewer.
- Assignment ID, included volume and data completeness.
- Direct handling, review, corrections and their definitions.
- Waiting and unattended processing, recorded separately.
- Error or exception, responsible person and resolution.
- Setup and training effort, subscription or usage cost fields.
- Acceptance decision, stopping event and fallback used.
Record changes to the trial method and their dates. If people learn the work during the comparison, note that. Workload differences, learning and other changes limit what a before-and-after comparison can establish. It is not a controlled causal experiment merely because it has two columns.
7. Decide whether to continue, revise or stop
Review accepted output, total effort and unresolved exceptions together. Continue only under the authorised conditions chosen before the trial. A result with missing records needs another observation or a repaired measurement process before a decision about savings.
A revision is a new trial version. Keep its changed rules visible rather than mixing its results with the first version. For an extension to another process, repeat the access and recovery checks and define the new boundary.
The cloud-service study describes reported buying across enterprise-size groups. It does not measure implementation quality or justify skipping this trial. EIS's digitalisation material provides a wider process-development context; the log, conditions and numerical example here are this publication's own model.
8. Source and next action
- EIS: Digitalisation, checked 3 November 2026.
- Choose one task type. Complete the trial log, preserve its baseline and define a stop condition before activating a change. Use the results to choose the next step without promising a financial outcome that has not been measured.