Editor’s Note

This article is part of The Experience Center Operating Model, a series exploring what it actually takes to run a modern support experience center at scale, across people, automation, governance, and culture.

You will meet Jeff throughout this series. Jeff is a fictional character, but his situations are not. If he feels familiar, it is because most leaders pass through the same moments, face the same pressures, and make the same mistakes, often without realizing what is happening until the system pushes back.

If you arrived at this page by chance or through search, I recommend starting at the main series page to understand why this work exists and how the parts connect.

→ Visit The Experience Center Operating Model

Jeff did not roll out automation because someone promised cost savings.

He rolled it out because the experience center was hitting a ceiling.

The work was getting more complex, not less. Customers expected faster answers, across more channels, with less tolerance for handoffs. Meanwhile the organization kept asking for the same outcomes, better experience, lower cost, higher consistency, with fewer people.

At some point, effort stops scaling.

So Jeff approved the plan.

An AI copilot for agents.
Automated summaries.
Suggested responses.
Routing improvements.
Self service expansion.

The launch went well, at first.

Then two things happened.

Productivity improved in places that were easy to measure.
Risk increased in places that were easy to miss.

That was the ninth lesson Jeff learned about running a support experience center.

Automation does not remove complexity. It moves it.


Automation Creates a New Class of Work

The biggest surprise was not the technology.

It was the new work it created.

Someone had to define what “good” looked like for suggested answers.
Someone had to maintain knowledge so the model did not hallucinate.
Someone had to monitor drift, bias, and failure patterns.
Someone had to decide when an agent should trust the machine, and when they should not.

Automation did not eliminate human work.

It created a different kind of human work, oversight, design, and governance.

The experience center did not get simpler.

It got smarter, and more fragile if leadership treated it like a plug and play tool.

Leadership Call Out
Automation reduces effort, but it increases responsibility.
If you do not invest in oversight, you are not automating.
You are delegating risk.


Automation Cannot Fix an Undocumented Workflow

One hard truth became impossible to ignore.

Automation did not expose people problems.

It exposed process debt.

In areas where workflows were clearly defined, consistently followed, and actively governed, automation performed well. Suggestions made sense. Routing held. Summaries aligned with reality. Risk stayed contained.

In areas where workflows lived in tribal knowledge, outdated documentation, or informal habits, automation amplified inconsistency.

The system did not know what “right” looked like.

And neither did the model.

Jeff realized something fundamental.

Automation can only execute what the organization has already agreed is safe, correct, and repeatable.

Anything less becomes a liability.

Leadership Call Out
Automation does not create discipline.
It scales whatever discipline already exists.


Documented Workflows Are a Safety Requirement

The team stopped treating documentation as an afterthought.

They treated it as a prerequisite.

Before automation touched a workflow, four questions had to be answered clearly.

Is the workflow documented end to end.
Is it consistently followed in practice, not just in theory.
Are exception paths explicitly defined.
Are there safeguards when the workflow does not apply.

If any of those answers were unclear, automation stopped.

Not because the technology could not handle it.

Because the risk could not be defended.

Automation made ambiguity dangerous. What humans could quietly correct or work around, machines would repeat perfectly and relentlessly.

Operational Reality Check
Undocumented workflows are manageable with humans.
They are unacceptable with automation.


Following the Workflow Matters More Than Automating It

Another uncomfortable pattern emerged.

Some teams rushed to automate workflows that agents did not consistently follow.

The assumption was automation would enforce compliance.

Instead, it created friction.

Agents worked around it. Exceptions spiked. Trust eroded. Automation became something to bypass instead of something to rely on.

Jeff drew a clear line.

Automation was not a mechanism to force behavior.

It was a mechanism to reinforce behavior the system already supported.

If the workflow could not survive human pressure, it would not survive machine scale.

What Leaders Often Miss
Automation should harden proven workflows.
It should never be used to compensate for broken ones.


Safeguards Are Part of the Workflow, Not an Add On

The final piece was safety.

Automation required guardrails by design.

Clear handoff points where humans reassert judgment.
Confidence thresholds below which automation deferred.
Escalation paths when signals conflicted.
Auditability when decisions were questioned.

These were not governance artifacts.

They were operational requirements.

Jeff saw the difference immediately.

Automation stopped being something that “just happened” in the background. It became a controlled participant in the system, with boundaries as clear as any human role.


The First Failure Mode Is Over Trust

Jeff expected resistance.

What he got instead was over trust.

Agents liked the assistance. It saved time. It reduced cognitive load. It gave them language when they were tired. It helped them move faster.

Then it quietly started shaping behavior.

Agents stopped thinking as deeply about root cause. They accepted suggestions that sounded right. They used summaries without verifying. They followed recommended steps even when the customer context did not match.

The best agents stayed cautious.

The average agents drifted toward compliance.

And the system started producing errors that looked like people mistakes, but were actually automation mistakes at scale.

Operational Reality Check
The first risk is not that agents will reject automation.
It is that they will trust it too much.


Augmentation Must Be Designed Around Decision Points

Maria brought the team back to fundamentals.

Where are the moments in an interaction where judgment matters most.

Diagnosis.
Entitlement.
Policy interpretation.
Security checks.
Commitments to the customer.
Escalation decisions.
Transfers.

Those were the points where automation needed guardrails, not convenience.

If automation helped agents type faster, it was helpful but shallow.

If it helped agents decide faster, it could be transformative, or dangerous.

Jeff realized the goal was not to automate responses.

It was to design augmentation around decision points, where it could improve consistency without erasing responsibility.

Leadership Call Out
Automate the repeatable.
Augment the judgment.
Govern the consequences.


The Second Failure Mode Is Invisible Drift

The second issue emerged slowly.

The model got slightly worse over time.

Not dramatically. Not enough to trigger alarms. Just enough that small inaccuracies crept into suggested responses, summaries lost nuance, and knowledge references aged.

The experience center had changed. Products changed. Policies changed. Customer behavior shifted. The automation layer kept operating as if nothing moved.

It was not a bad model.

It was an unmanaged system.

Jeff finally saw why governance mattered.

Not as a compliance requirement.

As operational hygiene.

What Leaders Often Miss
Automation does not fail in one moment.
It drifts, quietly, until the experience absorbs the consequences.


The Ninth Rule of Running a Support Experience Center

Automation is not a shortcut.

It is a teammate.

And like any teammate, it needs training, boundaries, feedback, and accountability.

If automation cannot be monitored, it cannot be trusted.
If it cannot be explained, it cannot be scaled.
If it cannot be governed, it cannot be allowed near high risk decisions.

Jeff stopped talking about automation as efficiency.

He started talking about it as operating model change.

New roles. New controls. New review loops. New definitions of quality. New coaching behaviors. New metrics that measured not just agent performance, but human and machine performance together.

And once that clicked, the next reality became obvious.

You cannot scale AI in an experience center without governance.

Not a committee.

A system.


When you are ready, we move into Part 10, where Jeff learns the difference between AI governance as paperwork and AI governance as a living operating model.


I use AI for editing, so if you see what looks like AI, it just might be. You can visit my AI Prompt Article or the Professional GPT Playbook to put AI to work for you.