Automations that look simple but always fail

“It’s simple: when an order confirmation email comes in, we pull out the order number, look it up in the ERP and update the status on the website.” That’s how the conversation started with a client who wanted to automate their order flow. 6 months later, the automation had failed dozens of times, every failure had needed manual intervention and the client was more stressed than before.

The problem wasn’t the technology; it was that the real process was more complex than it looked: inconsistent email formats, partial orders, returns that used the same type of email and template changes that broke the parser (the code that reads the message and extracts the data).

There are automation patterns we see fail again and again. They aren’t technical failures; they’re failures in analyzing the process.

Pattern 1: extracting data from emails

The idea is appealing: email is universal and looks simple. Reality is different:

Emails are inconsistent HTML. Some arrive neatly laid out, others with chaotic HTML generated from Word and others in plain text. Your parser has to cope with all of them.

Senders change without warning. The supplier switches email tools and confirmations arrive from a different address in a different format. The automation stalls until someone notices.

Body, attachments or links. The data might be in the body, in an attached PDF, behind an external link or in all three places at once, with conflicting information.

Human edge cases. The “order canceled” email uses the same template as “order confirmed”, with a single line changed. The parser marks it as completed when it should be marked as canceled.

A more robust alternative: direct API connections between systems whenever possible. When that’s not an option, structured formats (a CSV over SFTP, webhooks with JSON) rather than free-text emails. If you work with tools like Make or Zapier, here’s how to connect your website to Make/Zapier without building a time bomb.

Pattern 2: syncing data between systems

“I want the CRM and the ERP to have the same customers.” Sounds reasonable. The reality:

Incompatible data formats. The CRM has separate “first name” and “surname” fields; the ERP has a single “full_name” field. The CRM uses “ES” for Spain and the ERP uses “34” or “ESP” depending on the field.

Sync loops. A updates a customer and syncs it to B. B makes an automatic change (assigning a customer number, for example), which triggers a sync back to A and overwrites the original change. And round it goes.

Editing conflicts. Someone edits the same customer in both systems between one sync and the next. Which version wins? The most recent one isn’t necessarily the right one for the business.

Source of truth. Which system is in charge? If the ERP is the official financial system, perhaps certain fields should only be updated from there. Deciding this requires understanding the business, not just the technology.

Solution: a clear source of truth for each piece of data, “last modified” and “change origin” fields, and manual conflict resolution for the tricky cases. No blind syncing. We go into more detail in what a company gains when its systems stop working in silos.

Pattern 3: automating end to end processes that need judgment

A company had a 5-step customer onboarding process: check documents, create accounts in 2 different systems, send a welcome email based on customer type and notify the account team.

They automated all of it. The result: customers with incomplete documents were activated anyway, accounts were created in the wrong systems because the customer type classification failed, and the welcome emails ended up in spam because nobody had checked deliverability.

The mistake was automating decisions that needed human judgment.

Alternative: automate the mechanical steps (creating accounts, sending emails) and keep a human approval point before final activation. Semi-automation instead of full automation.

Pattern 4: integrating with APIs that “work fine”

“The supplier’s API is documented and it works.” Yes, in testing. In production:

Undocumented rate limits. The API accepts 100 calls a minute in testing. In production, with real volume, you start getting 429 errors (Too Many Requests) out of nowhere.

Unannounced downtime. The supplier restarts its servers on Sundays at 3 in the morning. Your automation fails silently and nobody finds out until Monday.

Unversioned changes. A field that used to be mandatory becomes optional and your validation breaks. Or a new field appears and your code ignores important data.

Ambiguous errors. The API returns a 200 OK, but the body says {“status”: “error”}. Or it returns a 500 with no body at all.

Solution: detailed logging, retries with increasing waits (exponential backoff), circuit breakers (if the API fails too often, stop trying for a while) and monitoring that alerts you when failures pass an acceptable threshold.

Pattern 5: scraping because there’s no API

Scraping (pulling data straight from web pages) is tempting when there’s no official API, but it’s fragile by design:

The HTML changes. A redesign of the site, a change in CSS classes or a different page structure, and your scraper stops extracting the right data, often without anyone noticing.

Anti-scraping measures. CAPTCHAs, request limits, IP blocks. The scraper works in development and fails in production once the site detects the volume.

Terms of use. Many sites prohibit scraping in their terms of use. They can block you technically and, in some cases, take legal action too.

Data designed for people. The page shows data formatted for reading, not structured data: “2 hours ago” instead of an exact date and time, “€1.2M” instead of 1200000.

Alternative: negotiate official API access (even if you have to pay for it), use structured public data if it exists, or rethink whether you really need that data automated.

Pattern 6: automating decisions based on incomplete data

“If the customer hasn’t bought anything in 90 days, send them a reactivation email with a discount.” Sounds logical. But:

• What if the customer bought in the physical shop and that purchase isn’t in the system?
• What if they don’t want to receive marketing emails?
• What if they’ve already had 3 reactivation emails and never opened any of them? Do we keep going?

The data you see isn’t the whole picture.

Solution: more context data, conservative thresholds and, always, respecting each customer’s unsubscribes and communication preferences, which is also a legal obligation.

How to build automations that don’t fail (or that fail well)

We’re not against automation: we use it all the time, but with precautions.

1. Understand the process before automating it. Watch how it’s done by hand for a few weeks, identify every edge case and keep asking “what happens if…?” until you run out of answers.

2. Design for failure, not for the ideal case. In a well-built automation, a large share of the code goes into handling errors, logging and recovering. The ideal case is the easy part.

3. Detailed logging. When something fails, you need to know exactly what happened: IDs, dates and times, the content of API calls. Debugging without logs is guesswork, and without documentation it’s even worse: we cover it in the hidden cost of poorly documented automations.

4. Monitoring and alerts. Set up alerts for when failures pass a threshold, when expected activity is missing or when data looks abnormal.

5. Fall back to manual. When the automation fails, it has to be easy to step in by hand without breaking anything and without getting stuck in a half-finished state with partial data.

6. Start simple and expand gradually. Automate the most common case first, with alerts for the exceptions, and add edge cases as they come up.

Frequently asked questions

How do I know if my process is stable enough to automate?

If it changes every week, has lots of exceptions handled by hand or needs constant judgment calls, it’s probably not a good candidate. Repetitive, well-defined processes are the best ones.

How much does it cost to maintain an automation?

As a rough guide, budget between 10% and 30% of the initial development cost per year for maintenance, adjustments and new edge cases. What matters is budgeting for it from the start and including it when you calculate the real ROI of the automation project.

What should I do if an automation keeps failing?

Reassess whether it’s worth it. Going back to a manual process is a valid option if the automation creates more work than it saves.

Conclusion

Automation is powerful, but it isn’t magic. Automations that look simple often hide complexity that only shows up in production. The key is to anticipate that complexity, design with failure in mind and keep expectations realistic.

If you’re thinking about automating processes and want an honest assessment of feasibility and real cost, tell us what you want to automate. We’d rather tell you up front “this is more complex than it looks” than “this doesn’t work the way you expected” 6 months later.