How to Decide What Requests to Automate

A business can ask how to decide what requests to automate while already asking for one intake form. I start with the question of how to decide what requests to automate, because the form shouldn't define the process before the process is clear.

A single intake form can hide different kinds of work

A single form can collect requests that look similar at the point of entry but need different decisions afterward.

One request might have a known owner and a next step that happens the same way each time. Another might need someone to check the details before deciding whether it belongs with that owner at all. A third might be a request that doesn't fit the existing work, even if the form has a field where someone can describe it.

That difference matters before I choose fields, notifications, or automation rules. If the same form accepts all of these requests, the workflow has to carry the uncertainty somewhere. Usually, that means a person checks the request manually after submission, works out where it belongs, and repairs the path when the request doesn't match the assumptions behind the workflow.

The form may look simple to the person submitting it. The work behind the form may not be simple at all.

How I decide what requests to automate

I look for requests that are repeatable and have a known next step. The request should meet a clear condition for entering the workflow, and the workflow should be able to move it to the right next action without someone interpreting the request from scratch.

That doesn't mean every detail has to be predictable. It means the important decision has already been made. I should be able to describe what qualifies, who owns it, and what happens after it enters the process.

If the request needs judgment before those things are clear, I don't treat it as an automation candidate yet. I leave room for a person to review it first. That review might determine whether the request belongs in the workflow, what information is missing, or whether the work should follow a different path.

This is where business process intake often goes wrong. The intake form is built first because it feels like a visible starting point. But the form can't make an unclear process clear. It can only collect the uncertainty and pass it to the next person.

I decide on the boundary before I decide on the form. Accepted request types can then have a direct route into the workflow. Requests that need judgment can have a separate route instead of pretending they are ready for automation.

A catch-all workflow makes exceptions everyone’s work

Accepting every request creates more work than the form suggests.

Someone has to check whether the request belongs in the workflow. If it doesn't, someone has to reroute it. If the request entered with the wrong information, someone has to repair it before the next step can happen. When the workflow is designed around a common request, every exception adds another decision that the workflow wasn't built to make.

That cost doesn't always show up as a broken automation. The workflow may continue moving requests forward while people quietly correct it along the way. The process appears to be working because the exceptions are being handled manually.

Over time, the manual checking becomes part of the process. The person responsible for the workflow has to watch the intake, interpret unusual requests, and keep the wrong work from reaching the wrong owner. The automation hasn't removed the decision. It has moved the decision into a less visible part of the job.

I don't want to build a catch-all workflow that depends on someone cleaning up after it. If a request type needs a different decision, it should be visible as a different path.

Some requests should stay outside the workflow

Some requests shouldn't enter the workflow at all.

A request can be valid and still be a poor fit for a fixed process. It may need a direct conversation before anyone can define the work. It may be unusual enough that forcing it into a standard request type would hide the important part of the decision. It may also belong to work that hasn't been defined well enough to automate.

In those cases, I prefer an exception path or a direct conversation. That isn't a failure of the intake process. It's a way to keep unclear work from being presented as routine work.

The boundary should be clear to the person handling intake. If a request doesn't meet the entry condition, it shouldn't be pushed through because the form happens to accept it. The process needs a place for requests that fall outside the accepted types.

Keeping those requests outside the workflow also protects the workflow that does exist. The repeatable work can stay repeatable, while the unclear work gets the attention needed to decide what should happen next.

I test the boundary with real request examples

Before I automate intake, I test the proposed boundary against real examples from the intended work. I take each request type and ask whether it has a clear entry condition. Then I ask what the next action is once it enters.

If I can't answer those questions without adding another manual decision, I don't treat the request as ready for the workflow. I check whether the problem is missing information, an unclear owner, or a request type that shouldn't be included in the first place.

I also test examples that are close to the boundary. A process can look clear when it only handles the common case. The useful test is whether a request that sounds similar but needs a different decision can be identified before it enters the wrong path.

This gives me a shorter and more honest intake process. The accepted request types have a clear route. Anything else has a clear place to go before it becomes workflow work.

The test ends with a short list of accepted request types and a clear place for anything that falls outside it. I make that decision before building the form, because accepting every request turns exceptions into the process.