Before You Automate, Decide What Good Work Looks Like

Automation is most useful when a business can distinguish a correct outcome from an incorrect one. If employees disagree about when a request is approved, which information is required, or who should resolve an exception, software will inherit those disagreements. Before investing in faster execution, an owner should establish what acceptable work looks like and who has authority to define it.

Describe the outcome before the steps

A hypothetical property maintenance business wants to automate supplier approval. Its current process involves collecting documents, reviewing service categories, and asking a manager for confirmation. The immediate temptation is to reproduce these steps in an application. The more important starting point is the required outcome: a supplier may receive work only after the business has completed its agreed checks.

Document what counts as a complete approval, what evidence is required, and when approval must be reviewed. Clarify whether different categories require different information. The exact requirements belong to the business and any applicable professional advice; the software team should not be expected to invent them.

This separates necessary controls from habits. A repeated email asking whether a document has arrived may be a workaround. A review by an authorized manager may be essential. Making the distinction helps the business automate coordination while preserving decisions that deserve human attention.

Find where current practice diverges

Follow several recent cases with the employees who handled them. Include a normal approval, a rejected application, and a case with missing information. Compare what people actually did with the written procedure. Differences may reveal outdated instructions, unclear responsibility, or sensible exceptions that were never recorded.

The Government Data Quality Framework recommends addressing causes at source and assigning accountability for data quality. Applied to this example, the lesson is to understand why supplier records are incomplete before automating reminders about them. Faster reminders will not settle disagreement over which documents are needed.

Avoid assuming that variation always represents poor work. An experienced employee may adapt a process to a customer or supplier circumstance that the official procedure overlooks. Discuss whether the variation should become an agreed exception, disappear through simplification, or remain a matter for professional judgment.

Establish a decision boundary

Decide which actions can follow an explicit rule and which require review. A system might identify missing information and prevent a premature status change. A person might assess an unusual document or determine whether an exception is appropriate. Record who owns that judgment and what should be retained afterward.

For the maintenance business, “all fields completed” should not automatically mean “approved” unless that is the agreed policy. Information can be present without being sufficient. Define the distinction in business language and have staff test it using realistic cases.

Consider reversals and expiry as well as initial decisions. If a supplier's approval changes, what happens to planned work? Who is notified, and which records remain available? Automation should support the full consequence of the decision, rather than only the moment an employee presses an approval button.

Make acceptance observable

Turn agreed outcomes into examples that the delivery team and business reviewer can use together. A complete application should reach the appropriate reviewer. An incomplete one should show what is missing. An unauthorized employee should not be able to approve it. An exception should follow the agreed route and remain understandable afterward.

The Government Digital Service describes acceptance criteria as outcomes used to confirm that a service meets a need in its user-story guidance. For an owner, the practical benefit is a shared definition of completion that goes beyond whether a new screen exists.

Measure the process after introduction. Review time awaiting action, repeated requests for information, and cases returned for correction. Interpret results alongside changes in workload and staffing. A shorter processing time is useful only if the business continues meeting its required standard of work.

Build agreed rules into a maintained product

Holism combines AI-assisted development, a Software Product Line foundation of reusable capabilities, and a human developer. Once the business has clarified its rules, AI can help implement and refine the workflow. Reusable capabilities provide a consistent starting point, while the developer decides how information, permissions, and exception paths should work together.

The owner remains responsible for business standards and priorities. The developer supplies engineering judgment and continuing technical direction, helping the owner avoid becoming the person who must maintain the system personally. This division is particularly valuable when an approval process must evolve without creating a different interpretation in every part of the product.

Good automation begins with agreed outcomes, explicit responsibility, and examples of acceptable and unacceptable work. With those foundations, speed serves the business's standards. Without them, faster execution can simply make an unresolved process harder to supervise.