What we refuse to automate, and why

Most of what an automation firm publishes is about what it can build. This is the opposite: six categories of work we decline, including some where the client was willing to pay and the build was entirely feasible.

The reasoning matters more than the list. In every case the objection is not technical — we could build all of these. It is that the result would be worse than what it replaced, and the person paying for it would find that out later than we would.

1. Fake personal outreach

The single most requested thing on this list, and an automatic no.

The ask is always some version of: generate messages that look individually researched and written, at volume, so prospects believe a person studied their business before making contact. Sometimes it is dressed up as personalisation at scale. Occasionally it is explicitly "make it look like I wrote it myself."

We decline because the entire value of the message depends on a claim that is false. The recipient responds because they believe someone took the time. They did not. That is not personalisation, it is a small deception operating at industrial scale, and everyone who has been on the receiving end of it now recognises the pattern anyway.

What we will build instead: research assembly. Pull the prospect's recent news, funding, job postings and tech stack into a brief, so a salesperson spends two minutes writing something genuinely informed rather than twenty minutes finding out. The human still writes it. The claim stays true, and it works better.

2. Automated review and testimonial generation

Drafting reviews for customers to approve. Generating testimonials from support transcripts. Selectively routing happy customers to public review sites while unhappy ones go to a private form.

The first two are straightforwardly fabricating social proof. The third — review gating — is subtler, feels reasonable to a lot of people, and violates the terms of most review platforms. It also makes your rating meaningless as a signal, which is the thing you were trying to build.

What we will build instead: ask everyone, at a well-chosen moment, with a genuinely frictionless process, and route negative feedback to someone who can fix it — as well as, not instead of, the public request.

3. Anything that hides a human decision

Auto-declining applications while implying a person reviewed them. Automated "I've looked into this personally" replies. A system that sends apologies signed by a named individual who never saw the incident.

The objection is narrow and worth stating precisely: we are not against automating decisions. We are against automating a decision and claiming a human made it. Auto-decline with a clear, honest message is fine. Auto-decline dressed as considered human judgement is not.

What we will build instead: the same automation, honestly labelled. "Your application did not meet our criteria for X" is straightforward. "After careful personal review…" from a system is not, and it is precisely the phrasing that destroys trust when discovered.

4. High-stakes decisions with no verification path

This one is a judgement call rather than an ethical line, and we will build it when verification is possible.

Some tasks are consequential and produce no signal when they go wrong: financial coding, regulatory classification, permanent data deletion, compliance filings. Nothing errors, nothing looks unusual, and the mistake surfaces months later in an audit.

We will automate these only with genuine verification built in — a cross-check against an independent source, a reconciliation that would catch a discrepancy, or a human review step on anything unusual. If none of those can be built, we say no, because the failure mode is a quiet accumulation of errors nobody detects until it is expensive.

More on this in what should not be automated.

5. Automating around a broken process

The most common thing we turn down, and the one clients push back on hardest.

A business asks us to automate the reconciliation between two systems that disagree. The right answer is not to automate the reconciliation — it is to work out why they disagree. Usually two teams are entering the same data differently, and the reconciliation exists to paper over that. Automating it makes the underlying problem permanent and invisible, and adds a maintenance burden forever.

Same shape: automating a report nobody reads. Automating an approval step that has never resulted in a rejection. Automating data entry into a system being replaced next year.

What we do instead: say so, in the audit report, with the reasoning. Some audits conclude that a process should be simplified or dropped rather than built. Those are good outcomes even though they are smaller invoices, and a firm that never reaches that conclusion is not looking very hard.

6. Surveillance dressed as productivity

Keystroke logging, screenshot capture at intervals, "activity scores," idle-time reporting to managers, sentiment analysis on internal messages.

These are technically easy and consistently requested by someone who has just read about them. We decline for a practical reason as much as a principled one: they do not work. They measure activity rather than output, they reliably produce gaming rather than productivity, they poison the working relationship, and in several jurisdictions they carry legal exposure the buyer has not considered.

What we will build instead: measurement of work, not of people. Cycle times, throughput, where items sit longest, which stages generate rework. That tells you where the process is failing, which is the actual question — and it does not require watching anyone's screen.

The pattern underneath

Five of the six come down to the same thing: the automation would create a false impression. That a person wrote the message, reviewed the decision, left the review, or considered the case. The technology works fine; the deception is the product.

The sixth — automating a broken process — is different. Nothing dishonest, just expensive: it locks in waste and makes it harder to remove later.

We are not claiming unusual virtue here. These are the boundaries we have found produce work that is still working in three years, with clients who still want to talk to us. Automations that depend on someone not noticing tend to have short lives and unpleasant endings.

If you were going to ask for one of these

Ask anyway. Two reasons.

First, we may have misread what you want. "Personalised outreach at scale" sometimes means the research-assembly build described above, which we are happy to do and which works better.

Second, there is nearly always an adjacent build that achieves the underlying goal honestly. You want more reviews, faster hiring decisions, better visibility into your team's workload. Those are legitimate and solvable. It is usually only the specific implementation that is the problem, and the alternative is often cheaper.

What we will not do is take the money, build it, and let you discover the downside later.