Building a CX Tech Stack: How to Think About It

Building a CX Tech Stack: How to Think About It

The tooling trap

Most CS technology decisions are made backwards. A vendor presents a compelling demo. A peer at another company recommends a platform. A new leader arrives with a preference from their previous organisation. A product is purchased, implemented with significant effort, and then partially used — either because it doesn't fit the actual workflow, because the team wasn't ready for it, or because the problem it was designed to solve wasn't the most pressing problem the operation had.

The tooling trap is the pattern of acquiring technology in response to immediate triggers rather than as part of a coherent stack architecture — and ending up with a collection of tools that are individually reasonable and collectively incoherent. Data lives in three different systems that don't talk to each other. Agents switch between five platforms to handle a single contact. Reporting requires manual extraction from multiple sources that define the same metric differently. The tools work. The stack doesn't.

Escaping the tooling trap requires approaching technology decisions differently — starting not with what tools are available but with what the operation needs to do, how the tools need to connect, and what the simplest architecture is that delivers the required capability without unnecessary complexity.

This article covers how to think about the CX tech stack before making any specific tool decision — the architectural principles, the evaluation framework, and the build-buy-integrate logic that distinguishes CS leaders who make technology work for their operation from those who collect technology that runs alongside it.

What a CX tech stack is

A CX tech stack is the collection of technology platforms and tools that a customer service operation uses to receive, process, resolve, and learn from customer interactions. It is not a single platform — even the most comprehensive helpdesk products cover only a portion of what a mature CS operation needs. It is a system of interconnected tools, each covering a specific functional domain, designed to work together.

The functional domains that a complete CX stack covers:

Contact receiving and routing — how customer contacts arrive and how they are directed to the right queue, tier, or agent. Covered by the helpdesk platform, telephony system, or messaging integration depending on channel.

Contact handling — the agent workspace where contacts are read, investigated, and responded to. The core of most helpdesk platforms — the ticket view, the conversation history, the agent tools for composing responses and logging actions.

Knowledge and information access — how agents find the information they need to resolve contacts. The internal knowledge base, the customer-facing help centre, and any integrations that surface relevant customer data or product information within the agent workspace.

Quality assurance — how interactions are assessed for quality and how that assessment drives coaching and improvement. Covered by dedicated QA tools or native QA functionality within the helpdesk.

Workforce management — how staffing is planned, scheduled, and managed in real time. Covered by dedicated WFM platforms or, in smaller operations, by manual scheduling supported by basic analytics.

Reporting and analytics — how operational data is collected, aggregated, and made visible to managers and leaders. Covered by native helpdesk reporting, dedicated BI tools, or a combination of both.

Customer feedback — how satisfaction and loyalty data is collected and analysed. Covered by native CSAT functionality in the helpdesk, dedicated survey tools, or external NPS platforms.

AI and automation — how repetitive or low-complexity work is automated, how AI assists agents, and how self-serve channels are powered. Covered by native AI features in modern helpdesks, dedicated AI agent platforms, or custom automation built on top of the core stack.

The architecture principle: connectivity over capability

The most important principle in CX tech stack design is connectivity over individual capability. A tool that is best-in-class at its specific function but cannot integrate cleanly with the rest of the stack is worth less than a tool that is very good at its function and connects seamlessly to adjacent tools.

The reason is data flow. A CS operation's ability to learn from its work — to understand what is driving volume, what quality patterns are emerging, what is causing SLA failures — depends on data moving cleanly between systems. If QA assessments live in a tool that cannot export to the reporting system, quality trends are invisible in the operational dashboard. If customer satisfaction data cannot be connected to agent identifiers, CSAT cannot be tracked at the individual level. If WFM forecast data cannot be compared to actual volume in the analytics layer, forecast accuracy cannot be measured.

Every integration point in a tech stack is a potential failure point — a place where data can be lost, delayed, or distorted. Minimising unnecessary integration points — by choosing tools with broad native functionality where possible — reduces both the technical complexity of maintaining the stack and the operational risk of data gaps.

The connectivity principle produces a practical hierarchy for tool evaluation: first, look for the capability within tools already in the stack; second, look for tools with proven native integrations to the existing stack; third, look for tools with open APIs that can be integrated with acceptable effort; fourth — and only when the first three options are insufficient — consider standalone tools that will require custom integration work.

The layers of a CX tech stack

A useful way to think about the CX tech stack is in layers, from the core outward. The core is what everything else connects to. The outer layers extend the core's capability in specific directions.

The core: the helpdesk platform

The helpdesk platform is the centre of gravity of the CX tech stack. It is where contacts arrive, where agents work, where tickets are created and resolved, and where the primary operational data is generated. Every other tool in the stack either feeds data into the helpdesk, receives data from it, or extends its functionality.

The choice of helpdesk platform is therefore the most consequential technology decision a CS leader makes — more consequential than any other tool because it determines what is possible in the rest of the stack. A helpdesk with a rich API, a broad integration marketplace, and strong native functionality in key areas leaves the rest of the stack open and flexible. A helpdesk with a closed architecture, limited integration options, or poor data export capability constrains every subsequent tool decision.

Helpdesk selection is covered in depth in Article 2.

The capability layer: specialist tools

The capability layer consists of tools that extend the helpdesk's functionality in specific domains where the native capability is insufficient. QA tools, dedicated WFM platforms, advanced analytics and BI tools, and AI agent platforms are all capability layer tools — they do one thing well and connect to the helpdesk to do it.

The decision to add a capability layer tool should be made deliberately rather than by default. The question is not "is there a better QA tool than the one in our helpdesk?" — the answer is almost always yes. The question is "is the gap between the native QA capability and the specialist tool significant enough to justify the cost, the integration complexity, and the ongoing maintenance of an additional tool in the stack?" Sometimes it is. Often it is not — and CS operations that add capability layer tools before exhausting the native functionality of their helpdesk end up with stack complexity that creates more problems than the specialist tools solve.

The integration layer: data infrastructure

The integration layer is the infrastructure that connects tools to each other and to the organisation's broader data environment — the data warehouse, the CRM, the billing system, the product analytics platform. In small operations this layer may not exist as a formal component — integrations are handled through native connectors between tools. In larger operations it becomes a dedicated component — a data pipeline, an integration platform, or a data warehouse that serves as the single source of truth for the entire stack.

The integration layer is where the CS operation connects to the rest of the business. Customer data from the CRM enriches the agent workspace. Billing data from the finance system surfaces account context in the ticket view. Product usage data identifies customers who are experiencing friction before they contact support. These connections are what transform CS from an isolated support function into an intelligence function with visibility of the full customer context.

The build versus buy versus integrate decision

Every technology need in a CS operation can in principle be addressed three ways: build a custom solution, buy a commercial product, or integrate an existing tool to cover the need. The right choice depends on a set of factors that are worth evaluating explicitly rather than defaulting to the most familiar option.

Buy is the right default for any need that is well-served by commercial products. Helpdesk platforms, QA tools, WFM software, and survey tools are mature product categories where commercially available solutions are sophisticated, continuously improved, and supported by vendor expertise. Building custom versions of these tools — unless there is a genuinely specific requirement that no commercial product can meet — is almost always more expensive, slower to deliver, and harder to maintain than buying.

Integrate is the right choice when the need can be met by connecting existing tools rather than adding new ones. Before adding a new tool to the stack, the question should always be: can the existing stack be configured or connected differently to cover this need? A new data connection between the helpdesk and the BI tool may produce the reporting capability that was about to trigger a new analytics tool purchase. A Zapier workflow between the ticketing system and the communication platform may automate the notification flow that was about to trigger a new automation tool evaluation.

Build is the right choice in a narrow set of circumstances: when the need is genuinely specific to the organisation in a way that commercial products cannot accommodate, when the integration of commercial tools would be more complex and expensive than building the specific functionality needed, or when the organisation has the technical capability to build and maintain custom solutions reliably. The Bug Portal that surfaces in the context of engineering accountability in support operations is an example — a specific workflow need that doesn't map cleanly to any commercial product and is simple enough to build and maintain without significant engineering resource.

The build option is consistently over-chosen by technical leaders and under-chosen by non-technical ones. The risks of building are real: custom solutions require ongoing maintenance, break when dependencies change, and often fail to evolve with the operation's needs. A commercial product purchased for €50,000 per year that is continuously improved by a dedicated engineering team is almost always a better long-term investment than a custom solution built for €30,000 that requires ongoing engineering support to maintain.

Evaluating the stack you have

Before evaluating new tools, the starting point is an honest assessment of the stack that currently exists — what it covers, where the gaps are, and where complexity has accumulated without proportionate benefit.

A stack audit asks four questions about each tool currently in use:

Is it being used? Tools that are purchased but underused — because they were never properly implemented, because the team was never trained on them, or because the workflow they were designed for was never adopted — are pure cost without benefit. Every tool in the stack should have a clear answer to the question of who uses it, how often, and for what purpose.

Is it working? Tools that are used but not producing the intended outcome — a QA tool that is technically implemented but whose scores are not being used in coaching, a WFM platform whose schedules are not being followed — are generating cost without generating value. Working is not the same as implemented.

Is it integrated? Tools that operate in isolation — that do not connect to adjacent tools in the stack — are generating data silos that reduce the analytical value of the entire stack. An integration audit maps what connects to what and identifies where data is being manually transferred between systems that should be automatically connected.

Is it the right tool? Tools that were the right choice two years ago may not be the right choice today — because the operation has grown, because the product category has evolved, because the integration requirements have changed. An honest assessment of whether each tool is still the best available option for its function, given the current stack architecture and the current operation's needs, prevents the accumulation of legacy choices that were once right and are now just familiar.

The total cost of ownership mistake

The most consistent financial mistake in CX technology decisions is evaluating tools on licence cost rather than total cost of ownership. Licence cost is the most visible number — it appears in the vendor proposal and in the budget line — but it is rarely the largest cost of a technology decision.

Total cost of ownership includes:

Implementation cost — the internal and external effort required to configure, integrate, and deploy the tool. For complex platforms this can exceed the first year's licence cost. For simpler tools it may be a few days of internal effort. It is always more than zero and should always be modelled explicitly.

Training cost — the time required to train the team on the new tool and the productivity loss during the transition period. For a 50-agent team moving to a new helpdesk platform, the training and ramp-up cost — even if no external trainer is used — is significant.

Integration cost — the engineering or technical effort required to connect the new tool to the existing stack. A tool that requires a custom API integration to connect to the helpdesk may cost more in integration engineering than in annual licence fees.

Ongoing maintenance cost — the internal effort required to keep the tool configured correctly as the operation evolves. Every tool in the stack requires ongoing administration — updating routing rules, maintaining knowledge base content, managing user permissions, reviewing automation logic. This effort is often invisible in the initial evaluation and surfaces as an ongoing overhead that was not anticipated in the business case.

Migration cost — if the new tool replaces an existing one, the cost of migrating data, retraining the team, and rebuilding integrations for the new platform. Migration costs are systematically underestimated in tool replacement decisions.

Switching cost — the cost of leaving the tool if it doesn't work out. Some tools — particularly those that become deeply integrated into the stack or that hold significant historical data — are very difficult and expensive to replace. High switching cost is a risk that should be modelled before commitment, not discovered after.

A tool that is cheaper on licence cost and more expensive on total cost of ownership is not a cheaper tool. Evaluating on total cost of ownership rather than licence cost produces better technology decisions and fewer post-implementation surprises.

The change management dimension

Technology decisions are people decisions as much as they are technical decisions. A tool that is technically excellent but poorly adopted by the team it was implemented for has delivered nothing. Tool adoption depends on the quality of the change management surrounding the implementation — not just the training programme but the communication, the involvement of the team in the selection process, and the management of the transition from old to new.

Four change management principles consistently improve tool adoption:

Involve the team in selection. Agents and team leads who have been consulted in the evaluation of a new tool — whose workflow requirements were gathered, whose feedback on the demo was sought, whose concerns were addressed in the implementation design — are more likely to adopt it than those who find a new tool deployed on their desktop one Monday morning with a training session scheduled for the following week. Involvement creates ownership.

Communicate the why before the what. Teams that understand why a tool is being changed — what problem it solves, what the current tool's limitations are, how the new tool will make their work better — adopt changes more readily than those who receive a technical briefing on features without context for why they matter.

Plan for the productivity dip. Every tool transition involves a period where productivity is lower than before — agents are less fluent on the new tool, workflows are being rebuilt, and the inevitable edge cases that training didn't cover are being resolved in real time. Planning for this dip — scheduling it at a lower-volume period where possible, increasing management support during the transition, setting realistic performance expectations for the first weeks — reduces both the depth and the duration of the dip.

Measure adoption, not just implementation. A tool is implemented when it is technically deployed. It is adopted when the team is using it in the intended way for the intended purpose. Measuring adoption — login rates, feature usage, workflow compliance — separately from implementation reveals whether the change management has been successful and where additional support is needed.