Every enterprise CX procurement cycle produces the same spreadsheet: vendor names across the top, per-seat license price down the side. It is easy to build, easy to present and easy to defend in front of a board. It also answers a question that nobody in the organisation actually asked.
The question the buying committee has to answer is what the platform will cost to own over the next five years and what it will return in the same period. License price is one line in that calculation. In our practice, it is rarely the line that decides the final figure, and a contact center TCO model built after the contract is signed tends to arrive with unpleasant news.
Why the license figure dominates the conversation
There is a practical reason the license price gets all the attention: it is the only number every vendor will put in writing early. Integration effort depends on the client architecture. Migration duration depends on the legacy estate. Adoption cost depends on agent turnover. None of it can be quoted before discovery, so these lines enter the business case late, as a placeholder, or never.
Three things follow from that. Vendors compete on the visible number and recover margin on the invisible ones. The finance function approves a figure it will have to revise. And the technical team inherits operating costs it never sanctioned.
What contact center TCO actually includes
A workable model covers the whole ownership cycle, from discovery to exit. The components below are the ones that most often sit outside the license quote, together with the point at which each starts to accumulate.
| Cost line | When it appears | What to confirm before signing |
| Integration and API work | Implementation | Which systems need custom connectors, whether they run on a supported versioned API, and who maintains them after handover |
| Data migration | Implementation | Volume of historical interactions, recordings and CRM records in scope, target format, and who validates the result |
| Infrastructure and telephony | Implementation and ongoing | SIP trunking, concurrent session capacity, storage for recordings and the retention window that compliance requires |
| Non-production environments | Implementation and ongoing | Whether test, staging and disaster recovery environments are licensed separately |
| Training and adoption | Go-live and ongoing | Who trains new joiners once the vendor team leaves, and what the ramp-up period costs in lost productivity |
| Maintenance overhead | Ongoing | Release cadence, regression testing effort per release, and whether platform changes require a certified partner |
| Support tier | Ongoing | Response and resolution times included in the base contract, and the price of the next tier up |
| Compliance and audit | Ongoing | End-to-end encryption scope, data residency, PII masking, and the evidence the vendor supplies for audits |
| Day-2 change requests | Ongoing | Which routing, IVR and reporting changes the internal team can make unaided, and which are billable |
| Exit and portability | End of term | Export format for interaction data and recordings, notice period, and transition assistance terms |
CapEx vs OpEx: one platform, two balance sheets
The deployment model decides where the spend lands. An on-premise deployment concentrates cost at the start – hardware, perpetual licenses, implementation – and the capitalised portion is then depreciated across the asset life. A cloud subscription spreads the same commitment across the term as an operating expense with a predictable monthly profile that scales with seats and volume.
Two identical five-year totals can therefore look entirely different in the accounts. Treatment of implementation and configuration costs varies by reporting standard and jurisdiction, so the finance function belongs in this conversation from the first shortlist, not at signature stage.
The point for the buying committee is that CapEx vs OpEx is a financing decision with its own logic. It deserves to be made deliberately rather than inherited from whichever deployment model the leading vendor happens to prefer.
The costs that arrive after go-live
Two patterns account for most of the gap between the projected and the actual figure.
The first is the connector that quietly becomes a product. A bespoke integration written during implementation has no vendor roadmap behind it. Every CRM upgrade, every API version change and every new channel triggers regression testing and rework, and the effort is carried by the internal team. Integration costs modelled as a one-off implementation item will understate the five-year position whenever the integration layer is custom middleware rather than a supported, versioned API.
The second is the change request queue. If routing rules, IVR flows and report definitions can only be modified by a certified partner, then maintenance overhead grows with how often the business changes – which, in enterprise CX, is constantly. A useful evaluation metric here is simple: how many day-2 changes per quarter can the internal team make without raising a ticket?
Building a business case the committee will sign
A contact center business case that survives the buying committee usually does four things.
- Fixes the horizon before the numbers. Five years matches a typical contract term plus one renewal. A shorter window flatters subscription models; a longer one overstates the useful life of on-premise hardware.
- Models volume rather than seats. Contact volume, channel mix and containment rate drive the cost curve. Seat count is a derived number, and quoting it as the input hides the effect of automation on the total.
- Puts a figure against the risk lines. Downtime during migration, a delayed go-live, attrition during rollout. Even a rough estimate moves these from anecdote to line item, which is where a CFO can act on them.
- States the return next to the cost. Deflected contacts, reduced handle time, lower shrinkage, shorter onboarding. Total cost of ownership presented alone gives the committee a reason to postpone. Presented alongside the return, it gives them a decision.
Where a vendor-agnostic view changes the arithmetic
A single-vendor proposal will optimise the model around its own product set. That is a reasonable commercial position, and it is also why the resulting TCO figure tends to be accurate about licensing and thin everywhere else.
SmartNova works across Genesys, Verint, Omilia and NovaTalks, which means the cost of integrating them is something we estimate from delivery experience rather than from a price list. The architecture decisions that move the five-year number – where the omnichannel core sits, which workforce management layer is in scope, how much of the volume can be contained by self-service automation, which parts of the legacy estate stay in place – are the ones worth modelling before the shortlist narrows.
Benchmark your model
Building a five-year TCO model for a platform decision and unsure which cost lines your current estate will actually generate? Schedule a 30-minute session with a SmartNova solutions architect to map the integration, migration and maintenance components specific to your architecture.