The automation agency pitch oversells, and oversold automation gets abandoned.
That is the central commercial problem in this category, and it is worth stating plainly because it shapes everything about how a business in it should be run. If you promise transformation and deliver a modest recovery of a few hours a week, the client feels misled even though the few hours were genuinely worth having.
I founded and run Hawk Eye AI, an automation agency for small and mid-sized businesses. What follows is what I have concluded about doing it honestly, including the parts that make it commercially harder.
The category has a credibility problem
Small business owners have usually been sold something like this before.
The pattern is familiar: promises of transformation, a demo that works flawlessly on clean data, a build that goes in, and then a slow failure as the system drifts out of sync with how the business actually works. Nobody owns it. It breaks quietly. Eighteen months later the business is back to doing it by hand and is now sceptical of the entire category.
The consequence is that the next honest vendor has to overcome the last dishonest one. That is not a complaint, it is a constraint to design around, and mostly it means being conservative in what you claim and specific about what you do not do.
Scoping against what actually costs the business
The wrong way to scope is from a product menu. The right way is from measured reality.
What I ask for is a week of tracked interruptions. Every time something pulls the owner or their team away from real work, what it was and roughly how long it took. Not estimated afterward, because estimates systematically smooth out the small frequent items that are usually the entire problem.
The results are consistently unglamorous. Missed calls. Follow up that did not happen. The same five questions answered repeatedly. Data retyped from one system into another. Scheduling back and forth.
Almost never is the answer the thing the owner assumed it would be. And the boring items are usually the valuable ones, because they are high frequency, well defined, and currently consuming someone whose time is worth considerably more.
Saying no to the wrong projects
Three categories I decline, and declining them is what keeps everything else working.
Processes nobody has defined. Automating one of these does not create consistency. It creates a system that is wrong in a new way, applied uniformly, and harder to inspect than the manual version. The person who used to adapt is now fighting the automation. If the variation is essential, the automation should stop where the judgment starts. If it is accidental, defining the process is the real project and often captures most of the benefit on its own.
Judgment work. Pricing an unusual job, handling a complaint, deciding whether to make an exception. Automating these produces responses that are wrong in ways that cost far more than the time saved.
Anything where being wrong is expensive and silent. Sending the wrong invoice, quoting the wrong price, confirming an appointment that cannot be honored. The test is not whether it can be automated. It is what happens when it fails, and how long before anyone notices.
Turning down work is commercially harder than taking it, which is exactly why it is uncommon and why it is worth doing.
Custom, and what that costs
Every build is shaped around how the business already works rather than asking the business to reorganize around a product.
This is a real cost. Custom work does not scale the way a product does, it takes longer to deliver, and it means carrying knowledge about each client's particular arrangement.
What it buys is adoption. A system that fits the existing workflow gets used. A system that requires the team to change how they work in order to save the owner time gets quietly abandoned by the team, and the owner finds out months later.
For a small business with no capacity to absorb a change management project, fitting the existing process is not a nicety. It is the difference between a system that runs and a system that does not.
Managed rather than delivered
Systems break. An API version gets deprecated, a form field gets renamed, a process changes and the automation does not.
An automation that fails silently is worse than not having it, because the business has stopped doing the thing it replaced. They are not checking voicemail any more, because the system handles it. When the system stops handling it, nobody is checking anything.
So builds are managed rather than delivered and abandoned. That is a genuine ongoing obligation and it should be priced as one rather than treated as an upsell. A vendor who sells a build with no maintenance is selling something that has a shelf life they have not disclosed.
The related discipline is monitoring. Anything whose failure would be quiet needs a check: a count that should match, a report of items processed, an alert when volume drops unexpectedly.
Structuring engagements
Onboarding runs through three tiers, Foundation, Growth, and Premium, which differ in how much of the system is built and how much is managed.
The point of tiering is not price discrimination. It is that businesses arrive at different levels of readiness, and putting an unprepared business into a large build is how you produce a failed project. A business whose process is undocumented and whose CRM is empty is not ready for a full automation stack, and selling them one serves nobody.
Current scope is on hawkeyeai.io. I am deliberately not discussing pricing here.
What the accounting background contributes
Two things, and they are the reason I think the work is any good.
Knowing where automation must stop. Approvals, exception resolution, anything that creates an obligation or moves money stays with a person. That instinct comes from having to defend a control environment to an auditor, and it is not obvious from outside the discipline. A lot of well built business automation quietly removes controls that mattered, and nobody notices until something goes wrong.
The diagnostic habit. What triggers this, and is the trigger reliable. What happens when the usual person is not available. What does failure look like, and would anyone notice. Those are close process questions and they work equally well on a service business's intake workflow.
The honest scoreboard
A small business that automates the right four or five things recovers several hours a week and closes a category of work it was losing invisibly. That is real and it is worth paying for.
It does not remove the need for people. The work that remains is the work that genuinely required a person, which is usually the work worth doing.
Scoping to that produces systems that stay in place for years. Scoping to the transformation pitch produces systems that get abandoned, and makes the next honest attempt harder for everyone.