Understanding the process as it really runs. Not the documented version. This means watching it, reading the exceptions from the last few months and finding the steps nobody mentions because they are obvious to the people doing them. A few days, and skipping it costs more later.
Access and environments. Credentials, a sandbox, API keys, a test account, a security review if you have one. This is the step that most often adds weeks, and none of that time is technical.
Building the main path. Usually the fastest part, and the part clients expect to be the slowest. The happy path of a well-understood process comes together quickly.
Exceptions. Where the real time goes. Every rule has cases it does not cover, and each one needs a decision from you: handle it, flag it, or send it to a person.
Running it beside the humans. A period where the system does the work and people check it, on real volume. This is what turns an estimate of accuracy into a measured number, and it cannot be compressed much.
The pattern is consistent enough to predict. Projects run long when nobody can approve a decision without a committee, when access requires a security process nobody started, when the process turns out to be three processes that differ by region, or when the answer to "what happens to this case?" is that it depends on who is working that day.
None of these are technical problems and none of them are anyone's fault — they are simply what the automation exposes. A process running on human judgement absorbs ambiguity invisibly; a system cannot. Writing the missing decisions down is work that had to happen eventually, and the project is what forced it.
One person who can decide. Not a steering group. Someone who owns the process and can answer an exception question in a day.
Access arranged before the start. If a security review is required, start it during the audit, not after the contract.
A narrow first scope. One process, one region, one document type. Everything else is version two, and version two is much faster because the connections already exist.
Historical data available. A few months of real cases with known outcomes turns accuracy from an argument into a measurement.
Willingness to leave exceptions manual. Automating eighty per cent of volume in six weeks beats chasing the last twenty for six months.
Before any timeline exists there is a free mini audit: we look at the process, the systems and the data, and come back with what can be automated, what it would take and what it would be worth. That produces a fixed quote — not a rate card and an estimate that drifts, but a price for a defined outcome.
This step also filters. Some processes should not be automated yet, usually because a decision has not been made or the data to support it does not exist. Finding that out in an audit costs nothing; finding it out in week five costs a project.
If the audit says the honest answer is a spreadsheet fix or a configuration change in software you already own, we will say so. It has happened more than once.
The first fortnight in production always produces surprises, because real volume contains cases that a sample did not. Budget attention for it: someone from your side watching the exception queue, and quick turnaround from ours on adjustments. This is normal and it is short.
Then it settles. The second process on the same systems is typically much faster than the first, because the connections, the access and the monitoring already exist. Clients who plan a sequence of processes usually see the schedule compress as they go.
We use cookies for analytics — to see which pages bring enquiries. Nothing else, and nothing before you agree. Cookie Policy