What Should a Company Automate First? Start With a Handoff.

Most companies don’t start thinking about automation because they have a perfect process map. Usually it’s because someone on the team is doing the same annoying thing over and over again and everyone is tired of it. So the obvious answer is: automate that.

Sometimes that is the right move. But just because something repeats does not mean it is a good place to start. I would look for the handoff instead.

A handoff is the moment work has to move from one person, place, or system to another. An inquiry comes in and someone has to figure out where it goes. A meeting ends and somebody has to turn the decisions into actual work. Research gets collected and has to become something another person can use.

Those little transitions are where a surprising amount of time, confusion, and dropped work tends to hide. They are also often much easier to define, measure, and improve than something broad like “automate marketing” or “use AI for sales.”

Why I start with the handoff

You can choose an automation by looking for the task that happens most often, the one that takes the most hours, or the thing everyone complains about. Those are all useful signals, but they do not tell you whether the work is actually ready to be automated.

A handoff gives you more to work with. Something comes in. Something needs to happen to it. Someone is responsible for what happens next. And when the handoff fails, you can usually see the failure. The inquiry sits for two days. The wrong person gets assigned. Someone has to copy the same information into three places. A task never makes it out of a meeting. A report gets rebuilt because nobody can find the last version.

That makes the problem easier to see, and eventually easier to measure. But there is another reason I like handoffs: they expose all of the little decisions the company has been making informally.

That is also what can make them messy. The person handling a request today may know, without thinking about it, that this customer always goes to Sarah. Or that anything mentioning a distributor should go to Richmond. Or that the CRM is technically the system of record, except everyone knows the spreadsheet is more current.

Put automation in the middle of that and suddenly all of those unwritten rules matter. So finding the handoff is not the same thing as deciding it is ready. It is where I would start looking.

Follow one request all the way through

Take something simple: an inquiry comes through a company website. At first glance, this seems like an easy automation. A message comes in, the system figures out what it is about, and sends it to the right person.

But if I were actually building that workflow, I would not start with the automation. I would follow one real inquiry from the moment it arrives until someone owns the next step.

The first question is where the workflow actually begins. Maybe inquiries come through the website form. But maybe customers also email sales@, send messages through LinkedIn, or contact someone they already know directly.

If you automate only the website form while half the real requests arrive somewhere else, you have automated a channel, not the process. So make the boundary clear. For the first version, maybe website inquiries and anything sent to sales@ enter the workflow. Direct emails stay outside it for now.

That is a real operating decision. It is also the kind of decision that gets skipped when a company starts with the tool instead of the job.

Decide what the system needs to know

Now an inquiry has arrived. Before anyone routes it, what does the person handling it normally look up? Is this already a customer? Who owns the relationship? What service or product are they asking about? Is there already an opportunity open? Are they in a market the company serves? Has somebody on the team already been talking to them?

Now you have another decision to make: where does that information come from?

If the CRM says one thing and somebody’s spreadsheet says another, I would fix that before automating the handoff. Otherwise you are not removing confusion. You are making the confusion move faster.

For this workflow, maybe the CRM becomes the source of truth for customer status and ownership, while the incoming message is the source for what the person is asking about right now. That is enough to start giving the workflow some structure.

Then decide what kind of request it is

Now we can classify the inquiry. Not into twenty categories because an AI model can generate twenty categories, but into the handful of categories that actually change what the company does next.

Maybe that is new sales, existing customer, billing, partnership, vendor, employment, media, and unknown.

The point of classification is not organization for its own sake. Each category needs to lead somewhere different. An existing customer may go to the person who owns the account. Billing may go directly to finance. A new sales inquiry might route by territory. A partnership request might need one of the founders.

An unknown request should not get shoved into whichever category the system thinks is closest. It needs somewhere else to go.

Now we are getting close to a workflow that can be automated because the company has actually decided what the normal path looks like.

Decide what the system can do without asking

This is the part I think matters most. Just because a workflow can take an action does not mean it should.

For this inquiry process, I might be completely comfortable letting the system gather account information, classify a request, create a work item, assign an owner using an approved rule, prepare a short summary, and notify the person responsible. I might also let it send a basic acknowledgment that says the request was received.

Those are low-risk, reversible actions.

I would not let that same workflow approve a discount, accept a contract term, promise a delivery date outside an approved range, make a regulatory decision, or commit the company to something financially significant. Those decisions still belong to someone with the authority to make them.

This is why I do not automatically choose the highest-value process as the first automation. The work with the biggest financial impact often has the biggest consequences when something goes wrong.

You do not need your first automation to solve the hardest decision in the company. In fact, a lot of good first automations do not need AI making important decisions at all. The system can gather, organize, route, record, and prepare. A person can still decide.

The exception path tells you whether the workflow is really ready

The normal path is usually easy to draw. The more important question is what happens when the request does not fit it.

Suppose the system cannot confidently tell whether something is a sales inquiry or a partnership request. What happens next?

“Send it to a human” is not enough. Which human? Where does the request appear? How quickly should it be reviewed? What information does that person need in order to decide?

Maybe uncertain inquiries go into one review queue owned by the operations lead. Maybe anything involving an existing customer with no clear account owner gets escalated to the commercial lead. Maybe anything legal or regulatory skips the normal workflow completely and goes directly to an authorized reviewer.

Now the system has somewhere safe to put uncertainty instead of pretending it does not exist.

And I would track those exceptions. If “distributor inquiry” lands in the exception queue twelve times over the next month, it probably should not be an exception anymore. That is the company learning something. Add distributor inquiry as a normal category. Decide where it goes. Update the workflow.

I would actually put a review date on the first automation before it launches. Thirty days later, look at what got escalated, what got corrected, where people overrode the system, and which exceptions kept repeating.

A workflow should not stay frozen just because the first version technically works.

Keep the decision with the work

There is one more piece I would want before trusting this workflow: a record of what happened.

If the system classified the inquiry and routed it to someone, that should be visible on the work item itself. You should be able to see the original request, the information used to understand it, the category, the assigned owner, whether it hit an exception, and what happened next.

If a person changes the route, I would want that visible too. Three weeks later, nobody should have to search an AI conversation to figure out why a partnership request ended up with sales.

The record belongs with the work.

That also gives you something to review later. You can see where the workflow is consistently right, where people keep correcting it, and where the process itself needs to change.

Then automate it in pieces

Even after all of that is clear, I would not necessarily automate the entire workflow at once.

I would start with the part creating the most rework. Maybe the first version simply brings inquiries into one place, attaches the right customer information, and creates a structured work item. A person still classifies and routes it.

Once the information coming in is consistently right, the system can start proposing a classification. Then obvious, low-risk categories can route automatically while anything uncertain still waits for review. After that, maybe acknowledgments, reminders, summaries, or follow-up tasks make sense.

The point is not to move slowly. The point is to automate the pieces you understand and earn your way into the pieces that require more trust.

That gives the company a chance to learn how the workflow behaves before it starts making more decisions on its own.

What the first automation should really teach you

The reason I like handoffs as a first place to look is not that every handoff is ready to automate. A lot of them are not.

I like them because they force the company to answer the questions that eventually matter in every automation anyway: Where does the work begin? What information do we trust? How do we decide what kind of work this is? Who owns what happens next? What can the system do without approval? What happens when it does not know? Where do we record what happened? When does an exception happen often enough that we need to change the normal process?

Those answers become useful again when you build the second workflow, and the fifth, and the twentieth. The technology will change. The operating decisions do not go away.

So if I were trying to decide what a company should automate first, I would spend a week paying attention to the places where work changes hands. Then I would pick one.

Follow it from beginning to end. Find the decisions people are making without realizing they are making them. Decide which ones belong in the system and which ones still belong to a person. Then automate the parts that should actually be automated.

Because the goal of the first workflow is not to prove how much AI can do. It is to make one part of the company work better without losing track of who is still responsible for the decisions that matter.