Automate the Middle, Not Necessarily the Whole

Imagine a hypothetical enterprise team processing requests to change a customer’s subscription. Some requests are straightforward. Others contain an unclear promise, an unusual commercial arrangement, or a customer need that does not fit the available options.

From a distance, this looks like one workflow waiting to be automated. Up close, it is several different kinds of work sharing the same inbox.

My direct answer is this: automate the repeatable portions with clear inputs and bounded outcomes; retain human ownership where interpretation or commitments matter. Connect the two deliberately. The useful unit of automation is often a segment of work, not an entire process.

A workflow is not one kind of work

Enterprise automation services are part of Vahmine’s work. As a founder working across enterprise technology and SaaS products, I find it useful to resist the language of complete transformation when a narrower intervention might serve the business better.

Consider that hypothetical subscription request. Gathering account details, checking whether required information is present, interpreting the customer’s intention, authorising a change, and communicating the result are not equivalent tasks.

Some involve moving information. Some apply an agreed rule. Others require someone to accept responsibility for a choice.

Treating them as one automation project can hide those differences. It can also make the project unnecessarily large: a useful improvement waits for every difficult exception to be resolved.

I would rather draw the workflow as separate stretches. Where does information become ready? Where does interpretation begin? Where does a commitment become difficult to reverse?

Those boundaries reveal places where automation can help without pretending to replace the whole job.

Repeatability needs more than frequency

A task happening every day does not automatically make it suitable for automation. People may be reaching the same destination through different reasoning each time.

The repeatability I care about is more specific: given comparable inputs, can we describe the same acceptable action without relying on someone’s unspoken understanding?

In our hypothetical example, checking whether a request includes an account identifier could be repeatable. Deciding whether a loosely worded message authorises a particular subscription change may not be.

Constraints matter just as much. An automation needs a defined range of work, an available source of information, and limits on what it may change. If those are unclear, building faster execution can simply move the ambiguity elsewhere.

There is also a simpler question: should this task exist at all?

If two teams collect the same information because their forms evolved separately, connecting the forms may help. Removing the unnecessary collection might help more. I do not want automation to preserve work that a product or process change could eliminate.

The handoff is part of the product

Partial automation is sometimes treated as an unfinished destination. I see it differently. A deliberate human handoff can be a sound product boundary.

But “send it to a person” is not enough.

The person receiving the work should know what was requested, what the system has already done, what remains unresolved, and what action is expected next. They should not have to reconstruct the original task from scattered records.

In the hypothetical subscription workflow, an ambiguous request might pause before any change is made. The reviewer would receive the request and the specific ambiguity—not merely a generic failure message.

The return path matters too. After review, does the workflow continue, end, or wait for more information? Who owns it while it waits?

For enterprise SaaS, these are product questions, not just implementation details. They shape whether people can understand and operate the workflow. A clean automated segment with a confusing handoff is not a clean experience.

A practical boundary checklist

Before choosing what to automate, I would work through this checklist with the people responsible for the process:

• Remove: Is any part of the work unnecessary or duplicated?
• Separate: Which steps move information, apply rules, or require interpretation?
• Specify: Are the inputs, acceptable outcomes, and operating limits explicit?
• Bound: What may the automation change, and where must it stop?
• Assign: Who owns each unresolved case, including while it waits?
• Equip: What context does that person need to act without starting again?
• Reconnect: What happens after the human action is complete?
• Evaluate: Has total effort fallen, or has work merely shifted to reviewers?

I would use the answers to choose a modest, coherent segment first—not automatically the easiest isolated task, but one whose boundaries make sense to the people using it.

My aim is not to make human involvement disappear from a workflow diagram. It is to stop spending human attention on mechanical work while protecting the places where that attention adds meaning. Sometimes the best automation leaves a visible space for a person. That space is designed, not left over.