Business automation value: what work remains after development?

Before commissioning automation for a business process, examine everything a person does around the action you want to replace. Typing, scanning or drafting may be only the visible portion. Clarifying missing information, spotting mistakes, coordinating people and correcting results can remain after development. To assess value, compare the complete process before and after the change, including new work required to operate the system and check its outputs.

What can reduced self-checkout use illustrate?

In May 2024, Retail Dive reported on Dollar General reducing self-checkout. According to the CEO's comments quoted in the report, the retailer had removed self-checkout from twelve thousand stores and planned to reduce it across most locations. The change was presented as part of a broader effort to reduce inventory losses alongside other measures. This historical report does not establish that self-checkout caused every loss or that scanning itself always worked perfectly.

Our interpretation for software planning is to examine the surrounding work, not merely whether a machine performs an action. Replacing an employee's activity may also alter controls and service delivery. The conclusion is not that automation is inherently unnecessary. Its value depends on more than time saved in one step: it also depends on the cost of handling work outside that step and the quality of the complete outcome.

Observe work before turning it into features

Ask the person performing the process to walk through representative real cases that may appropriately be used. For each action, record what prompted it, what information they checked and where judgment was needed. Do not rely solely on the formal job description. Someone may fill a gap through a conversation, identify a duplicate request or stop a suspicious transfer without any of these actions appearing on the screen being replaced.

Separate routine actions from those that happen only when something goes wrong. Ask what the person avoids doing as well: an unapproved request, information withheld or a postponed change can be an important part of the outcome. These actions are not necessarily immediate automation candidates, but they belong in the technology product specification. Otherwise, they can disappear from the estimate even though the business will continue to need them.

Divide remaining work into three types

The first type is work the system still does not perform, such as clarification with a customer. The second is work it creates: handling alerts, maintaining rules and reviewing output. The third is correcting failures, including identifying actions already performed incorrectly. This distinction has a practical purpose. It prevents saved typing time from being presented as a complete saving when the same employee now spends similar time checking and correcting results.

For every remaining task, define its owner and the information that person receives. In a hypothetical quotation workflow, a system could prepare a draft while a person checks unusual pricing or special commitments. If the quote is sent automatically, decide who can correct it and what happens if the customer has already relied on it. This is a specification scenario, not a claim about results delivered for a client.

Calculate total cost with explicit assumptions

Start with case volume and current working time, then estimate which proportion can proceed automatically and which requires intervention. Add external service costs, maintenance, sample review and incident correction. Do not assume every freed minute becomes a financial saving: an employee may use it to improve service or absorb demand. Establish whether the objective is lower expenditure, shorter handling time or greater capacity before choosing how success will be evaluated.

Also examine a scenario with more exceptions than expected. A system may work well for most cases while requiring lengthy investigation for each exception, producing a different business result from the demonstration. Label measured numbers separately from assumptions. Before making a broad commitment, run a limited trial that compares actual work and preserves the existing way of handling cases outside the system's coverage.

A documented example from Julius's publishing workflow

In our website's article-publishing workflow, saving content in the CMS is not enough to mark publication as verified. The runbook also requires checks of both public language versions and their appearance in the sitemap and RSS feeds. If public verification is still outstanding, a pending state is retained before another article is added. These are documented steps in our own process, not claims about hours saved or improved search rankings.

The example illustrates that automation does not remove the need to define and verify the outcome. Some checks run through automated tools, but someone still needs to specify acceptable results and what happens when evidence is missing. An estimate covering only insertion into the CMS would leave out work needed to know that readers can actually access the article. The same question is useful when examining other business processes.

Test the value before expanding

Choose a set of cases representing ordinary work and known exceptions. Compare total time to a correct outcome, correction volume and work waiting for a person. Do not measure only output-generation speed. In an AI product, a convincing answer may still need review; our guide to choosing AI developers discusses defining quality and failure cases. Check whether the person continuing the workflow understands the information the system hands over.

For a conversation with Julius about software development, bring an ordinary case, a difficult case and a description of who handles each today. Request a proposal separating the automated action, remaining work and controls after release. This helps choose development scope according to the actual change in work, and avoids a savings promise based only on the portion that is convenient to demonstrate.