Automation is only as good as the data feeding it

Automating a broken process just breaks it faster

The pitch for automation is that it removes manual work. It does. What it also does is remove the person who was quietly catching things: the account manager who spotted the duplicate before the invoice went out, the administrator who noticed the address was three years old.

Take that person out of the loop and every fault in the data becomes an action. Two records for one customer becomes two emails, or a renewal notice to a company that renewed last month, or a lead routed to a rep who left. The automation is working perfectly. That is the problem.

What it costs when it misfires at scale

• Customers receive things that are wrong, and the ones who notice are the ones who tell you.
• The team goes back to doing it by hand, because the automated version cannot be trusted, and now you pay for both.
• Nobody can explain why a particular thing happened, because the logic is spread across four tools and nothing logged the decision.
• The person who built it has left, and the reason for the rules left with them.

We fix the inputs before we automate the process

Check what the automation will be acting on

Duplicate rate, completeness on the fields the rules will read, whether the same customer means the same thing in each system. That is a CRM data audit, and it is the difference between automation that saves time and automation that generates apologies.

Map the process as it really runs

Including the exceptions, which is where every automation project actually fails. The documented process is rarely the one being followed, and the gap is usually the thing being automated.

Build it so it can be explained

Validation on the way in, logging on every decision, clear conditions rather than nested cleverness. When something happens six months from now, someone who was not there has to be able to say why.

Connect the systems properly, once

Most automation problems are integration problems wearing a costume. If the same customer exists three times across CRM, finance and marketing, no workflow will fix that. That is integration and cleaning work, and it comes first.

Why this is hard to do in-house

• The tools make the first automation easy and the fiftieth unmanageable, and nothing warns you when you cross over.
• Testing an automation properly means testing what it does to the exceptions, and the exceptions are the part nobody has written down.
• A workflow that fires on bad data fails silently. It does not error, it just does the wrong thing quietly and at volume.
• Whoever builds it has to understand the commercial process and the platform, and those are usually two different people.

What we actually do

Automation design workshop

A focused session to find where automation genuinely reduces manual work rather than moving it, and where it would just make an existing problem faster. You leave knowing what to automate, what to fix first, and what to leave alone.

Integration scoping session

A structured scope for connecting CRM with finance, forms, marketing, reporting, comms and operations. What moves, in which direction, which system owns which field, and what happens when they disagree.

Automation build sprint

A defined delivery sprint where agreed automations and integrations are built, tested and documented. Best when the scope is already clear and the decisions are made.

Automation club

A monthly reserved block for teams that want continuous improvement without raising a project every time. Included in the managed service from Kestrel upwards.

We work in Zapier, Make, HubSpot, ActiveCampaign and Pipedrive, and hand over documentation whichever it is.

What it looks like once it is working

The manual step is genuinely gone

Not moved to someone else, and not replaced by a weekly check that the automation did what it said.

You can find out why something happened

Every run is logged and every rule is written down, so an odd result is a question with an answer rather than an argument.

It fails loudly

When something upstream changes, the automation stops and says so, instead of carrying on against data that no longer means what it did.

New requirements are a change, not a rebuild

Because the logic is documented and the systems agree on what a customer is, the next thing you need is an addition rather than an archaeology project.

Questions people ask before starting

Can you just build the automation we have specced?

Usually yes. We will look at what it reads first, because an automation built on unreliable fields is the one that gets switched off in month three.

Which tools do you work in?

Zapier, Make, HubSpot, ActiveCampaign and Pipedrive, plus direct API work where a platform will not do what is needed. The choice follows the process, not the other way round.

What happens when it breaks?

It is logged and it alerts. On a retainer we are the ones who notice. Without one, the documentation is written so your team can.

Do we need integration first?

Often, yes. If the same customer exists separately in three systems, a workflow cannot reconcile that. CRM data integration is the fix, and it makes everything built afterwards simpler.

Is AI automation different?

The dependency is the same and sharper. A model acting on incomplete records produces confident, wrong answers faster than a workflow does. Only 8.6% of businesses are currently AI-ready (Huble AI Readiness Research 2025), and the gap is a data gap rather than a technology one.

Automation needs maintaining, because everything around it moves

Platforms change their APIs, teams change their process, a field gets renamed and a rule that depended on it stops matching. None of that announces itself. Automation that stays trustworthy is reviewed on a rhythm alongside the data health it depends on, which is the whole argument for keeping someone on it.