How to scope an automation project that is worth doing

Most organizations have a process that everyone agrees is painful. Invoices are retyped from PDFs. Orders are copied from one system to another. Someone spends every Monday building the same report. These are good candidates for automation, but only if the project is scoped well.

Here is how we scope automation and integration work, and why we start with discovery before building anything.

Start with a problem you can measure

“We want to use AI” is not a scope. A scope starts with a business problem, written down in plain terms:

The process. What happens, step by step, from trigger to result?
The people. Who does the work, and how many of them?
The volume. How many invoices, orders, tickets or records each week?
The time. How many hours does it take each week?
The errors. How often is something wrong, and what does a mistake cost?
The delay. How long does a customer, vendor or manager wait?

If you cannot answer these, measure them first. A few weeks of simple tracking is usually enough. Those numbers become the baseline every later decision is judged against.

Map the process, including the exceptions

Draw the process as it really runs, not as the procedure manual says. Note every system it touches, every decision someone makes, and every handoff between people. Pay special attention to exceptions: the order with a missing part number, the invoice that does not match the purchase order. Exceptions are where most of the time goes, and where automation projects most often fail.

Use what you already own: API first

The first question is not which AI tool to buy. It is what your existing systems can already do. Many business applications have built-in automation, application programming interfaces (APIs), or ready-made connectors that are never switched on.

In a recent episode of CRN’s The Path to Growth, Paul Redding of NinjaOne summed it up: AI gets the attention, but it starts with API. Automation, in his view, begins with the tools you already own and the interfaces between them.

Connecting the systems you already pay for is usually faster, cheaper and easier to support than adding another platform. It also gives any AI component clean, reliable data to work with.

Put AI where it helps, and a person where it matters

AI is useful for work that involves reading or judgment on unstructured information:

Pulling fields from invoices, purchase orders and shipping paperwork.
Classifying incoming requests and routing them to the right queue.
Drafting replies or summaries for a person to review.

For document-driven work, design the exception path as carefully as the happy path. Decide which results are confident enough to process automatically and which go to a person for review. Decide who reviews them, how quickly, and how corrections are recorded. Every automated decision should leave a record someone can audit.

Settle data and access early

Before anything is built, agree on:

Access. Which systems the automation connects to, with what permissions. Use dedicated service accounts with the least access needed.
Data. What information leaves your environment, if any, and under what terms.
Retention and logs. What is stored, for how long, and who can see it.
Ownership. Who inside your organization owns the process after go-live.

Write acceptance criteria before you build

Agree up front on how you will know the project worked. Good acceptance criteria are tied to the baseline:

Processing time per document or transaction.
Error rate, measured against a sample checked by a person.
Number of exceptions sent for review each week.
How the system behaves when a connected application is unavailable, and how work is recovered.

Test with real samples from your own operations, not ideal examples. Agree on a rollback plan in case the new process has to be switched off.

Why we start with paid discovery

We scope automation through a short, paid discovery engagement before any build. Discovery produces:

A map of the current process, with its exceptions.
Baseline measurements of time, volume and errors.
A review of the systems involved and what access they allow.
Solution options, including the option not to automate.
An estimate and acceptance criteria for the recommended option.

Paying for discovery keeps both sides honest. You get an independent answer, which sometimes is that a process should be simplified rather than automated. We get the information needed to price the build accurately, instead of guessing.

An example worth remembering

In the same episode, Redding described a two-person managed services firm working with an intermodal shipping company. The owner had been listening to the company’s dispatcher complain about the 24-hour outsourced dispatching team they had used for years. He built an internal agent to handle dispatching. As Redding told it, the agent was internal rather than customer-facing, the firm did not have to hire anyone, and it solved a real business problem.

The lesson is not the technology. It is that the project started with listening to a specific, costly frustration inside the business.

After go-live

Automation is not finished at launch. Review the measures monthly against the baseline. Watch the exception queue: if it grows, something upstream has changed. Plan for updates when connected applications change their interfaces. Give the process a named owner.

A scoping checklist

Problem written down, with volume, hours, errors and delays
Baseline measured over a representative period
Process mapped, including exceptions and handoffs
Existing systems’ automation and API options reviewed
Exception handling and human review designed
Access, data, retention and ownership agreed
Acceptance criteria and rollback plan written
Discovery complete before build is priced

Have a process in mind?

Our Automation Value Estimator helps you put numbers to a manual process in a few minutes. When the numbers justify it, we start with paid discovery. See systems integration and automation, or discuss a project with us.