Most businesses do not need to automate more things. They need to stop asking people to remember the same thing in three different places.

That distinction matters. Automation built on a vague process simply moves confusion faster. A notification fires, a record gets copied, and the team still does not know who owns the next move.

The useful question is not, “Can software do this?” Nearly always, the answer is yes.

The useful question is, “Is this workflow clear enough that software can carry part of it without hiding the judgment that still belongs to a person?”

Here is the test I use.

Start with the trigger

Every automatable workflow begins with something observable.

A customer submits a form. A payment fails. A project reaches a date. A contract is approved. A shipment changes status. A team member marks a task complete.

If the trigger is “someone should probably notice this,” the process is not ready yet. You need a visible event that another system can detect and a person can explain.

This is why “automate our follow-up” is too broad. “When a qualified inquiry has no response after one business day, create a task for the assigned owner” is specific enough to design around.

The second version also exposes an uncomfortable question: how does the system know an inquiry is qualified? If the answer lives in one employee's head, that decision needs attention before automation.

Name the handoff

Most workflow problems are handoff problems disguised as data-entry problems.

One person finishes a quote, but nobody knows who approves it. A lead arrives, but it lands in a shared inbox. A customer asks for a change, but the request is not attached to the work already in progress.

Write down the handoff in one sentence:

“After [event], [owner] needs to do [action] using [information].”

For example: “After a quote is accepted, the project coordinator needs to schedule the kickoff using the signed scope, selected services, and promised start window.”

Now you can see what automation might do. It can create the task, attach the relevant records, and make the deadline visible. It cannot decide whether the scope is realistic unless you define that judgment separately.

Clear ownership is one of the best predictors that an automation will help instead of annoy people.

Look for a stable decision

Repetition alone is not enough. A task can happen every day and still be a poor automation candidate if the decision changes completely each time.

Good candidates usually have a stable shape:

  • The same kind of event starts the process.
  • The same person or role makes the next decision.
  • The same small set of facts informs that decision.
  • The result leads to one of a few known next steps.

That does not mean every case must be identical. It means the workflow has a recognizable center.

An accounts-receivable reminder may have unusual customers and unusual notes, but the basic loop remains stable: an invoice reaches a threshold, somebody reviews it, and the next contact is recorded.

By contrast, “review every strategic partnership opportunity” may be too open-ended for a first automation. The work might be valuable, but the judgment has not been narrowed enough.

Measure the cost of waiting

The strongest automation candidates are not always the most boring tasks. They are the points where waiting creates a measurable cost.

Ask what happens when the workflow stalls for a day:

  • Does a customer wait for an answer?
  • Does cash remain uncollected?
  • Does a project miss a dependency?
  • Does a manager make a decision without current information?
  • Does someone repeat work another person already completed?

If the only consequence is that a spreadsheet gets updated later, automation may still be useful, but it is probably not the first place to invest.

If the delay loses revenue, creates rework, or makes the customer question whether anyone is paying attention, the business case is clearer.

This is where a workflow becomes a software decision instead of a productivity wish.

Design for exceptions without worshiping them

Every team will tell you that its process is too complicated to automate. Usually, that means the exceptions are memorable, not that they are common.

Separate the normal path from the exception path.

The normal path might be: inquiry arrives, owner is assigned, response is due, outcome is recorded. The exception path might be: the owner is unavailable, the request is outside the service area, or the customer needs a custom review.

The system should make those exceptions visible and provide a safe handoff. It does not need to turn every rare case into a new branch in the main workflow.

If one unusual customer can force the team back into email, that is not necessarily failure. The goal is to make the common path dependable and the uncommon path honest.

Run the workflow by hand first

Before building an internal tool, run the proposed workflow manually for a short period. Use a shared list, a form, or a simple table. Record the trigger, owner, decision, exception, and outcome.

This is not busywork. It answers questions that software cannot answer for you:

  • Are the triggers actually visible?
  • Does the assigned owner have enough information?
  • Which fields are never used?
  • Which exceptions keep repeating?
  • Does the workflow change the outcome or only create more administration?

A manual trial also produces a better brief for custom business software. Instead of requesting “a dashboard and notifications,” you can describe the loop the system must support and the evidence that it is working.

When the workflow is still changing every few days, a prototype-to-production process can test the risky parts before the team commits to a larger application.

Automation should remove remembering

The best first automation is often surprisingly modest. It reminds the right person, carries context across a handoff, updates a source-of-truth record, or makes a stalled item impossible to miss.

That may not sound impressive in a sales demo. It is impressive on a Tuesday afternoon when nobody has to ask, “Who was supposed to handle this?”

Your workflow is ready when the trigger is visible, ownership is clear, the decision has a stable shape, delays have a real cost, and the normal path is understood well enough to test.

Start with that loop. Then let the software earn the right to do more.