top of page

Contact Centre AI Automation: Why Vendors Never Ask the Question That Determines Whether It Will Work

  • Graeme Colville
  • 7 days ago
  • 4 min read

Updated: 8 hours ago

Every AI vendor conversation in the contact centre space follows the same sequence.


  1. Volume data is collected.

  2. Use cases are identified.

  3. A pilot is scoped around the highest-volume contact type.

  4. Containment rate becomes the success metric.

  5. A timeline is agreed.

  6. The implementation begins.


Contact centre AI automation is being deployed at scale across the industry - and almost none of it starts with the right question.


At no point in this sequence does anyone ask the question that determines whether the implementation will work.


That question is: what is generating this demand?


The Question That Gets Skipped


Before any contact type is automated, the operation needs to understand why that contact type exists.


Not what customers say they're calling about - that is the presenting reason.


The structural reason: what is happening in the system that creates this demand in the first place?


If the contact type exists because customers have a legitimate recurring need - renewing a policy, checking a balance, updating details - automation is appropriate.


The demand is valid, the interaction is containable, the outcome is achievable without human involvement.


If the contact type exists because the system failed - because the previous interaction didn't resolve the issue, because the process withholds information customers need, because the downstream step the customer was promised hasn't happened - automation is not appropriate.


It is a faster path to the same unresolved outcome.


The contact is contained.

The failure continues.

The next contact arrives.


The vendor conversation does not ask this question because the vendor's incentive structure does not require it.


Vendors are measured on deployment speed and containment metrics.


The diagnosis that would reveal whether AI is appropriate for a given contact type is the same diagnosis that might delay or prevent the sale.


So it does not happen.


The four structural conditions that need to be in place before any deployment is likely to deliver its business case are set out in Contact Centre AI Readiness: What Needs to Be True Before Deployment Will Work.


What the Contact Centre AI Automation Sales Motion Actually Looks Like


Diagram comparing the standard contact centre AI automation vendor sequence - which skips demand diagnosis - against the right sequence, which diagnoses demand and fixes structural failures before deployment.
The vendor sales motion moves straight to deployment. The right sequence starts with demand diagnosis. That gap is where most contact centre AI automation projects fail.

The AI vendor engagement follows a predictable logic.


Volume is the entry point - the highest-volume contact types are the most compelling use case for automation because the efficiency gain is most visible.


A pilot is scoped, a containment target is set, and the implementation is benchmarked against that target.


Three months in, containment is reported.

The pilot is declared a success.

The rollout is expanded.


This is the structural problem with contact centre AI automation decisions made through a vendor lens rather than an operational one.


What is not reported in month three: whether the repeat contact rate at customer level has changed.


Whether complaints about the automated journey have appeared in the qualitative data.


Whether the contacts that are being contained are actually reaching resolution, or whether customers are completing the automated interaction and calling back.


These are not metrics the vendor is accountable for.


Their contract is typically complete before the downstream consequences become visible.


By the time the operation realises that contact volume hasn't fallen - that the automation has processed the demand but not removed it - the vendor relationship has moved to the next phase of deployment.


Why the Industry Accepts This


The vendor model is not the only structural cause of this pattern.


The buying side has its own dynamics that produce the same outcome.


AI implementation is a leadership commitment before it is an operational intervention.


Board-level interest, budget allocation, and stakeholder communication have typically happened before the operational question of what is being automated is fully examined.


The question of whether the demand is structurally generated introduces delay and uncertainty into a project that already has political visibility.


The path of least resistance is to proceed with implementation and manage consequences when they emerge.


Operations leaders who raise the structural question - who ask whether the contacts being automated are worth automating - are often positioned as obstacles to progress rather than as the people applying the right diagnostic rigour.


The pressure to move forward overrides the analysis that would make the move effective.


This is not unique to AI.


It is the same dynamic that produces coaching programmes deployed against structural performance gaps, FCR targets applied to operations with authority design failures, and AHT targets set without examining what the calls are long about.


The industry has a long-established pattern of deploying solutions before completing the diagnosis.


AI is the current and most expensive expression of that pattern.


What to Diagnose Before Any Contact Centre AI Automation Conversation


Before scoping any contact centre AI automation deployment, the operation needs to answer one question for each proposed contact type: is this demand that the interaction can resolve, or is this demand that exists because of a failure upstream that the interaction cannot fix?


To answer that question, pull a sample of the target contact type and classify the contacts by cause.


What would need to be true for this contact not to exist?


If the answer is a better interaction - better information, better call control, faster authentication - the demand is a candidate for automation.


If the answer is a process change, a system fix, a policy adjustment, or an authority change that agents currently don't have - the demand is failure demand.


Automating it handles the symptom and leaves the cause intact.


That analysis takes time.


It delays the vendor timeline.

It introduces findings that may challenge the business case.

It is also the only analysis that determines whether the implementation will work.


Before your next AI vendor conversation, the Find Your Loop diagnostic identifies whether the demand you are being asked to automate is structurally generated - and what needs to change before automation will reduce it rather than accelerate it.

Comments


bottom of page