Automation creates friction when it speeds up the happy path but makes exceptions, recovery, accessibility or accountability worse. Evaluate the specific customer job, exception consequences, reversibility, human checkpoints, accessibility and pilot evidence before expanding the automation.
Automation creates more customer friction than it removes when it makes the normal path faster but makes exceptions harder, hides who is accountable, blocks customers who cannot use the automated path, or inserts an unreliable system into a high-consequence decision without a meaningful human checkpoint. The right question is not simply whether a task can be automated. It is whether the automated version helps customers complete the job, recover from failure, and reach a responsible person when the standard path breaks.
A useful decision therefore starts with the customer journey and its failure modes, not with the automation tool.
Name the customer job before choosing the automation
“Automate support” is too broad to evaluate.
Define the specific job. It might be:
- rescheduling an appointment;
- checking an order status;
- changing an address;
- answering a common product question;
- collecting onboarding information;
- routing a request;
- issuing a refund within an approved policy;
- reviewing a claim or application;
- resolving an account-access problem.
David Fradin’s product-strategy perspective in Genius Talk is useful here because it pushes teams to understand the customer problem before designing the solution. A workflow that looks repetitive from inside the company may contain information or judgment that becomes visible only when you watch real customers use it.
If the team cannot state what the customer is trying to accomplish, what information is required, and what a successful outcome looks like, it is too early to automate the interaction.
Exception frequency matters, but consequence matters more
A workflow can have few exceptions and still be a poor automation candidate if those exceptions are severe.
Consider two tasks. An automated appointment reminder occasionally sends the wrong time and can be corrected easily. An automated system that locks a customer out of a financial account may fail less often, but the consequence is much greater.
Evaluate both dimensions:
How often does the standard path fail?
What happens to the customer when it fails?
Then add a third question: How easy is recovery?
Low-consequence, reversible tasks can tolerate more automation. High-consequence or hard-to-reverse outcomes deserve stronger review, clearer escalation, and more conservative rollout.
Paul Gibbons’s Genius Talk discussion of AI and work emphasizes using technology to remove administrative drudgery while preserving human judgment where judgment matters. That is a useful boundary for customer-facing automation as well. Speed is valuable when the task is routine. It becomes a poor trade when the system removes the person who could understand an unusual case.
Look for the hidden work skilled people are doing
Before replacing a manual step, observe how experienced staff actually handle it.
They may be checking tone, noticing contradictory information, remembering a prior customer promise, recognizing a vulnerability, translating unclear language, or deciding that a policy exception is justified. Those actions may never appear in the written procedure.
This is one reason automation can increase friction after an apparently successful launch. The happy path was documented. The tacit exception handling was not.
Ask frontline staff:
- Which cases do you immediately know will not fit the normal process?
- What clues tell you a customer is confused or distressed?
- Which rules require interpretation?
- When do you override the standard sequence?
- What information is usually missing?
- Which cases require another team?
- What errors are easy to reverse, and which create lasting harm?
Rahul Alim’s systems perspective supports a related principle: systems should remove avoidable work without creating new operational drag elsewhere. If automation saves three minutes in one queue but creates repeated escalations, duplicate contacts, or manual clean-up in another, the company has moved the work rather than removed it.
Accessibility can turn a “faster” flow into a locked door
Customer friction is not measured only by average completion time.
Angela Fowler describes navigating digital products as a blind user with a keyboard and screen reader rather than a mouse. That perspective matters directly when automating forms, chat, verification, scheduling, payments, or support.
The W3C’s Web Content Accessibility Guidelines 2.2 include criteria for keyboard accessibility and for helping users identify controls and understand interfaces. For a customer-facing automated flow, practical checks include whether a person can complete the process without a mouse, whether focus moves predictably, whether form controls have meaningful labels, whether errors are understandable, and whether the customer can reach an alternative route when the automated interaction fails.
Do not treat an automated accessibility scan as proof that the customer journey works. Test the actual flow with assistive technology and, where possible, with people who use it.
Accessibility is therefore part of the automation decision itself. If the proposed system removes an accessible human path before the automated path is usable, the automation has created friction for a group of customers even if average handling time improves.
Human checkpoints need a job, not a label
“Human in the loop” sounds reassuring but can be meaningless.
A human checkpoint works only when the reviewer knows:
- what they are reviewing;
- what information they can see;
- which risks should trigger intervention;
- whether they have authority to change the result;
- how quickly they must act;
- how the customer reaches them;
- what is recorded for later review.
A person who can only approve whatever the system already decided is not a meaningful safeguard.
For high-consequence steps, define the checkpoint around a specific responsibility. A reviewer might handle unusual identity evidence, large refunds, conflicting account information, sensitive complaints, or a request that falls outside policy. The right design depends on the task.
The current NIST Generative AI Profile supports a risk-management approach in which trustworthiness considerations are incorporated across design, development, use, and evaluation. It does not prescribe one customer-service workflow. Its value here is the discipline of identifying and managing risks instead of assuming that deployment ends the evaluation.
Make accountability visible to the customer
Automation feels especially frustrating when the customer cannot tell who owns the problem.
Every automated journey should have an answer to four questions:
- Who owns the workflow?
- Who receives exceptions?
- Who can correct a wrong outcome?
- How does the customer know what happens next?
If a bot transfers a customer to a queue with no context, asks them to repeat everything, and provides no expected response time, the handoff is part of the friction.
The same is true internally. An exception that lands in a shared inbox with no owner can remain unresolved even though the automated front end appears efficient.
Design the escalation as deliberately as the standard path.
Pilot the narrow job before automating the whole relationship
A pilot should test a defined customer task with a rollback path.
Choose a bounded workflow, establish the current baseline, and decide in advance what would count as improvement or harm. Useful measures may include:
- completion rate;
- abandonment;
- repeat contacts;
- escalation rate;
- time to resolution;
- error corrections;
- complaints;
- support effort after automation;
- accessibility failures;
- customer-reported confusion;
- the share of cases a human must reopen.
The right measures depend on the job. A support deflection metric, for example, can look positive while repeat contacts rise. A shorter average handling time can hide customers who abandon the flow.
Erich Archer’s work around AI-generated media adds a broader trust reminder: synthetic output changes how people judge what they are seeing. In customer service, the analogous concern is transparency and reliability. Do not make the interaction appear more certain or more human than the underlying system can support.
Define rollback criteria before launch
Rollback is easier to approve before a team becomes attached to a new system.
Set specific conditions that trigger a pause, narrower scope, or return to the previous process. Depending on the workflow, triggers might include:
- a material increase in failed completions;
- repeated inaccessible interactions;
- a rise in unresolved exceptions;
- incorrect outcomes in high-consequence cases;
- support volume moving downstream;
- customers being unable to reach a person when policy requires judgment;
- a failure that cannot be corrected promptly.
Rollback does not mean the automation idea was worthless. It may show that the scope was too broad, the exception path was weak, the data was poor, or the human checkpoint was placed too late.
That learning is more useful than protecting the launch.
Use a simple pre-automation decision test
Before replacing a customer-facing step, answer these questions:
The job: What exactly is the customer trying to complete?
The standard path: Is the required information clear and reasonably consistent?
Exceptions: How often do cases deviate, and what kinds of deviations matter?
Consequence: What is the cost to the customer if the system is wrong?
Reversibility: Can the error be corrected quickly and fully?
Accessibility: Can customers using keyboard navigation, screen readers, or other assistive technology complete the flow?
Accountability: Who owns a failed case?
Human checkpoint: Which cases require judgment, and can the reviewer actually change the outcome?
Evidence: What baseline and pilot measures will show whether friction improved?
Rollback: What result will cause the team to stop or narrow the automation?
If several of those answers are vague, the problem is not solved by adding more automation.
Three examples show why context changes the answer
A simple order-status lookup has a clear input, a clear answer, and an easy escape route when the data is missing. It may be a strong candidate for automation.
A refund request can be partly structured, but edge cases may involve damaged goods, fraud concerns, service failures, or a prior promise. Automation may handle policy-standard cases while routing exceptions to someone with authority.
A high-stakes eligibility or account-access decision can affect a customer materially and may involve conflicting evidence. Even if software assists with intake or triage, stronger human review, documentation, and recovery paths may be warranted.
The point is not to classify whole departments as “automatable” or “human.” The unit of analysis is the customer task, its exceptions, and the consequence of failure.
Automation removes friction when it makes a well-understood task easier while preserving an accessible route for exceptions and accountable human judgment where needed. It creates friction when speed on the happy path is bought by making recovery, explanation, or access harder. Test the job, the edge cases, and the escape route together. That is the customer-facing standard that matters.