The Precondition Problem: Attributing Contact Drivers Appropriately

Contact driver analysis is supposed to tell support leaders why customers get in touch. You’ll often find that reports only tell you what customers asked about. Those are different questions, and the gap between them is where you risk losing a meaningful share of the customer support department’s budget.

This article covers:

• What standard contact driver taxonomies actually measure.
• Why a large portion of support volume is generated by the organisation rather than the customer
• How a concept called the precondition problem explains the tickets that never seem to resolve cleanly no matter how good the team is.

At the end of this article you will find a practical approach to attributing contact drivers to their real source, so that support data starts producing organisational change instead of prettier dashboards.

If you run a Support or CX function in a SaaS environment and your contact driver report has categories like “billing question”, “how-to”, and “bug report”, this is for you. Those categories might be factually accurate, but they are also hiding the most expensive information in your queue.

What Contact Driver Categories Measure?

The standard contact driver taxonomy is a topic taxonomy. It records the subject of the conversation: billing, onboarding, integrations, a specific feature area.

This is obviously useful when it comes to staffing, routing, and knowing which help articles to write. 

The trouble starts when a topic gets treated as a cause. A ticket coded “billing question” tells you the customer asked about billing. It does not tell you whether they asked because pricing is genuinely complex, because the invoice contradicted what the Sales rep quoted them, or because the pricing page describes a plan structure that stopped existing two quarters ago.

Those are three different problems, owned by three different departments, with three different fixes. The taxonomy files them under one label and moves on.

Topic-based coding answers “what is this about?” It never asks “who caused this?” And when it is never asked, the answer defaults to nobody, which in practice means “the support team”. The volume lands in support’s queue, so it becomes support’s cost, and support’s problem to make cheaper.

An easy way to identify your contact drivers is to parameter Swifteq’s Ticket Classification app in this scope.

Failure Demand: an Upstream Issue with a Downstream Cost

The systems thinker John Seddon drew a distinction that CX operations still has not fully absorbed: value demand versus failure demand.

Value demand is a customer asking for something the service exists to provide.

Failure demand is a customer contacting the organisation because the organisation failed to do something, or failed to do it right.

Seddon’s research in service organisations found failure demand typically running at 40 to 60 per cent of total contact volume, and higher in some sectors.

In SaaS environments, these might look like follow-ups about a bug that was reported last month, or a customer asking where a particular feature went.

Those customers didn’t get in touch because they fancied a nice chat with the support team. Their tickets were manufactured into the queue by something that broke upstream.

The operational punchline is that if roughly half of contact volume is failure demand, then roughly half of the support team’s budget is spent processing the output of other departments’ mistakes. And the standard contact driver taxonomy codes all of it as support workload, indistinguishable from conversations that have a different origin point.

This is why “reduce contact volume” initiatives aimed at the support department so often disappoint. Support did not generate the volume. Deflecting it at the door does not make the underlying failure go away; it just makes the customer experience it alone.

The Precondition Problem

Failure demand explains the operational waste. It does not explain why so many of these contacts are also increasingly difficult and unpleasant, for both the customer and the human agent. Explaining that requires an additional concept.

Every productive support conversation rests on something neither party usually notices: a shared understanding of what was promised, what is possible, and what a fair outcome looks like. Call that shared understanding the precondition of the conversation.

When everyone’s on the same page, the interaction is straightforward. Customer describes problem, agent solves problem, everyone goes home.

When that mutual understanding is missing, something stranger happens.

An example: a customer starts a support interaction believing the product does X, because Sales told them it was possible. The support rep assigned to the conversation knows it does not work that way, because Product never built the feature.

Before anyone can solve anything, the agent has to renegotiate the customer’s entire understanding of what they bought. That renegotiation is the real work of the ticket, but lacks a KPI metric to keep track of it.

This is the precondition problem at work: the shared understanding needed for the conversation to function was broken before the conversation began.

It was damaged by a part of the organisation that is unlikely to see the conversation. The customer experiences the gap as the company going back on its word. The agent experiences it as being handed a contradiction and asked to smile through it.

And, critically, the customer almost always reads the agent’s careful explanation of reality as obstruction. From their side of the screen, the agent is refusing to honour a promise. The fact that the promise was made by someone else does not change how it feels to the customer.

Precondition failures also explain why some conversations are recurring. When there is no shared understanding of what went wrong or what fair resolution looks like, the customer cannot actually evaluate whether their problem is solved. So they contact again. And again.

One upstream failure converts into a series of interactions. When you code each as a fresh contact driver, you end up missing that it is the same broken precondition, unresolved.

Where Precondition Failures Come From

Precondition failures are not random. In SaaS organisations they are generated by a small number of predictable misalignments between departments.

Marketing and Product drift apart.

Marketing’s job is to make the product compelling; Product’s job is to ship what is technically feasible. When these run on different information, the pitch and the product diverge.

“Unlimited customisation” meets hard technical constraints. “Seamless integration” meets a two-week implementation project. Every customer who bought the pitch arrives at support carrying an expectation the product cannot meet, and the agent gets to be the one who breaks the news.

Sales makes commitments that never reach delivery.

A rep tells a prospect their use case will be prioritised on the roadmap, or that a limit can be flexed, or that an exception will be honoured. The deal closes. The commitment lives in one person’s memory and nowhere else.

Months later the customer contacts Support expecting follow-through on a promise Support has no record of and no authority over. The customer is not wrong to expect it. The agent is not wrong to be unable to deliver it. Consequently, the precondition failed at the point of sale.

Product changes things without telling anyone.

Features get deprecated, limits adjusted, behaviours quietly reworked. If the change ships faster than the communication, customers discover organisational decisions through support tickets.

Learning from a support agent that a feature you rely on was removed after it stopped working is a genuinely bad way to find out. Those tickets might get coded “feature question,” while in reality they are announcements that should have happened but never did.

Strategy and messaging contradict each other.

This one is rarer than the others, and uglier when it happens.

Picture leadership trimming the support team’s availability to manage costs while the website still advertises 24/7 coverage, or a tier being repositioned while old collateral keeps circulating.

When strategic decisions outrun the messaging that informs the customers, those customers arrive holding the organisation’s own words. It leaves support agents to explain why those words no longer apply. 

Notice what these four have in common. In every case, one department made a decision, a different department absorbed the consequence, and the cost was booked as ordinary Support workload.

Economists have a name for arrangements where one party makes the decision and another bears the cost, and it is never a compliment.

Attribution Changes the Economics

Once contact drivers are attributed to their source, the conversation with the rest of the business changes character entirely. 

Without attribution, support goes to leadership with “volume is up 18 per cent, we need headcount“, and leadership hears a cost center asking to spend more.

With attribution, Support goes to leadership with “31% of last quarter’s contacts trace to the gap between the current pricing page and the actual plan structure, and here are two hundred examples“.

Suddenly there is a marketing deliverable on the table with a measurable price tag attached, and it tends to get fixed with a speed that pure escalation never achieves.

Attribution also transforms how QA is done within CX.

We’re used to scoring every interaction as if agents start from the same neutral position, and they clearly do not.

An agent handling a genuine how-to question and an agent handling a customer who was promised a nonexistent feature by Sales are playing entirely different games, and scoring them on the same rubric measures the difficulty they inherited as equal to the skill they applied.

Some conversations are already damaged when the agent opens them. Evaluating agents without separating inherited difficulty from performance means systematically punishing whoever draws the short straws. 

And that connects to retention.

Agents who spend their days absorbing contradictions they did not create, without the organisation ever acknowledging where those contradictions came from, wear down in a way that generic wellness initiatives do not touch.

Attribution will not fix that by itself, but it makes the workload visible. Visible workload is the only kind an organisation can decide to redistribute.

What Appropriate Attribution Looks Like in Practice

You can run the recommendations below on existing tooling. You just need one additional dimension in your coding scheme and the discipline to use it.

Keep the topic taxonomy, add a source dimension. Alongside “what is this about“, code “what generated this“: value demand, product failure, expectation gap, undocumented sales commitment, uncommunicated change, repeat contact on an unresolved issue. Six to eight categories cover most SaaS environments. Resist the urge to build forty.

Start with a sample, not the firehose. A few hundred randomly selected tickets, coded for source by people who know the product history, will produce a defensible distribution within a fortnight. The first pass will be imperfect, and an imperfect honest number beats a precise fictional one.

Attribute costs, not blame. The output is a statement of fact: this volume traces to this gap, and processing it costs this much. Departments respond to cost figures far better than to accusations, partly because a cost figure is harder to argue with than a feeling.

Route findings to owners with examples attached. A themed digest of twenty tickets tracing to one undocumented sales practice does more than a quarter of dashboard reviews. Specific beats aggregate every time someone needs to be convinced.

Feed it into QA before performance scoring. Flag interactions that arrived with broken preconditions and read agent performance in that light. The question shifts from “did the agent follow the rubric” to “given what this conversation was when they inherited it, what did they do with it”. That is a fairer question and, not incidentally, a better measure of skill.

Support as an Early Warning System

The deeper shift is in what support data is understood to be. Precondition failures concentrate exactly where organisational alignment breaks down, which means the support queue is the most sensitive instrument a SaaS company owns for detecting internal incoherence.

Every misaligned promise, every uncommunicated change, every gap between the pitch and the product surfaces there first, with the customer’s own words attached.

Most organisations point that instrument at their agents. The ones that point it upstream find out what is actually broken.