How Long an Automation Pilot Really Takes

A well-scoped automation pilot on a single process runs roughly one quarter from kickoff to a system doing real work in production. Not a demo, not a sandbox — a process running against live data with a human still watching it. That timeline assumes you have one clearly bounded process, a named business owner who can make decisions without a committee, and IT access granted within the first couple of weeks. Miss any of those three and the quarter stretches.

Most of that time is not spent writing code. The build itself is usually the shortest phase. The long poles are understanding what the process actually does (as opposed to what the SOP says it does), getting credentialed access to the systems involved, and running the new system in parallel with the old one long enough that people trust the output. If a vendor tells you they can deliver a production automation in two weeks, they are either automating something trivial, skipping the parallel run, or handing you a prototype and calling it a pilot.

The five phases, and where the time actually goes

Process mapping. This is where we watch the work get done. Not a workshop where someone describes the process from memory — actual observation, screen recordings, sampling of real transactions, and a tally of the exceptions. Every process has a documented happy path and an undocumented reality made of workarounds, email threads, and one person who knows what to do when the vendor code is missing. The mapping phase exists to find that reality. It usually takes two to three weeks for a single process, and it runs longer when the work is distributed across several teams who each do it slightly differently.

The output is not a diagram for its own sake. It is a decision: which slice of this process is worth automating, which exceptions we will handle in software, and which we will deliberately route to a person. Getting that boundary wrong is the single most expensive mistake in a pilot, because it surfaces during the parallel run when rework is most disruptive.

Design. Short phase, high leverage. We settle the integration approach (API, database, file drop, or UI automation as a last resort), the data model, the exception-handling path, the audit trail, and what "correct" means in terms someone can test. Design also covers the operating model: who gets paged when the automation stops, who approves an exception, what happens during month-end close. This phase typically runs a week or two and depends heavily on how quickly your architecture and security teams can review the approach. We cover our review and approval sequence in more detail on how we work.

Build. Three to five weeks for a well-scoped single process. This is the phase everyone imagines when they think about automation, and it is the most predictable one. It runs long when the source systems are poorly documented, when rate limits or batch windows force awkward scheduling, or when document extraction is involved and the input quality varies more than the sample suggested. Building against a system with a clean, documented API is a different job from building against a legacy screen with no test environment.

Parallel run. This is where pilots earn their credibility, and it is the phase most often cut. The automation processes real work alongside the existing manual process, and you compare the results item by item. Discrepancies get triaged into three buckets: the automation is wrong, the manual process was wrong, or the two are both defensible and the rule was never actually defined. That third bucket is common and useful — it is how you discover the policy questions nobody had to answer while a person was quietly making the call.

Parallel running needs enough volume and enough calendar time to cover the process's natural cycle. A daily process needs weeks. A month-end process needs at least one full close, and honestly two. Shortening this phase to hit a date is how you end up with a system that fails in week nine of production on a case that happens every quarter.

Cutover. Short in elapsed time, but it needs preparation. Cutover means the automation becomes the system of record for that process, the manual path is retired or reduced to exception handling, and monitoring plus escalation are live. We plan a fallback for the first few cycles — a documented way to revert to manual — and we keep it until the automation has run clean through a full cycle without intervention.

What actually makes it slower

Access. The most common cause of delay, and it is almost never technical. Service accounts, read credentials to a data warehouse, a non-production environment, network allowlisting, a vendor's permission to use their API — each of these is a ticket in someone else's queue. The fix is to start the access requests during the mapping phase, before you strictly need them, and to name a single person on your side who can escalate when a request stalls. If access is likely to take longer than the build, say so out loud at kickoff and set the schedule around it. Our security and access practices page covers what we ask for and why, which helps shorten the review.

Data quality. Automation does not tolerate ambiguity the way a person does. Inconsistent vendor names, free-text fields carrying structured meaning, dates in three formats, records that violate the constraints the schema claims to enforce — all of it surfaces during build and parallel run. Sometimes the right answer is to clean the data first, which is its own project. More often the right answer is to handle the messiness explicitly and route the genuinely ambiguous cases to a person. Document-heavy processes are their own discipline; that is the work we describe under document and data intelligence.

Approvals and stakeholder count. Every additional approver adds calendar time, not effort. A pilot that needs sign-off from operations, finance, IT security, legal, and a vendor management office will spend more days waiting than building. Sequence the approvals early, in parallel where possible, and get the security review started before the build rather than after.

Scope drift. Once people see the automation working, adjacent requests arrive. "Can it also handle the international entities?" "Can it write back to the CRM?" Each is reasonable; each resets the parallel run. We log them and hold them for phase two. A pilot that absorbs every good idea never ships.

Availability of the people who know the process. The subject matter expert is usually the person doing the most work. Their time is the scarcest input in the project, and it is needed in concentrated bursts during mapping and parallel run. Protecting a few hours a week of that person's calendar, formally, is worth more to the schedule than adding engineers.

When the answer is "don't automate this yet"

We turn work down or recommend waiting more often than you might expect. The honest signals:

• The process is about to change. If an ERP migration, a policy rewrite, or a reorganization is landing within a couple of quarters, automating the current state is building on sand. Wait, or automate a piece that survives the change.
• Nobody can say what "correct" means. If two experienced people handle the same case differently and neither is wrong, the process needs a decision before it needs software. Automation will force that decision anyway — better to make it deliberately.
• The volume does not justify it. A process that runs a handful of times a month, takes minutes, and never causes downstream errors is not a good first candidate, however annoying it feels. Frequency, error cost, and cycle-time pressure matter more than how tedious the work is.
• The underlying data is fundamentally broken. If the source records are wrong often enough that a person is effectively re-deriving the truth every time, fix the source. Automating on top of bad data industrializes the errors.
• No owner. If no one on the business side will own the outcome — approve exception rules, sign off on cutover, answer the phone when it breaks — the pilot will stall regardless of engineering quality.

Saying "not yet" on one process usually points to a better one. The exercise of ranking candidates by volume, error cost, and data readiness is quick, and it is worth doing before committing a quarter. Our value calculator is a structured way to work through those inputs with your own figures.

What a first quarter should deliver

By the end of a pilot quarter, you should have all of the following. If you have a working demo and nothing else, the pilot did not deliver.

• One process running in production against live data, with a defined scope boundary and a documented list of what it deliberately does not handle.
• Measured baseline and current performance — cycle time, volume processed, exception rate, error rate — recorded before and after, using your numbers, not ours.
• A parallel-run comparison record showing where automation and manual output agreed and how each discrepancy was resolved.
• An operating runbook: monitoring, alerting, escalation path, on-call expectations, and the manual fallback procedure.
• Documented exception handling — which cases route to a person, how they are queued, and how long they wait.
• Security and audit artifacts: access model, logging, data retention, and whatever your auditors will ask for next year.
• An honest roadmap for what comes next, including which adjacent processes are now cheaper to automate because of the integration work already done, and which are still not ready.

That last item is where the real return on a pilot sits. The first process carries the cost of establishing access, environments, deployment, monitoring, and trust. The second and third processes in the same system landscape are meaningfully faster because that groundwork is done. If you are judging a pilot purely on the savings from process one, you are measuring the wrong thing — you are measuring the most expensive unit you will ever build.

How to compress the timeline honestly

You can shorten a pilot without cutting the parallel run. Pick a process with a clean system of record rather than one that spans six tools. Start access requests at kickoff. Name one decision-maker and give them authority. Provide real sample data, including the ugly cases, in week one — sanitized production data beats synthetic data every time, and getting that approved early removes a classic mid-project stall. Choose a process where the business owner already has a clear view of what good output looks like.

What you cannot compress: the natural cycle of the process. A monthly close is monthly. A quarterly reconciliation is quarterly. Plan the parallel run around the calendar rather than around the project plan, and be suspicious of anyone who proposes otherwise.

If you want a sense of what this looks like in different shapes of work — back-office transaction processing, document-heavy intake, or customer-facing queues — see our intelligent process automation and AI customer operations practices, or the broader services overview.

If you have a process in mind and want a straight answer on whether it is a good first candidate and what the realistic schedule looks like, talk to us. A scoping conversation takes under an hour, and we will tell you if the answer is to wait.

Questions we get asked about this