An Automation Backlog Needs a Delete Column

Imagine a hypothetical enterprise team preparing a weekly account-status pack. Someone exports records, someone reconciles the labels, and someone assembles a presentation. The automation proposal seems obvious: connect the systems and generate the pack automatically.

But there is another possibility. Perhaps the recipient only needs to know which accounts require a decision. The pack may be an elaborate answer to a question nobody is asking anymore.

My direct answer is this: before choosing what to automate, sort the work into four categories—stop, simplify, automate and deliberately keep human. Repeatability matters, but only after the task has earned its place.

Give the task a reason to survive

Enterprise automation services are part of Vahmine’s work. As a founder working across enterprise technology and SaaS product building, I think the consulting responsibility begins before the implementation proposal.

A request to automate is not necessarily a request to preserve everything the team currently does.

I would first ask: what changes because this task is completed? Does someone make a decision, receive something they need, or move work forward? If the answer is unclear, I would not immediately treat that uncertainty as a technical requirements problem.

In the hypothetical account-status example, the presentation might support a real decision. Or it might be a familiar ritual whose purpose has narrowed over time. Those possibilities lead to different product choices.

Removing a task should not be casual either. Someone may depend on it in a way the requester cannot see. Before proposing that work stop, I would identify its recipients and ask what would become harder without it.

The point is not to celebrate deletion. It is to avoid building a reliable machine for producing an unnecessary output.

Separate repetition from avoidable rework

Once a task has a clear purpose, I would examine why it repeats.

Some repetition is inherent: each new request needs routing, each completed step needs recording. Other repetition comes from a preventable mismatch: a field is missing, labels differ between systems, or the same information is requested twice.

These deserve different responses.

In our hypothetical example, automating label reconciliation could make the weekly preparation easier. But if the team can agree on a shared definition at the point of entry, the reconciliation task might shrink or disappear.

That is a simplification decision before it is an automation decision.

For the remaining work, repeatability means more than frequent occurrence. I want to know whether comparable inputs can reasonably produce comparable outputs, whether those inputs are available, and whether completion can be recognised without guesswork.

A task can happen every day and still depend heavily on interpretation. Frequency alone does not make it a good candidate.

Keep people where their contribution matters

I would not describe every retained human step as an automation gap.

In the hypothetical account-status process, software might prepare a shortlist from agreed criteria. A person might still decide whether an account needs attention, because the decision involves competing priorities that the shortlist does not resolve.

The handoff should carry the relevant context, not merely a notification saying “review required.” The recipient needs to understand what was prepared, what remains uncertain and what decision is theirs.

This also exposes constraints. Does the intended reviewer have time? Is the necessary information available? Can a mistaken action be corrected? Is maintaining the automation proportionate to the work it removes?

Sometimes the sensible choice is to leave a small, infrequent task manual. Sometimes it is to reduce the number of handoffs rather than accelerate each one. A useful consulting recommendation should allow both answers.

Review the work before approving the build

I would use this checklist with a proposed automation backlog:

• Purpose: What useful outcome depends on this task?
• Dependency: Who would notice if it stopped, and why?
• Simplification: Can we remove duplicate entry, unnecessary output or avoidable reconciliation?
• Repeatability: Are inputs, expected outputs and completion conditions sufficiently clear?
• Constraints: What limits the design—information, access, capacity, maintenance effort or reversibility?
• Human handoff: Who receives unresolved work, with what context and responsibility?
• Disposition: Should we stop, simplify, automate or retain the task—and what would make us reconsider?

I would record that last decision alongside the implementation backlog. Otherwise, only the tasks selected for building remain visible, and restraint disappears from the story.

The outcome I want is not a workplace in which every activity runs automatically. It is one in which necessary work becomes easier, unnecessary work is allowed to end, and human attention has a clear reason to be there.