How to Model Customer Experience as Structured Data

Your Service Data Is Not a Data Model. It Is a Pile.

By Brian Keiner, Head of Data, serviceMob

Here is a question that stops most service leaders cold: How many customer experiences did your organization have last week?

Not tickets. Not calls. Not cases. Experiences — the full chain of interactions a customer endured to get a single issue resolved.

If you cannot answer that question with a number, you do not have a data model. You have a collection of operational logs scattered across a half-dozen systems, none of which were designed to represent the customer's actual journey. You have what we call a Franken-stack — CCaaS, CRM, WFM, sentiment tools, case management, ticketing, chat platforms — each generating its own silo of records, each measuring something different, none of them modeling the experience itself.

According to MIT Sloan and BCG, 90% of organizations fail to realize measurable value from AI investments because they lack proper data architecture. The issue is not the AI. The issue is that no one structured the data to represent what actually matters — the customer's effort to reach resolution.

The ROT Problem: Why Most Service Data Is Worthless

Enterprise service organizations are drowning in data they cannot use. The industry has a term for it: ROT — Redundant, Obsolete, Trivial. And most service data qualifies.

Consider what a typical enterprise collects from its service operations:

• Average Handle Time from the telephony platform
• CSAT scores from a post-call survey (captured on roughly 5% of interactions)
• Case status fields from the CRM
• Queue metrics from the workforce management system
• Sentiment scores from a natural language processing tool

Each system produces outputs. None of them produce a model. The data is redundant across platforms, obsolete the moment operational conditions shift, and trivial in that it measures efficiency and perception — not the structural inputs that drive repeat demand.

This is why contact volume never changes at scale. Enterprises keep buying tools that measure what already happened instead of building a framework that explains why it happened and what will happen next.

The missing layer is not another dashboard. It is a data ontology.

What a Data Ontology Actually Is

A data ontology is a prescriptive framework that models the customer experience as data — structuring service interactions, effort, and resolution into measurable inputs that connect strategy, operations, and analytics to provable business outcomes.

That definition is precise for a reason. Every word carries weight:

• Prescriptive — it defines what must be captured, not what happens to exist
• Framework — it is a structural model, not a report template
• Models the customer experience — the unit of analysis is the experience, not the ticket or the call
• Measurable inputs — it captures the upstream drivers that produce downstream outcomes
• Provable business outcomes — it connects directly to cost, churn, margin, and demand

An ontology is not a schema. A schema tells a database how to store records. An ontology tells an organization how to think about its data — which dimensions matter, how they relate, and where gaps exist.

The 6-Dimensional Ontology Model

At serviceMob, we build ontologies across six dimensions. Every customer experience must be mappable across all six:

1. Perspective (POV)

From whose viewpoint is the data captured? The customer, the agent, the tenant, the system? A single interaction looks fundamentally different depending on who you ask. The operational POV sees three calls at 6:46 average handle time. The experience POV sees three calls, three agents, seven days, and twenty minutes of cumulative effort to resolve one issue.

2. Channel

How did the experience occur — telephony, chat, email, self-service, social? And critically, how did the experience move across channels? A customer who calls, then chats, then calls again has a multi-channel experience that no single system of record captures end to end.

3. Phase

Where in the journey did the interaction occur? Before support (self-service, IVR), during support (live agent, transfer, escalation), or after support (follow-up, survey, re-contact)? Phase segmentation exposes where effort concentrates.

4. Component

What product, feature, service line, or business process triggered the contact? Component mapping connects service demand to the upstream business units responsible for generating it.

5. Actor

Who participated — which agents, which teams, which automated systems? Actor mapping reveals transfer patterns, skill gaps, and routing inefficiencies.

6. Resolution

How was the issue resolved, and was it actually resolved? Resolution tracking distinguishes between case closure and genuine resolution — a distinction most CRMs cannot make.

The POV x Channel x Phase Matrix: Where NULLs Reveal the Truth

The power of the ontology becomes visible when you build the matrix. Take Perspective, Channel, and Phase as your three axes and map every combination to a system of record:

POV / Fact	Channel	Phase	System of Record
Customer	Telephony	Before Support	IVR Platform
Customer	Telephony	During Support	CCaaS + CRM
Customer	Telephony	After Support	NULL
Customer	Chat	Before Support	Chatbot Platform
Customer	Chat	During Support	Chat System + CRM
Customer	Chat	After Support	NULL
Agent	Telephony	During Support	WFM + QM
Agent	Chat	During Support	WFM
Tenant	Global	Global	NULL
Component	Global	Global	NULL

Every NULL in that matrix is a structural gap in your data infrastructure. It represents a dimension of the customer experience that your organization cannot see, measure, or act on. Most enterprises we engage with have NULL values across 40-60% of their matrix. They are operating on a partial picture and making strategic decisions accordingly.

The ontology does not hide these gaps. It exposes them — deliberately and exhaustively — so they can be closed.

How Forward Deployed Engineers Build the Ontology

This is not a software installation. Building an ontology requires understanding the business — its products, its customer segments, its support model, its routing logic, its escalation paths, and its data infrastructure. That is why serviceMob deploys Forward Deployed Engineers (FDEs) who embed with your team during the first 30-90 days of engagement.

Days 1-30: Data Engineering and Gap Identification

FDEs identify the appropriate ontology predicated against your industry and business segments. They establish the data pipeline, ingest systems of record — CCaaS, WFM, CRM, QM, sentiment platforms, proprietary systems — and run initial analysis. The POV × Channel × Phase matrix gets built. NULL conditions get documented. The gap between what exists and what should exist becomes visible.

Days 30-60: Operational Due Diligence

FDEs conduct operations discovery — reviewing the support footprint, customer types, user and contact types, channels, agent desktop workflows, case and ticket data structures, contact handling processes, and customer record architectures. This phase connects the data gaps to operational realities.

Days 60-90: Experiential Analytics Activation

The ontology is operationalized. GenAI-backed experiential analytics go live. The organization receives its first insights presentation with a benefits matrix and potential initiatives. The data is no longer ROT. It is structured, dimensional, and operationally ready.

The Unified Ontological Data Layer

The ontology becomes Layer 1 of the Answer Engine — the Unified Ontological Data Layer. This layer collapses CRM, telephony, chat, WFM, case management, ticketing, and delivery data into a single experiential model.

This is not data aggregation. Aggregation stacks records from multiple systems into a warehouse. The Unified Ontological Data Layer remodels those records around the experience object — a single entity that represents everything a customer went through to reach resolution, regardless of how many systems, channels, agents, or days were involved.

Once the data layer exists, the remaining layers of the Answer Engine activate: experiential analytics quantify effort and identify repeat demand drivers, forecasting predicts experiences (not just contact volume), resolution optimization targets root causes, and enterprise signal distribution pushes structured intelligence to product, engineering, operations, and customer success.

Operational Data Models vs. Experiential Data Models

The distinction matters and it is not semantic.

An operational data model organizes data around system events — a call started, a case was created, a ticket was closed, a survey was sent. It answers: What happened in my systems today?

An experiential data model organizes data around the customer's journey to resolution — how many contacts it took, how many agents were involved, how many days elapsed, and how much cumulative effort was required. It answers: What did my customers go through today?

Operational models feed traditional metrics: AHT, SLA adherence, FCR, CSAT. These metrics reduce service to efficiency and perception. Traditional operational metrics like AHT show near-zero statistical correlation to actual customer outcomes.

Experiential models feed behavioral metrics:

• CPx (Contacts Per Resolved Experience) — how many contacts did it take?
• AMPRx (Average Minutes Per Resolved Experience) — how much time did the customer invest?
• DTRx (Days To Resolution) — how long did the experience last?
• 1CX (One-Contact Experience rate) — what percentage resolved in a single interaction?

AMPRx shows a up to 98% correlation to CSAT and NPS — and it is measured on 100% of experiences, not a 5% survey sample. That is the difference between a metric that describes feelings and a metric that describes reality.

Key Takeaways

• Most enterprise service data is ROT — Redundant, Obsolete, Trivial — because it was never structured to model the customer experience
• A data ontology is a prescriptive framework with six dimensions: Perspective, Channel, Phase, Component, Actor, and Resolution
• The POV × Channel × Phase matrix exposes NULL conditions — structural gaps in your data infrastructure that explain why AI investments fail to deliver value
• Building the ontology requires embedded Forward Deployed Engineers who understand both the data and the business — not a software installation
• The Unified Ontological Data Layer (Layer 1 of the Answer Engine) remodels fragmented system data around the experience object
• Experiential data models produce behavioral metrics (CPx, AMPRx, DTRx, 1CX) that correlate to actual business outcomes — operational models do not
• According to MIT Sloan and BCG, 90% of organizations fail to realize measurable value from AI investments because they lack proper data architecture — the ontology is that architecture

---

serviceMob builds the data ontology that turns your service operation into a structured intelligence layer. If your organization is ready to stop treating service data as a cost center and start modeling customer experiences as measurable, actionable data, the first step is a working session with our team.

Book a Working Session