Choosing your first automation project and checking its payback

Persistent complaints about manual work deserve attention. They do not, by themselves, tell you which process to automate first. The most frustrating task may have disputed rules, inaccessible data or benefits that will take years to assess.

The first project also affects confidence in future investment. The campaign optimizer I developed for a large international advertising agency met its purpose and became a foundation for further automation. An expensive implementation with unclear results would have made the next budget harder to justify.

I suggest starting with the expected benefit, checking whether the process is ready, and then calculating payback. Existing operational records are enough for an initial assessment. You do not need a detailed technical specification to begin.

Identify where the benefit will come from

Automation can free up time, reduce errors and help people act sooner. Consider these effects separately. Hours are usually the easiest to count, but they may account for only part of the value.

Freeing up time. At the advertising agency, media buyers, the specialists responsible for buying ad placements, spent several hours a week reviewing campaigns and disabling underperforming placements. They still could not cover every campaign. I built an ad campaign optimizer that checked performance and applied their rules much more frequently.

While a placement waited for manual review, it continued spending money. The optimizer could disable individual placements, geographic areas, devices and other segments without stopping the whole campaign. Campaign profitability improved, and many campaigns became profitable. The strongest effect was on recent launches. These were campaign-level results, not evidence that every placement became profitable.

Reducing errors. The same agency's buyers edited landing page code containing complex analytics scripts. A mistake could prevent a visitor from reaching an advertiser, block the intended action or disrupt tracking. Advertiser statistics sometimes arrived several days late, allowing losses from paid traffic to continue unnoticed.

I developed a landing page builder that let buyers configure pages through an interface without editing code. Errors became less frequent, reducing the associated traffic losses. For a process like this, counting only staff hours would miss an important part of the benefit.

Acting sooner. The sales team sometimes discovered promising advertisers after competitors had already signed contracts with them. I built an advertiser discovery system that regularly prepares leads within a selected category, with contacts, partnership terms and context for outreach. It supports proactive prospecting; it does not guarantee that the agency contacts every prospect first or wins a deal.

For this type of process, the financial estimate might consider opportunities lost through late outreach and the contribution profit a new customer could bring. The sales lead can help set realistic assumptions, including acquisition and service costs. Until observations support those assumptions, treat the estimate as a scenario rather than a revenue forecast.

Check whether the process is ready

Choose three or four candidates and examine each against the six checks below. The useful outcome is a choice with clearly identified unknowns, rather than a formal score that hides them.

1. Frequency and consequences

Daily or weekly work usually creates more opportunities for savings than an occasional task. In the agency's campaigns, new placements appeared constantly, so reviews had to be repeated.

Frequency alone is insufficient. A rare error with expensive consequences can also justify automation. Compare the workload and potential losses with the cost of building and operating the system.

2. Decision rules

For the optimizer, I interviewed buyers about how they assessed campaigns, which conditions they used and when they made exceptions. Those details became the software's decision logic.

If someone can explain a decision only as “it feels right,” examine real examples together. That may reveal usable rules. Alternatively, the first version can collect and prepare information while leaving the final decision to an employee.

Choose the technology after understanding the task. Clear conditions often need only conventional code. Language models can help interpret text and compare scattered information. The article on choosing between AI and rules explains how to divide those responsibilities.

3. Data access and reliability

Establish where the system will get information and where it will write results. Advertising platforms, analytics tools, CRM systems and accounting software may provide an API, a software interface for exchanging data, or support exports and other transfer methods.

An available API does not settle the integration question. Some ad networks in the optimizer project returned delayed statistics or intermittent errors. Stale data could cause the system to disable an effective placement while leaving an unprofitable one running. I had to account for each source's actual behavior. Such limitations add work, although they do not necessarily make a project uneconomical.

Before sending customer information to an external language model, establish what data may be processed and the requirements for access controls, data location and deployment. Qualified specialists should determine the applicable legal basis; the system then needs the corresponding technical safeguards.

4. Error detection and recovery

The first version needs a way to show what happened and recover from mistakes. Keep irreversible actions subject to human approval.

In the landing page builder, I included logging, which records system events, and rollback to restore a previous page version. Other processes need their own recovery arrangements. Decide what an employee will be able to inspect, correct or undo before allowing the system to act automatically.

5. A responsible person in the business

Someone must explain the work, resolve disputed cases and accept the result. In my agency projects, department heads participated alongside the buyers who performed the work.

If nobody can agree on the rules or make time for testing, technically complete software may never become part of daily operations. Assign that responsibility before development starts.

6. A measurable result and a realistic observation period

Useful measures include hours worked per week, the number and cost of errors per month, or the time from identifying a prospect to first contact. Decide where the baseline figures will come from and how long a meaningful comparison will take.

A week of observation can help quantify repetitive manual work. It cannot establish the frequency of rare events. At energy company Gazprom Neft, I led an industrial safety training simulator project, described among the other products in this case study. It reached a minimum viable product, or MVP: an initial working version. But incidents were rare, so assessing the training's effect on their frequency could take years.

A process may have clear potential yet still need preparation. If its rules or data are not ready, a related, better-defined task may be a more useful first project.

Separate freed-up hours from financial savings

A preliminary monthly estimate can include:

• A justified cash benefit from freed-up staff time.
• Avoided losses from errors or delays.
• Additional contribution profit: new revenue after the costs of acquiring and serving those additional sales.

Do not count the same benefit twice. If freed-up hours allow employees to generate additional contribution profit, counting both that profit and the full cost of those hours would overstate the return.

Subtract operating costs, including hosting, language model usage where relevant, and necessary support. Use the chosen provider's actual rates at the expected workload. Include ongoing feature development if it is planned; a monthly development package is not an unavoidable cost for every small system.

With a positive net monthly benefit, simple payback is the initial investment divided by that benefit. If the monthly result is zero or negative, the project has no financial payback under those assumptions.

Worked example: time has a cash value

Suppose four employees spend 80 hours in total each month on a process. Automation is expected to reduce that to 15 hours for oversight and disputed cases. The hourly employment cost is 1,200 currency units.

An error currently occurs twice a month and costs 40,000 currency units each time. After implementation, assume it occurs about once every two months, or 0.5 times per month. There are no additional sales in this example.

Assume hosting, model API usage and all necessary operational support together cost 15,000 currency units per month. Development, data migration and training cost 600,000 currency units upfront.

All amounts are illustrative currency units. They are neither service prices nor a conversion into USD.

Simple payback is 600,000 / 123,000 ≈ 4.88 months, just under five months.

The crucial assumption is that the 65 freed-up hours produce a real financial benefit. For example, the company might avoid additional hiring costs as workload grows. If employees instead move to more valuable tasks, estimate those tasks' financial contribution separately. It does not automatically equal the employment cost of their time.

The same process without a cash benefit from time

Suppose payroll stays the same, no hiring cost is avoided and no additional financial benefit can be identified. The 65 hours still represent reduced workload, but they should be excluded from the financial calculation.

Monthly benefit then falls to 60,000 - 15,000 = 45,000 currency units. Payback becomes 600,000 / 45,000 ≈ 13.33 months.

Now change one more assumption: the original error occurs only once a quarter. Even complete prevention would avoid an average of 40,000 / 3 ≈ 13,333 currency units per month, less than the 15,000 monthly operating cost. With no cash benefit from time, there is no financial payback at that workload and cost.

Show the decision-maker both time scenarios and identify the assumptions still awaiting evidence. These figures are estimates, not guaranteed savings.

Also account for losses the automation itself could cause. In the agency's traffic antifraud system, I selected filtering thresholds for major campaigns by comparing the harm from problem traffic with the risk of rejecting genuine visitors who generated revenue. Stricter filtering was not automatically the better financial choice.

Budget for rollout and maintenance

Writing the software is only part of getting it into daily use. Existing work must move into the new system, employees must learn it, and someone must verify that their usual operations still work correctly.

For the landing page builder, I migrated more than 60 live pages. Copying them was insufficient: the scripts and the visitor's path to the advertiser had to remain intact. I wrote scripts to automate part of the migration, but the transfer still required implementation work. For the optimizer, I trained buyers and helped them move existing campaigns and configure rules.

External data sources create another ongoing cost. If software extracts information from another company's website, changes to page structure or access methods may require updates to the parser, the code that extracts that information. Not every layout change will break it, but maintenance belongs in the estimate. APIs and export formats can change too.

When comparing options, include purchase or development, rollout, migration, training, operation and expected updates. A lower initial price can otherwise conceal a more expensive system to run.

When to postpone custom development

If managers make opposite decisions in identical situations, start by agreeing on the process using actual examples. Software cannot resolve that disagreement for them. If essential information exists only in messages and employees' memories, collect and organize it before deciding what to automate.

Where the financial case is uncertain, find the few missing facts that could change the decision. These might be the true error frequency, time spent checking results or availability of a usable export. A detailed spreadsheet built on guesses adds little confidence. At the same time, short payback should not be a universal requirement: mandatory work and the reduction of serious risks may justify investment independently of it.

Sometimes the workload is too small or varied to justify a separate system. When I designed the release process for employee-built AI prototypes, there were few applications, and they connected to different systems. I chose not to build a separate automated system to review those applications, including their code and readiness for release. That would have introduced another system to develop and maintain. A part-time developer was more proportionate: employees prepared what they could under the procedure, and the responsible technical specialist reviewed and improved each application.

A ready-made service or configuration of an existing CRM may also be enough. Check its functions, limitations, integrations and total cost of use before commissioning custom work. The comparison of off-the-shelf software and custom development can help with that decision.

Use a limited rollout to test the decision

After the initial comparison, focus measurement on one or two promising candidates. For frequent manual work, start with a week of observations. Use longer records for rare errors. Record the unknowns that matter most, who can resolve them and how the result will be measured.

Two financial scenarios are useful before committing to development. If payback appears only under the most optimistic assumptions, reduce the first version's scope, collect more evidence or choose a different process.

Agree on how to validate the proposed logic before the main build. Sometimes a diagram or presentation is enough; sometimes a demonstration prototype is needed. For the landing page builder, I presented and demonstrated the logic and interface before implementation. Include the required preparation in the agreed project phase.

Limit the first rollout to one team and a defined set of tasks. I developed the optimizer in stages, from prototype to MVP and then to handling hundreds of campaigns. After launch, repeat the measurements and recalculate the economics before expanding.

The evidence may support stopping. In the news app and advertising platform project, I built the entire backend and initial advertising system; a separate developer built the mobile app. Actual installs confirmed demand, but projected advertising returns were weak. The client stopped the project before major spending on scaling and a high-volume advertising platform.

A useful first release gives you enough evidence to expand, change the scope or stop. If you would like help choosing a process, send me a few sentences about who does the work, how often it happens and where time or money is lost. We can start with a free written exchange in English; a completed payback calculation or technical specification is not required.