Why I Turn Down Automation Projects Without a Support Plan

The Question That Makes Discovery Calls Uncomfortable

There's a version of this conversation I have on nearly every discovery call, and it usually goes the same way.

I explain that once a system is built and handed over, the client owns it. I'm not required to babysit it. I document everything — how it works, why it's built the way it is, what to check if something looks off. Most clients are relieved to hear this. They don't want to be locked into a consultant forever.

Then I ask the follow-up question, and this is where the conversation gets uncomfortable: "If this breaks at 9am on a Monday and it's blocking your team from submitting orders — who fixes it?"

Sometimes the answer is confident: "Our IT person can handle it," or "We have someone who's technical enough." Good. That's a real answer, and we move forward.

But sometimes the answer is silence. Or "I guess we'd figure it out." Or "We'd just go back to the old way for a bit."

When that's the answer, I don't build the system. Not because I want the retainer. Because building it anyway would be handing someone a liability and calling it a solution.

An Automated Workflow Is Not a Document. It's an Employee.

This is the part that gets lost in how automation gets sold. A workflow that submits data, routes approvals, sends notifications, and updates dashboards isn't a static tool sitting quietly in the background. It's doing a job — the same job a person used to do, or the job several people used to do together. It works continuously. It touches real data, real approvals, real money moving through a real company.

Treat it like an employee for a moment, because that's functionally what it is. Every employee has a manager. Every employee, no matter how good, occasionally makes a mistake or hits a situation they weren't trained for. When that happens, someone notices, someone steps in, and someone fixes it. Nobody hires a person and says "you're on your own indefinitely, good luck."

But that's exactly how a lot of businesses treat their automated systems. Built once, deployed, and then left with no one assigned to notice when it stops behaving the way it should.

Every Workflow Eventually Hits an Error. That's Not a Flaw — It's a Certainty.

Servers go down. In October 2025, a major outage at Amazon's cloud servers — the infrastructure that quietly runs a huge portion of the internet — knocked out Slack, Zoom, banking apps, and thousands of other businesses for several hours. If your automation depended on a service running through those servers, it stopped too, and there was nothing wrong with how you built it.

A form that used to always capture every field starts arriving with gaps, because a new employee filled it out slightly differently than the training covered. An edge case nobody anticipated during the build finally shows up in month four, when a client submits an order type nobody thought to plan for.

None of this means the system was built badly. It means the system is doing real work in a real business, and real work eventually runs into situations nobody planned for. This is true whether the workflow uses AI or not — deterministic automation breaks just as often as anything else, usually from something upstream changing quietly.

The question was never if something will need attention. It's who is paying attention when it does.

The System Serves People. The Accountability Should Match.

Every system exists because it serves actual people. A field agent who needs their expense reimbursed. A finance team that needs clean numbers to close the month. A manager who needs to trust the dashboard they're making decisions from.

When the system breaks and nobody's watching, it's not an abstract technical failure. It's the field agent whose reimbursement is now stuck. It's the finance team back to manual reconciliation because the automation silently stopped updating. It's the manager making a decision off data that's three days stale and doesn't know it.

The people the system was built to help are the ones who feel it first when the system fails unattended. That's the accountability gap, made concrete.

So I Ask the Question, and I Mean It.

Before I build anything, I need an honest answer to who owns the system's health after I'm not the one checking it daily.

• An internal hire or existing technical staff member who owns system health
• A support retainer with me for monitoring, fixes, and adjustments
• A clear self-monitoring plan, with documentation detailed enough that a competent person on the team can follow it

Building Responsibly Means Building for After Launch

What doesn't work is no answer at all. A system with no one accountable for it isn't a finished project. It's an unattended risk with a head start.

If a business isn't ready to answer that question, the honest move isn't to build the system anyway and hope for the best. It's to have the conversation first — because the alternative is delivering something that looks like a solution and behaves like a liability the first time it needs a human to step in.

I build custom automation systems and operational portals for Philippine SMEs in trading, distribution, manufacturing, and field operations. Every engagement includes a real conversation about who's accountable for the system once it's live.