Why automation projects fail: three wrong assumptions

Automation projects rarely fail on the integration. They fail because the workflow encodes an assumption about how people behave, and the assumption is wrong in a small, specific way that testing cannot reveal. The three that cost the most are treating a field edit as a decision, treating a customer reply as a command, and trusting your own inventory of what already exists. Each one passes every test you write, because you test like someone who knows what the system expects.

The failure is in the model of the human, not the code

Read the postmortems and the technical causes look almost boring. An API changed. A credential expired. A record did not sync. Those are real, and they are the failures teams are already good at catching, because they announce themselves.

The expensive failures are quieter. They happen when the workflow's picture of a person is slightly wrong, and reality keeps supplying inputs the picture does not account for. Peer-reviewed research on automation implementation puts process-related problems first among five categories of challenge, ahead of the technological ones, and includes a detail worth sitting with: the employees performing a process often have limited conscious understanding of what they actually do. Ask an office manager how she books an appointment and she will describe a clean sequence. Watch her do it and you will see something messier.

That gap is where projects die. Not in the integration layer, in the six inches between how work is described and how it is performed. Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, and the pattern is not that the models got worse.

So the useful question during a build is not "does this work." It is "what am I assuming a person will do here, and have I watched anyone actually do it."

Wrong assumption one: a field edit is a decision

Your automation watches a record. A field changes. It fires.

Here is what actually happens on the other side of that record. An operator opens an appointment, sets the date, glances at the calendar, realizes the time is wrong, and fixes it. Elapsed time, about eight seconds. To the automation that is two change events, so it books the first version, sends a confirmation, then reschedules and sends a second confirmation. The customer now has two texts and a reason to call and ask which one is real.

The naive fix is to debounce on the field you care about. The better fix is to accept that a human edit is a burst, not an event, and wait for the burst to finish. On a scheduling system we run for a New England window and door replacement contractor with two brands across two states, the sync waits about thirty seconds after a time change before acting. That number is not arbitrary and it is not a performance tradeoff anyone regrets. It is roughly how long it takes a person to set a date and then correct themselves.

The general form: any time a workflow triggers on a change made by a human in a user interface, ask whether that change is likely to arrive alone. Status transitions usually do. Dates, times, addresses and anything with a paired field usually do not. Set the delay to the length of a real edit, not to a round number that sounded safe.

This is the same class of problem as an automation overlapping its own previous run, and it belongs in the same review as the rest of your scheduling and dispatch logic.

Wrong assumption two: a customer reply is a command

You send a confirmation text that ends with "reply YES to confirm." So you check whether the reply starts with yes.

Customers do not write commands. They write sentences. "Yes today between 2 and 4 would be great" begins with yes, so first-word matching records a bare confirmation and throws away the only part of the message that contained new information. Nobody sees an error. The appointment is confirmed, the customer believes they have communicated a time window, and the crew arrives at the wrong hour.

We hit this exact failure once, traced it to first-word classification, and fixed the class rather than the instance. Matching now runs against the entire message body, case insensitive, tolerating trailing punctuation, so an exact command is treated as a command and anything longer is treated as a message from a human being and routed to a person with its full text intact. The old first-word value is still written to the record, which costs nothing and makes the next debugging session much shorter.

Worth being honest about the edge that remains: a one-word reply with a trailing emoji still routes to the general branch rather than the command branch. We know, it is on the list, and the cost of that miss is a forwarded message rather than a wrong action, which is the correct direction for an unhandled case to fail in.

The pattern to copy is not the string matching. It is the default. Decide what happens to input your rules do not recognize, and make that default "hand it to a human with everything intact" rather than "pick the closest match." An agent that guesses is worse than an agent that escalates, which is the same argument that governs what to do when an AI agent has no matching tool.

Wrong assumption three: your inventory of what exists is accurate

The third one is the least discussed and the most dangerous, because it does not come from misunderstanding your users. It comes from misunderstanding your own system.

Before rolling out a change to the identity model on that same build, we reviewed every live workflow rather than the ones we expected to be affected. The result was not what anyone predicted. Twelve workflows needed changes. Twenty two were genuinely unaffected. And three that looked broken turned out to be correct on inspection and were deliberately left alone.

That third number is the one that matters. Three working things were one confident afternoon away from being "fixed" into breakage, by an engineer with good intentions and an inaccurate mental map. The audit also turned up a node that looked like existing coverage for exactly the case we were worried about, and was in fact disabled and disconnected from the flow. It had been sitting there long enough that its presence in a screenshot had become evidence.

The lesson is not "document more." It is that the inventory in your head has drift, and structural changes are the moment that drift becomes expensive. Read the live system before you change it, classify every component as needs-change, verified-correct, or not-applicable, and write down which is which. The verified-correct list is the valuable output, because it is the list of things you now know not to touch.

How to find your own wrong assumptions this week

Three exercises, each under an hour, each aimed at a different assumption.

Replay a week of real customer replies through your matching logic and count how many were classified as a command. Then read the ones that were not, and ask what your workflow did with the information in them. This finds assumption two immediately.

Pull the last ten appointment or record edits your office made and look at the change history rather than the final state. Count the separate change events per edit. If the average is above one, and it usually is, you have assumption one and probably a customer who received two of something.

Open your automation platform and list every active workflow, then compare that list to the one you would have written from memory. The gap in either direction is assumption three. Extra workflows you forgot are risk. Missing ones you were sure existed are worse.

None of this requires new tooling, and all of it is more productive than another round of testing the path you already know works. The failure modes that survive to production are the ones that only appear when real people touch the system, which is also why automations tend to break silently rather than loudly.

What to do next

Take the automation you would least like to explain to a customer, and write down the one sentence that describes what you assume a person does right before it fires. Then go watch someone do it, or read the change log of the last ten times it happened. You are looking for the gap between the sentence and the record.

If the two do not match, you have found the next thing to fix, and it will be cheaper than the integration work you were about to schedule instead. If you would rather have someone do that review with you, tell us what the workflow is and we will look at it against the same three assumptions.