Automating work prevents you from learning
Nobody in a CX team decided to stop reading their own verbatims. It happened one reasonable Tuesday at a time: the summary was good enough, the clustering was faster than doing it by hand, the draft persona was a sensible starting point. Each of those was defensible on its own, and together they moved a set of capabilities out of the team and into a tool.
The uncomfortable part is what the research says about the remedy. Vigilance does not work, expertise does not protect you, and the loss only becomes visible at the moment the tool is unavailable and somebody senior is waiting for an answer.
This is a piece about which capabilities are quietly leaving CX teams right now, why noticing is so hard, and what the honest countermeasure looks like.
The oldest problem in automation is not a new problem
In 1983, well before any of this, Lisanne Bainbridge described the irony at the center of automated systems. Automation takes over the parts of a job that are easy to specify, which leaves the operator holding only the parts that are not. Those remaining parts are the hardest ones, and the operator now practices them less often than before, because the routine work that used to build fluency has been removed.[1]
Read that again with a CX team in mind. The routine work in customer experience is reading feedback, sorting it, drafting the map, writing the questions. None of it is glamorous, and all of it is where the judgment gets built that you are later asked to exercise in a steering committee. Take it away and the judgment has nothing to grow on.
This is not an argument against tooling. It is an argument for knowing which capabilities you intend to keep holding, and for noticing that the choice is currently being made by default.
Where it is actually happening
We see the same seven places across the organizations we work with. None of them involved a decision anybody would recognize as a decision.
| What gets handed over | What stops being practiced |
| Writing survey questions | Defending why you asked |
| Reading verbatims | Noticing the outlier |
| Clustering into themes | Realizing there is an emerging category |
| Drafting segments | Arguing about who you will not serve |
| Building the journey map | Creating the cross-functional agency |
| Answering stakeholders | Learning what leadership objects to |
| Standing in for the customer (synthtetic users) | Talking to one |
The right column is the one to sit with because it comes asa cost you pay later. It's a capability you are not holding today.
Three of them are worth more than a table row.
Reading verbatims
A summary is an average, and the average is the one thing in your feedback that was never going to teach you anything. The finding is almost always the outlier: the single customer who described the problem in a way nobody in the building would have phrased it. Summaries exist to smooth exactly that away. Two hundred verbatims is an hour of work, it is the cheapest hour in customer experience, and it is the first one anybody automates.
This is the expensive one and it shows the least. Building the business case is how a CX lead acquires internal credibility. You learn what the finance director actually objects to by being objected to, in a room, with your own argument. Hand over the drafting and you keep the document and lose the muscle. The muscle was the point.
Asking a model what a customer would say is not research. It is a very fluent version of asking the loudest person in the last meeting. It has real uses, mostly in rehearsal and in stress-testing a question before you take it to a person. It has no business being the last customer you consulted.
Why nobody notices
Two findings explain the silence, and both are uncomfortable.
The first is about attention. Parasuraman and Manzey reviewed the empirical literature on automation complacency and reached a conclusion most managers do not expect: complacency appears under multiple-task load, it is found in expert participants as readily as in naive ones, and it cannot be overcome with simple practice.[2] That last clause removes the standard remedy. Telling a capable team to stay sharp is not a control, because capability is not the thing failing.
The second is about memory. Sparrow, Liu and Wegner found that when people expect future access to information, they recall the information itself less well and recall where to find it better.[3] A team that knows the platform holds the verbatims remembers the platform. That is efficient, and it is why the question "what are customers actually saying" so often produces a link instead of an answer.
Together they explain why nothing feels wrong. No dashboard goes red, no complaint arrives, no incident is logged. The organization can simply do less for a customer than it could last year, and there is no moment at which that becomes visible.
In a CX function the tool rarely disappears. What disappears is its applicability. A new market. A new product line. A regulator asking a question the taxonomy has no box for. An acquisition whose customers behave nothing like yours. At that point the team is doing the work by hand for the first time in two years, under pressure, in front of people who assumed they could already do it.
We had this problem before AI arrived
Worth saying plainly, because it stops this reading as a piece about AI. The same trade has been running in customer experience for two decades, through an instrument nobody thinks of as automation: the feedback survey.
John Sills made the argument on our own podcast and it is the sharpest version we have heard. Picture a customer life as a wedge. At the thick end sit the things that actually matter to them: their hopes, their family, what they are trying to get done. Then the things that get in the way. And at the very thin end, a small part of a whole life, sits you.
Every question on a satisfaction survey is at the thin end. What do you think about us. What do you think about our product. Would you recommend us. His conclusion: "They are only really close to customers opinions of their business."
That is the entire pattern in one sentence, arriving twenty years early. An instrument was adopted, it produced data, the data felt like understanding, and the organization stopped doing the thing that produced actual understanding, which is spending time with people. Leaders came to believe they were close to their customers when they were close to a metric about themselves.
If that sounds familiar, it should. The seven items above are the same move at higher speed and with much better prose.
What the trade is legitimately good for
The honest position is not that none of this should be automated. Nobody should hand-tally a spreadsheet on principle, and there is real work that only exists now because the tooling made it cheap enough to attempt. Coding thirty interviews used to be a funded project and is now an afternoon, which means qualitative research is available to teams that could never previously afford it.
The distinction is whether the tool is doing work you could still do, or work you have quietly stopped being able to do. The first is a tool doing work for you. The second is a transfer of capability nobody minuted.
Capability decays anyway. Automation is just faster at it
We have argued before that capability is a state you hold, not a score you got, and that it decays through ordinary organizational events: a reorganization, a resignation in March, a migration that quietly broke a feedback loop nobody owned.
Automation belongs on that list. It is not a different category of risk. It is the same decay, moving faster and presenting better.
Which means the countermeasure is not a policy about AI. It is the discipline that protects any capability: decide which ones you intend to hold, then arrange for them to be exercised whether or not anything forces you to.
Four things that work
None of them requires banning a tool.
Name the capabilities you refuse to outsource
Not all twenty. Three or four, chosen because they are the ones your organization is peculiar in. For most CX teams, reading raw customer language is one of them, because it is the only input that has not already been filtered through somebody model of what matters.
Put a removal test in the calendar, not in a crisis
One working session a quarter where the team answers a real question without the tooling. The point is not virtue. The deficit is invisible until removal, so removal has to be scheduled or it arrives by accident, on a bad day, in front of an audience.
Keep the argument, automate the artifact
A journey map can be drafted by anything. The cross-functional fight about who owns the gap is what produced the value, and that fight is not a document. When the artifact arrives without the argument, the map is decoration.
Put a person between the summary and the decision
Not as an approval step, which Parasuraman and Manzey's review implies will be rubber-stamped under load, but as a reader with a different job: find what the summary smoothed away, and bring one example of it into the room.
The question worth asking is not "are we using AI responsibly", which no team has ever answered usefully.
Ask instead: which three things could this team do two years ago that it could not do next week without the tooling?
Most teams answer that in under a minute. Which tells you the knowledge was never missing. Only the occasion to say it out loud.
Footnotes
[1] Bainbridge, L. (1983). Ironies of automation. *Automatica*, 19(6), 775-779. https://doi.org/10.1016/0005-1098(83)90046-8
[2] Parasuraman, R., & Manzey, D. H. (2010). Complacency and bias in human use of automation: An attentional integration. *Human Factors*, 52(3), 381-410. https://doi.org/10.1177/0018720810376055
[3] Sparrow, B., Liu, J., & Wegner, D. M. (2011). Google effects on memory: Cognitive consequences of having information at our fingertips. *Science*, 333(6043), 776-778. https://doi.org/10.1126/science.1207745
[4] Bauer, K., Nofer, M., Henrich, B., Drachsler, H., & Hinz, O. (2026). The dependency dilemma: How machine learning decision aids can undermine skill growth. *Business & Information Systems Engineering*, 1121-1146. https://doi.org/10.1007/s12599-026-01014-z
Related courses
