How to Choose the First Business Workflow to Automate

Suppose you have budget for one automation project and three proposals to consider. Document review accounts for 1,040 staff hours a year, handling new inquiries takes 520, and preparing recurring reports takes 360. On that first comparison, document review deserves a closer look. It consumes twice as much time as intake, and the people doing it may also be more expensive.

These are invented figures for a worked example, not Foregrounds client results or industry averages. We'll use them to make a choice that a list of potential time savings leaves unresolved: which project deserves the first investment once you account for the work that will remain, the cost of running it, and the likelihood that people will use it?

A large workload can make a project look promising, but it doesn't tell us how much of that work automation can take off the team's hands. Checking results, handling unusual cases, and keeping the system running all take time too. Working through those details helps us see what each proposal could actually deliver.

Start with the hours, then make the deductions

Our three proposals cover specific pieces of work. Intake ends when a website inquiry reaches the correct person with the information needed to respond. Document review produces a checked first-pass list of provisions requiring attention in a defined type of agreement. Reporting produces a reconciled recurring report package, ready for its intended reader.

The current annual effort comes from these illustrative inputs:

Lead intake and routing. Annual volume: 5,200 inquiries. Current staff time per item: 6 minutes. Current annual effort: 520 hours

First-pass document review. Annual volume: 2,080 documents. Current staff time per item: 30 minutes. Current annual effort: 1,040 hours

Recurring management reporting. Annual volume: 144 report packages. Current staff time per item: 150 minutes. Current annual effort: 360 hours

A report package means one recurring set of reports, potentially among several produced each month. The totals include active staff time, so they tell us how much labor the work currently consumes. They don't tell us how much an implementation will release.

Document review's apparent advantage starts to shrink when we separate the eligible work from the full workload. Some agreements may fall outside the document type the system handles, contain unusual provisions, or have restrictions on how they can be processed. Even an eligible document may stay outside the new process if a colleague continues using their existing method. Of those that do enter it, every first pass still needs checking, and a difficult case may need substantial additional work.

There is a research reason to resist extrapolating from a good demonstration. In a randomized experiment involving 758 BCG consultants, participants using GPT-4 completed suitable consulting tasks 25.1% faster and produced work rated 32% higher in quality. On a different managerial task the model handled poorly, AI-assisted participants were about 19 percentage points less likely to reach the correct answer. The study appeared in 2026, but the experiment used designed assignments and GPT-4 in 2023. It didn't study document review or establish the assumptions in our example. Its relevance to this investment decision is narrower: success on one activity doesn't justify treating an entire workload as eligible for the same saving.

A capacity estimate needs to account for those deductions explicitly:

Net annual capacity = annual volume × eligible share × adoption × (current minutes − routine review minutes − exception rate × extra exception minutes) ÷ 60 − annual upkeep hours.

Adoption here means the share of eligible cases that actually uses the new process. Exception minutes are additional to routine review, so we avoid counting the same work twice. Upkeep includes the staff time spent monitoring, troubleshooting, and updating the system. Only completed work that meets the required quality standard can contribute to the claimed capacity release; faster incorrect work doesn't earn a credit in this calculation.

For lead intake, assume 95% eligibility and 90% adoption. The system handles 4,446 inquiries. Each needs half a minute of routine checking, while 10% need another five minutes to resolve an exception. That leaves an average of five minutes released per processed inquiry. After 36 annual hours of upkeep, the result is 334.5 hours of net capacity.

Document review has 80% eligibility and 80% adoption in this example. Routine checking still takes 12 minutes per processed document, and a quarter need another 18 minutes. Allowing 72 hours for annual upkeep leaves about 228 hours. The original 1,040-hour workload has become a smaller capacity gain than intake's, largely because less of the work enters the system and more human effort remains on each item.

Reporting releases about 112 hours, assuming 75% eligibility, 90% adoption, 35 minutes of routine review, an additional hour for the 15% of packages requiring exception work, and 60 annual upkeep hours. None of these values is a benchmark. Recent cases can inform eligibility, a small test can reveal checking time and exceptions, and actual use can eventually replace the adoption assumption. At the proposal stage, the model exposes what you still need to learn.

The largest capacity gain still has to justify its cost

The ranking has changed, although we haven't yet priced the three proposals. A document review hour may be worth more to the business than an intake hour, while the systems needed to release it may cost more too. Both belong in the comparison.

At an illustrative labor cost of $50 an hour, including salary and employer costs, intake's 334.5 hours have a planning value of $16,725. Document review's capacity is worth about $18,200 at $80 an hour, and reporting's about $7,300 at $65 an hour. Giving the released time a monetary value lets us compare it with expenses. It doesn't turn that time into cash savings.

Now suppose annual operating expense is $6,000 for intake, $12,000 for document review, and $8,000 for reporting. These amounts cover software and external running costs; internal maintenance time has already been deducted as upkeep. Intake retains a $10,725 annual capacity-value balance, document review about $6,200, and reporting falls roughly $700 short of its recurring cost. Each cost appears once, even if different departments would pay it.

Implementation changes the first-year decision again. With an $8,000 intake build, the remaining first-year planning balance is $2,725. A $15,000 document implementation or a $10,000 reporting implementation would leave a negative first-year balance under the respective assumptions. These calculations assume a full year at the stated volume and adoption. A phased rollout would release less capacity during its first year.

A negative first year needn't rule out a project that produces sufficient value over a longer useful life. It does mean someone must fund the initial gap and believe the benefit will persist. Reporting presents a different problem in this example: the modeled benefit doesn't cover even its recurring cost. Waiting another year won't repair that arithmetic unless the scope, volume, cost, or value changes.

At The Foregrounds, we'd also want the proposed use of the released time to be specific. An hour freed for a team already turning away client work has a different practical value from an hour dispersed across people who have no additional work to take on. Fewer paid overtime hours can reduce an expense; accommodating growth without a planned hire can change a budget. Faster service or more time for business development may also be valuable, but the financial result depends on what happens next.

Researchers at the St. Louis Fed make a related distinction in their discussion of reported time savings and business productivity: organizations may need to reorganize work before saved time appears in measured productivity. A capacity-value estimate is useful for planning. Payroll savings or additional revenue require their own evidence.

A waiting customer changes the comparison

There is another reason the hours alone may understate intake's value. An inquiry can require six minutes of administration and still wait half a day before anyone responds. Reducing that wait improves the prospective client's experience even if the team retains some of the handling work.

In Zapier's account of Vendavo's lead-handling work, inquiries previously passed through email, a spreadsheet, and manual entry. Connecting submissions directly to the customer relationship management system, or CRM, and notifying sales reportedly reduced response time by 90%, from hours to minutes. This is a vendor-reported result, not an independently measured benchmark. It provides a concrete example of how removing a handoff can matter beyond the minutes spent copying information.

For your own comparison, active staff time and elapsed time should therefore stay separate. Intake might earn its investment by improving how consistently inquiries receive attention. You could measure how long qualified inquiries remain unanswered and whether the oldest ones are still being missed. A conversion uplift would be a separate claim, requiring evidence that the faster response changed business won.

Volume deserves the same care. One or two weeks of records can provide a practical starting estimate, but a campaign may inflate inquiry volume and quarter-end may inflate reporting effort. Before annualizing either, compare the sample with a quieter period and a known peak. NIST's guidance on operational time series explains why trend and seasonality matter when interpreting observations over time; it doesn't establish that two weeks is enough for every process.

This can change the recommendation. Low regular inquiry volume may weaken intake's capacity case, while persistent delays could preserve a service case. Reporting may become more valuable during a demanding close, but that value needs to be distinguished from assuming every month resembles the busiest one. The comparison should make those reasons visible so leadership can decide which outcome merits funding.

Refine the proposal before committing to the build

Once we've worked through the comparison, we can use what we've learned to improve the proposals themselves. Some of the costs we've allowed for may come from missing information or unclear responsibilities that the team could resolve before any software is built. Other parts of a proposal may add too little value to justify including them. Four options help us decide what to change.

We would first fix problems that make the work unnecessarily difficult. For intake, that could mean adding a field so prospects can tell us which service they need, or agreeing who should receive each type of inquiry. Both changes could reduce the number of submissions someone has to interpret or reassign. For reporting, agreeing on what each metric means could remove some of the reconciliation work we've included in the estimate.

With clearer inputs and ownership, we could automate the transfer and assignment of inquiries. The revised proposal would cover those specific steps, with a new estimate of build cost and how much checking would remain.

For document review, we would use AI to assist the person reviewing a defined type of agreement. Keeping that person's checking time in the calculation helps us judge whether the narrower proposal is worth pursuing.

We would defer AI-written reporting commentary while we establish whether connecting the agreed data sources would save enough preparation time to justify its cost. That gives us a smaller reporting proposal we can assess on its own.

These revisions give us a clearer account of what we'd be paying for and what benefit we could reasonably expect. We can then update the cost and time estimates, see whether the expected return improves, and identify what still needs testing before committing to a full build.

Use the first commitment to settle the weakest assumption

Intake leads in this worked example, but the size of its advantage depends on assumptions that can be wrong. Before paying for a full implementation, we'd identify which uncertain input could plausibly reverse the choice and use the initial budget to learn about it.

Document review shows how consequential one assumption can be. Reducing adoption from 80% to 60% lowers its net capacity from about 228 hours to about 153. At $80 an hour and $12,000 in annual operating expense, the annual capacity-value balance falls from roughly $6,200 to about $200, before implementation. That narrow margin makes actual usage particularly important to the decision. A strong demonstration gives little information about how much eligible work people will put through the system.

For intake, we would fund a limited connection between one inquiry source and the team's records first, with a defined ceiling on integration cost. It needs to establish that inquiries reach the correct owner with their details intact, and that unresolved assignments remain visible. Those are quality gates. The investment question is then whether real volume, retained checking time, and exception handling support the expected capacity gain, while the records show whether inquiries receive attention sooner.

An unexpectedly difficult integration, substantially fewer eligible inquiries, or expensive assignment exceptions would weaken the case for expanding that connection. We could then revise the intake scope or compare a narrow document-review test against the new evidence. Reliable intake with acceptable ongoing effort would support the next spend. Reporting would remain a preparation project until its definitions and costs support a different conclusion.

Our AI strategy work can help put competing proposals on this common basis. The first commitment should resolve the uncertainty most likely to change your investment decision, with an agreed spending limit and a clear decision about what that evidence will fund next.