You know which work your team is tired of doing. Every week or month, someone pulls the same records, checks the same details, and follows up on whatever is missing. It feels like an obvious candidate for automation.
The useful question is how much of that burden automation would actually remove. Finishing one step faster means less if someone still has to chase missing information, fix errors, and check the result.
Before building anything, I want to see where the time and effort go across the whole process. That gives us a starting point for choosing what to automate and a way to tell whether it helped.
I’ll use two examples from my work with a construction business: checking monthly card charges against the accounting records, and reviewing what projects have cost compared with their budgets. The details come from construction, but the questions apply wherever people bring records together, resolve differences, and take responsibility for the result.
Start with work you can follow
In the construction work, two recurring processes gave us a useful starting point. One was the monthly check of card charges against the accounting records, called reconciliation. The other was reviewing what each project had cost compared with its budget.
The card process runs from receiving the statement through matching records, resolving differences, and reviewing the result. Payment approval remains a separate decision. The project cost review brings together the budget and recorded costs for an agreed date, then checks that the comparison makes sense.
Both have a clear reason for happening again next month. Both also need someone to accept the result. A populated spreadsheet or a list of matched transactions is progress, but there may still be questions to resolve.
That gives us a boundary to measure: what starts the cycle, what counts as finished, and who takes responsibility for it. The records and decisions between those points are the work we need to understand.
Find out where the effort goes
The repetitive part of reconciliation is easy to see: collect the records and match the entries. Then there are duplicates, split transactions, and missing information. Someone has to sort those out.
That is where I’d want to understand the effort. Saving time on the straightforward entries is useful, but it tells us less if the remaining investigation still takes substantial effort. We need to measure it across complete cycles to find out.
I separate the time a process takes from the time people spend on it. A reconciliation can wait for a missing receipt without anyone actively working on it. Conversely, a quick exchange can hide quite a bit of checking before and after the message.
System timestamps help with the first measure. They do not reliably give us the second. Recording staff effort takes some extra work, but it gives us a basis for deciding whether automation has reduced the burden.
Workload matters too. The number of card transactions or projects reviewed helps explain why one month took longer than another. Otherwise, a quieter month can look like an improvement.
Keep the awkward cases in view
The exceptions are part of the process. Leaving them out would make the work look easier than it is.
For the card workflow, I’d keep the measurement simple enough to use:
| Part of the monthly cycle | What to record |
|---|---|
| Collect the records | When the required records are available |
| Match transactions | Effort and entries matched without investigation |
| Investigate differences | Exceptions, missing information, and effort |
| Review corrections | Review effort and work sent back |
| Complete reconciliation | Completion date and acceptance of the result |
The number of entries matched automatically is only part of the result. We also need to know whether those matches were correct and how much investigation remained. Work sent back after review belongs in the record too.
Understand what the records mean
One complication in the project cost work was that the categories did not line up directly between the project system, accounting system, and reporting workbook. The same expense could be grouped differently in each.
The approach was to keep the existing categories and map them for the comparison. Pulling the data faster would help with collection, but the mapping still needed clear rules. It was part of making the report useful.
That changes what we need to measure. Time spent collecting data is different from time spent sorting out categories and checking discrepancies. A completed report can also have needed corrections that are invisible in the final version.
The monthly reporting conversations showed another connection. A person supplied a report on projects still underway, referred to a written procedure, and requested a draft accounting adjustment with the report attached and a link for review. Taken together, those actions form a preparation and review workflow. The draft alone would leave out the supporting work needed to make it reviewable.
These are separate processes, but they make the same point: getting information into the next system is one stage of getting the work finished.
Bring a few complete cycles
This is why I ask for previous cycles and their supporting records.
For reconciliation, that means statements, accounting exports, exception notes, and completed records. For project cost reviews, it means budgets, cost reports, mapping rules, and reviewed output. A routine month is useful. A difficult one often tells us more about where people spend their effort.
The examples need to cover the recurring process. Plenty of transactions from one easy month can tell us about matching without telling us much about the monthly cycle as a whole.
I also want enough context to make the comparison reproducible: which cases were included, when they happened, where the values came from, and how the measures were calculated. Keep the individual results alongside the summary. If nobody recorded the effort, leave that gap visible.
A few cycles can help us understand the work and scope an implementation. More evidence may be needed before treating the results as representative of the wider company.
Agree what would make the work better
With that baseline, we can make a more useful decision about what to build.
For reconciliation, the priority might be less staff effort, fewer unresolved differences, or earlier completion. For project cost reviews, it might be less time assembling a trustworthy comparison or fewer corrections during review. The people responsible for the work need to agree which result matters.
Then we can compare similar cycles after implementation, taking workload and complexity into account. Time spent checking automated output, resolving failures, and maintaining the process belongs in that comparison. It still takes someone’s time.
The records from this work show how the processes fit together. They do not give us a measured time saving. Collecting the baseline is what lets us make that assessment later.
Why the prework is worth doing
The preparation I ask for is substantial: previous cycles, source records, procedures, exception examples, and the rules people use to make decisions.
Those materials help us see where automation could be useful. In reconciliation, that could mean collecting and matching records while making exceptions easier to review. In project cost reporting, it could mean assembling consistent data while preserving the mapping rules and the reviewer’s judgment.
Once we have a baseline in the company, we have something to build on. We know the systems, the records, and more of the exceptions. The first engagement has to establish that foundation, so I want its scope to allow for the work involved.
Bring a recurring process, a few complete cycles, and the records that explain how the work got finished. That gives us a useful place to start.
You can use the preparation guide to work through those questions, or get in touch with a process you have in mind.