A billing query comes in from a long-standing client. They want to understand a line item on their last invoice. Your automated system picks it up, matches it against the billing record, generates a clear explanation, and sends it within minutes. Fast, accurate, professional.

The system did not know that the client's business had been struggling and had lost two major contracts that quarter. The person sending the query may have been working towards a conversation about deferring payment, restructuring the engagement or reducing scope. The billing query was an opening that needed someone to read the context, pick up the phone and ask: "How are things going? Is there anything we should talk about?"

Instead, they received a perfectly formatted response to the literal question and no invitation to discuss the wider situation. A client may never complain about that kind of miss. The signal can appear later as weaker engagement or a renewal conversation that never happens.

I've contributed to this problem too. We automated a client communication workflow at Distinction and later realised that we'd removed the touchpoint where a project manager used to notice when something felt off. Nobody complained. A few relationships became less engaged and we could not point to a single cause. We restored the touchpoint. The lesson stuck.

The return from automation depends on boundary decisions: which tasks a system handles, where people remain involved and which apparently routine tasks contain relationship or judgement signals. Broad adoption statistics do not answer those questions for your workflow.

Where automation is genuinely brilliant

I'm not writing a "be careful with AI" piece dressed up as nuance. Automation, done well, is genuinely transformative.

Repetitive, rule-based tasks with defined inputs and outputs can be strong automation candidates: document formatting, data extraction, routine reporting, scheduling, validation and reminders. Prioritise work where consistency and speed matter, exceptions can be detected, and an individual error is low-consequence and recoverable. Test the real process before automating it.

We worked with a professional membership body that was spending roughly 15 hours a week on manual course booking administration - processing forms, sending confirmations, updating records. The kind of work that makes good people leave. After integrating an automated workflow, that dropped to almost nothing, with near-zero errors. The team got their time back. The clients got faster confirmations. Everyone won.

That's the promise when the task genuinely fits. Estimate the opportunity from a process inventory, volumes, handling time, error rate and exception profile rather than applying an industry-wide percentage. A smaller, well-chosen workflow can produce more credible value than an ambitious automation target.

Where human judgement carries the value

The other side of the ledger contains tasks where a person's judgement, relationship or accountability is central to the outcome.

Complex decisions where the relevant factors aren't fully captured in the data. Situations that carry emotional weight or relational significance. Exception handling where the right response requires contextual judgement. And relationship-sustaining interactions where the client's sense of being known and valued depends on a human being paying attention.

Clients often experience a professional firm through particular advisers and moments of judgement. Efficient document processing can support that relationship. It does not create attention, reassurance or an understanding of circumstances by itself.

Can we automate routine work and keep people involved in the important interactions?

Yes. The difficult work is distinguishing the categories and recognising a third group between them: apparently routine tasks with consequential exceptions.

The danger zone

The danger zone is tasks that appear routine while containing hidden complexity. They look like perfect automation candidates on a process map and usually complete successfully. The exceptional cases can erode client relationships in ways the system does not detect.

The billing query at the start of this piece is one version. Consider another.

A standard automated update goes out at 4pm on a Friday telling a client their transaction is "progressing as expected." The statement is technically accurate. The client is in the middle of a board negotiation, their counterparty is being difficult, and what they need is a call from their adviser: "I know this is a tense moment. This is what's happening and what I think we should do next week." The template was efficient and wrong for the moment.

New client onboarding is another one. You've built a careful automated welcome sequence: introduction emails, portal setup instructions, document requests and a timeline. The client's first impression is being formed through a series of system-generated emails that can feel like enrolment in a programme rather than a welcome into a relationship. A consulting partner told me that three new clients in one quarter had described the onboarding as “a bit corporate” for a personal advisory service. He discovered that marketing had automated messages he assumed were personal. He responded by writing them himself for six months. The response was understandable and unsustainable; the workflow needed a designed human touchpoint.

The danger zone exists wherever the automated system can complete the task competently in the normal case but fails badly in the exception - and, critically, doesn't know it's in an exception.

Designing automation with oversight built in

You don't avoid automation. You design it with oversight mechanisms that catch the exceptions before they cause damage.

Escalation triggers. Define specific conditions that route a case to a human. A client who has made three contact attempts in 48 hours. An account where a payment was recently late. A matter approaching a critical deadline. Identifying the condition requires operational and client judgement; implementing it also depends on the available data and systems. Design the trigger before live use and test whether it catches representative exceptions.

Review points built into the workflow. Review outputs from the start and set a sample that reflects volume, variation and consequence. An operations director at a financial services firm told me they'd automated client portfolio summaries and discovered three months later that the system was sending previous-quarter data to clients whose accounts had been restructured mid-period. Early tests covering restructured accounts should have exposed the data rule before live release.

Feedback loops. Build in mechanisms that surface client signals suggesting an automated interaction missed the mark. An automated email followed by a phone call within 24 hours is one signal worth investigating alongside complaints, repeat contacts, abandonment and direct feedback.

Clear ownership. Every automated process needs a named accountable owner with authority to pause it when outcomes are wrong. A committee or specialist function may provide challenge and approval; it should not obscure who owns the live process. Automated work can continue after its original context changes unless someone reviews it.

Do not infer your control quality from a market governance statistic. Inventory every automated process, identify its owner, review evidence and confirm who can pause it. Those answers show whether oversight exists.

Measuring the right thing

Automation is automation. If a task is clearly defined and repeatable, it should be automated. We can always add human review if something goes wrong.

I hear this constantly, and it sounds completely reasonable. The problem is the second sentence. "We can always add human review if something goes wrong" assumes you'll know something has gone wrong. In client-facing professional services, the signal that automation has failed isn't a system error or a complaint ticket. It's silence. The client who stops calling. The renewal conversation that never quite gets scheduled. The relationship that was 8 out of 10 and is now 5 out of 10, and nobody in the firm can point to the moment it changed.

The operations leader who measures automation success purely by hours saved is measuring the wrong thing. Hours saved is an input metric. The question that matters is: are the humans whose time was freed by automation now spending more of it on the interactions that clients value most?

Because that's the real promise. Automation should free humans to be more human. Less time formatting documents, more time reading the room. Less time on data entry, more time noticing that a long-standing client hasn't called in a while and maybe something's up.

If your automation programme is achieving that, retain the evidence and keep testing the boundary. If it is saving hours while nobody asks where that capacity goes, you may be building a more efficient process that weakens client relationships.

If you want to map your firm's current or planned automation against the boundary thinking in this piece, we've put together a one-page automation boundary assessment that identifies which processes are safe to automate, which need oversight design, and which should stay with humans. Worth doing before committing budget - or before handing a build brief to your technology team.