I often see contact centre business cases begin with a simple comparison of supplier prices. The numbers are easy to find and easy to put side by side, so they quickly become the centre of the decision.
The problem is not that subscription prices are irrelevant. It is that they are only one part of the cost. The programme also has to migrate data and numbers, integrate other systems, prepare knowledge, train people, run two services during transition, operate the new platform and keep improving it after go-live. Some costs sit with the supplier, some with a delivery partner and many remain with the customer.
A credible total cost of ownership model brings those costs into one structure. It does not need to predict the future perfectly. It needs to make the assumptions visible, compare the options on the same basis and show which uncertainties could change the decision.
Start with a common decision horizon
Before comparing suppliers, define the period and demand profile being modelled. That includes the expected contract and appraisal period, user types, operating hours, contact volumes, channel mix, storage and retention, growth assumptions, planned AI use and the expected pace of change.
Every option should be tested against the same baseline. If Supplier A is priced for current demand, Supplier B for a growth case and Supplier C for a different set of digital channels, the totals may be precise but they are not comparable.
The model also needs a realistic “stay” or “do minimum” case. Existing technology is not free. It may carry support, upgrade, resilience, staffing, integration and opportunity costs. Equally, a move should not be made to look attractive by assuming every current cost disappears on day one.
The weighting of the categories below will vary materially with scope, architecture, channel mix, contract structure and migration complexity. That is why I would not apply a generic market percentage to any of them.
The 12 cost categories
| No. | Category | What the model should test |
|---|---|---|
| 1 | Current-state baseline and retained costs | The genuine cost of staying, the costs that remain after migration and any incumbent commitments. |
| 2 | Transition, migration and dual running | The cost of moving and the effect of delay on parallel services and project activity. |
| 3 | Platform subscriptions and entitlements | Every user type, product, environment, minimum commitment, inclusion and add-on. |
| 4 | Telephony, channels and non-AI consumption | Usage units, volumes, rates, regions, tiers and overage. |
| 5 | AI and model consumption | Entitlement, actual use, supporting controls and the human work that remains. |
| 6 | Implementation and integration | Named deliverables, partner roles, custom work, testing, cutover and acceptance. |
| 7 | Data and knowledge preparation | Discovery, cleansing, migration, retention, knowledge work, reconciliation and sign-off. |
| 8 | Client-side people and governance | The internal team, backfill, assurance, decisions and benefits management required. |
| 9 | Training, change and adoption | Preparation, release time, communications, process redesign and ongoing onboarding. |
| 10 | Support, operation and continuous improvement | The capacity needed to run, change and improve the service after launch. |
| 11 | Resilience, security and compliance | Testing, controls, assurance and buyer-retained responsibilities. |
| 12 | Exit, termination and residual commitments | The cost and practicality of leaving, transferring data and replacing the service. |
1. Current-state baseline and retained costs
The baseline should include current licences, support, infrastructure, carrier charges, internal administration and any essential third-party services. It should also identify which costs are genuinely avoidable and when they can be removed.
This is where stranded commitments and retained systems become visible. A new platform may replace the main contact centre technology while leaving parts of the recording archive, CRM, workforce environment, telephony or reporting estate in place. Those costs should not disappear from the model simply because they sit outside the new supplier proposal.
2. Transition, migration and dual running
Most organisations cannot switch off one service and start the next at the same moment. There may be parallel subscriptions, temporary environments, legacy support, migration tooling, number porting, cutover support and decommissioning activity.
Delay matters because dual-running costs are time dependent. I would model the cost of each additional month rather than hiding the risk inside a broad contingency. That gives the programme a clear commercial consequence when a dependency or decision slips.
3. Platform subscriptions and entitlements
The comparison should cover agents, supervisors, administrators, occasional users and every non-production environment. It should distinguish named, concurrent, hourly and other entitlement models, then record minimum commitments, fair-use limits, reassignment rules, add-ons and annual indexation.
“Included” is not a complete pricing assumption. The model should state what is included, the relevant limit and the charge or operational consequence when that limit is exceeded.
4. Telephony, channels and non-AI consumption
Voice minutes, numbers, inbound and outbound destinations, messaging, recording, screen recording, storage, API calls and data transfer may all use different charging units. The commercial model should keep volume, rate, tier and region separate so that changes in demand can be tested without rebuilding the calculation.
This is particularly important when proposals package channels differently. A lower subscription can be offset by a different usage basis, but the opposite can also be true. The answer depends on the organisation’s real demand profile, not a general rule about which pricing model is cheaper.
5. AI and model consumption
AI pricing can include credits, tokens, interactions, minutes, transcription, speech generation, summarisation, translation, knowledge retrieval and third-party model usage. A feature being available does not mean its use is unlimited or that every interaction produces a saving.
I would model adoption, usage, escalation and outcome separately. The model should also include the operational work around the technology, such as evaluation, guardrails, human review, monitoring, knowledge maintenance and improvement. AI can change the shape of the cost, but it does not remove the need to run the service.
6. Implementation and integration
Supplier and partner proposals should be tied to named deliverables and acceptance criteria. The model needs to show discovery, design, configuration, professional services, CRM and identity integration, middleware, custom development, testing, performance testing, cutover and hypercare.
A bundle of implementation days is difficult to compare if each supplier assumes a different scope. The commercial view should expose what the days are expected to deliver, which dependencies sit with the buyer and what would trigger additional work.
7. Data and knowledge preparation
Data and knowledge are often treated as inputs that will simply be available. In practice, organisations may need to discover, cleanse, classify, map and migrate data, then reconcile the result and obtain business sign-off.
Knowledge may need to be captured, rewritten, tagged, approved and placed under ongoing governance before it can support advisers or AI. Historic recordings, reports and retention obligations can create separate migration and archive decisions. These are business activities with people, time and assurance costs.
8. Client-side people and governance
The supplier proposal rarely contains the full cost of the customer’s own team. Procurement, legal, security, architecture, operations, finance, risk, data protection, programme leadership and subject-matter experts all contribute to the decision and delivery.
Internal people are not free because they are already employed. Their time may need backfill, or it may remove capacity from operational work. The model should make that effort visible without pretending that every internal hour creates a new cash payment.
9. Training, change and adoption
Training cost is more than the training supplier’s fee. It includes design, environments, delivery, release time, backfill, communications, process redesign, super-user support and floorwalking. There may also be a temporary effect on productivity while people learn new processes and tools.
The model should distinguish launch activity from ongoing onboarding and refresher training. A service with regular staff movement or frequent product change will carry a continuing adoption cost.
10. Support, operation and continuous improvement
Go-live does not complete the commercial case. The organisation needs supplier support, internal platform administration, monitoring, release testing, routine change, analytics and an improvement backlog. It may also choose a managed service or specialist support retainer.
This category should show the capacity required to use the platform properly, not merely keep it available. A platform that is technically live but cannot be improved, governed or adapted will struggle to deliver the benefits used to justify it.
11. Resilience, security and compliance
Cloud delivery does not transfer every responsibility to the supplier. Buyers may still need disaster-recovery and failover design, contingency channels, security testing, audit evidence, privacy assessments, payment controls, recording controls and sector-specific assurance.
The scope should be proportionate to the organisation’s services, customers and regulatory position. The important point is that required assurance activity is identified and funded rather than assumed to sit somewhere inside the subscription.
12. Exit, termination and residual commitments
A whole-life model includes the end of the arrangement. That means data and configuration export, secure deletion evidence, knowledge transfer, supplier exit assistance, number porting, archive access, decommissioning, termination charges and any unexpired commitments.
Transition cost is the cost of entering the new service. Exit cost is the cost and practical effort of leaving it. Both matter if the business case is intended to support a decision rather than only secure initial approval.
Normalise the suppliers before comparing the totals
A useful comparison table uses the same 12 categories for every option. For each cost, record whether it is included or excluded, the charging unit, volume, rate, minimum commitment, overage, indexation, dependency and evidence source.
Unanswered items should remain visible. I would rather see a clearly marked assumption with an owner and confidence level than a precise number that cannot be traced back to a proposal, contract schedule or agreed business input.
Separate one-off, recurring, variable, internal and exit costs. That makes the cash-flow shape visible and prevents a one-off transition cost being confused with the steady-state operating cost.
Test the assumptions that could change the decision
A single forecast gives a false sense of certainty. The model should test a base case alongside credible upside and downside scenarios, focusing on the variables that actually move the result.
For a contact centre decision, those variables may include migration delay, demand growth, user concurrency, channel mix, AI adoption, telephony destinations, storage retention, integration effort, annual indexation and the volume of change after go-live.
The most useful question is not simply which supplier has the lowest base-case total. It is what has to change before another option becomes better. That switching point tells the decision-makers where the commercial recommendation is robust and where it depends on a fragile assumption.
Keep benefits separate from TCO
Cost and benefit belong in the same business case, but they should not be blended too early. Start by showing the gross cost of each option. Then show the benefits separately, with a baseline, mechanism, owner, timing, delivery cost, dependency and confidence level.
This helps prevent double counting. A reduction in contacts, adviser time and staffing cost may describe different views of the same benefit rather than three benefits. It also prevents a supplier’s claimed efficiency from being deducted from cost before the organisation has agreed how that efficiency would be achieved and realised.
The result should show the gross TCO, the benefits case and the net position. Decision-makers can then see whether they are selecting a lower-cost service, investing more for a stronger outcome, or relying on uncertain benefits to justify a higher commitment.
Practical takeaways
- Use one decision horizon and one demand profile for every option.
- Compare the move, the operating service, continuous improvement and eventual exit.
- Record what is included, what is limited and what remains an assumption.
- Show internal people and retained services rather than treating them as free or removed.
- Model AI entitlement, consumption and operating effort separately.
- Keep gross TCO and benefits separate until both have been evidenced.
- Test the assumptions that could change the recommendation.
- Keep an evidence trail so the model can be maintained after the decision.
How HiSynergy can help
If you are comparing contact centre options or challenging an existing business case, HiSynergy can provide an independent review of the TCO structure, supplier assumptions and sensitivity analysis before the decision is fixed.