CPQ Build Versus Buy

A holistic view across risk & total cost of ownership

A strategic analysis for enterprise technology buyers evaluating Configure, Price, Quote and Order Management platforms, comparing a self-build with buying ServiceNow.

Julian Hodges, CTO

Executive Summary

The decision to build or buy a Configure, Price, Quote and Order Management (CPQ/OM) platform is one of the most consequential technology decisions an enterprise will make, sitting at the intersection of commercial capability, operational complexity, and long-term competitive positioning. This paper argues the case for buying in a ServiceNow context and does not assume any specific platform for the build option.

Self-build programmes are typically harder, more expensive, and riskier than enterprise teams anticipate. The initial scope looks manageable, increasingly lower cost storage and compute and advances in AI make build tempting. Despite these drivers, the real-world complexity of building a future-proof production-grade CPQ/OM system is often beyond the capabilities of even the biggest organisations. Those companies often discover – too late and too expensively, that the real challenge is not necessarily delivering an initial MVP. It is sustaining, evolving, and operating the system over a realistic multi-year lifetime in a fast-moving technology and product landscape.

This whitepaper structures the build vs. buy analysis across six dimensions: estimation and prioritisation, skills capacity and transference, functional scalability, storage and compute economics, integration and interoperation, and support and maintenance. Across each dimension, the cost and risk profile of self-build is examined against a mature commercial platform  –  specifically ServiceNow CPQ and Order Management, a platform with proven deployment experience across global telco and technology providers.

The conclusion is not that self-build is always wrong. It is that organisations must account honestly for what they are signing up for – and that for most enterprises, a continuously invested commercial platform delivers faster time-to-value, minimised risk, lower total cost of ownership, and a stronger foundation for long-term growth.

Why This Decision Matters

CPQ and Order Management are not peripheral systems; they govern how products and services reach customers, how pricing and configuration logic is applied, how orders flow through fulfilment, and how revenue is ultimately realised. In enterprise telecommunications and technology, where product catalogues are complex, pricing is multi-dimensional, and order journeys span many systems and third parties, a CPQ/OM platform is critical infrastructure.

The stakes are high in both directions. A poorly chosen or poorly executed CPQ/OM implementation can slow time to market, introduce revenue leakage, and erode the customer experience. A well-chosen and well-implemented platform can be a genuine source of commercial advantage, enabling faster product launch, more sophisticated pricing, and a more seamless buying experience for enterprise customers.

What makes the build vs. buy decision particularly complex is that the true costs of each path are distributed over time in ways that are not, by and large, visible at the point of decision. Buyers typically consider a small subset of the real full-lifetime risk and cost exposure factors. The upfront investment in a self-build programme can look highly attractive versus commercial licensing. However, in years two to ten, as maintenance demands grow, skills erode, and the platform falls behind the market,  the real economics become apparent.

The six dimensions that follow represent a more holistic, longer-term view, and each will be explored in more detail in this paper.

1. Estimation & Prioritisation

Of all six dimensions, this is where the gap between expectation and reality tends to diverge the most, in risk, cost and time.

Commercial CPQ platforms are built by teams with focused domain expertise accumulated over many years and many customer deployments. These teams understand the genuine breadth of what needs to be built, the edge cases that surface at scale, and the architectural patterns that hold up under real-world load. Estimation is grounded in that depth of experience. The build cost is distributed across the vendor’s customer base and does not fall on the buying organisation.

Self-build programmes follow a different arc. Even large enterprises with significant technical capability consistently fail to appreciate the genuine scope of a production-grade CPQ/OM system. Initial estimates look reasonable. As the system is built and complexity surfaces, timelines extend, budgets grow, and the gap between what was planned and what was delivered widens. This is not typically a failure of individual competence, it is a structural consequence of trying to replicate in-house what vendors have spent years and significant investment refining across many deployments.

Prioritisation presents a compounding risk. Self-build CPQ programmes are subject to the competing pressures of organisational change in a way that commercial platforms are not. Leadership changes, strategic priorities shift, and a flagship initiative can find itself unable to compete for the resource it needs to remain viable. Budgets that seemed secure at programme inception are reallocated. The result,  seen repeatedly across the industry,  is a system that was never quite finished, never quite maintained, and never quite competitive.

2. Skills Capacity & Transference

A self-built system is only as strong as the people who can build, operate, administer, and evolve it. The skills implications of this are regularly underweighted in initial business cases  –  and regularly become critical problems in year three of the programme and / or beyond.

Mature commercial platforms carry a structural advantage here that extends well beyond the platform itself. ServiceNow is supported by a global ecosystem of trained practitioners, continuously updated training programmes, and an active community generating best practices, documentation, and solutions. When a key team member leaves, a replacement can be hired from an established market of qualified candidates. For an organisation with an existing ServiceNow practice, a significant body of skills is applicable directly to CPQ and Order Management  –  the platform, the data model, the tooling, and the development patterns are already familiar. This facilitates transference of existing capacity into the new programme.

A self-built system offers none of these structural guarantees. Training must be created from scratch. Documentation, if it exists at all, typically falls behind the codebase and rarely reaches the quality or currency that commercial vendors maintain as a matter of course. When a key developer or architect leaves (or, for example, becomes long term sick), institutional knowledge leaves with them. The organisation must train from scratch, with no external talent pipeline and no community to draw from for best practice.

Staff churn is more damaging to a custom system than organisations typically model. What appears manageable in a steady state can become an operational risk when it occurs during a major product launch, a platform upgrade, or a period of broader organisational change  –  precisely the moments when a system needs to be at its most reliable.

3. Functional Scalability

The CPQ and order management landscape does not stand still. New market demands emerge, telecommunications technologies, capabilities, architectures etc evolve rapidly (very often introducing massive market disruption). AI-driven capabilities move from differentiator to baseline expectation, regulatory requirements evolve, and customer buying behaviours change. A platform that is competitive at launch must continue to evolve to remain so.

Commercial platforms invest continuously in functional capabilities because their business model depends on it. ServiceNow has visibility of CPQ and Order Management requirements across its entire global customer base and builds to satisfy that collective need, with systematic, strategically driven processes for feature prioritisation. The cost of that investment is distributed across all customers. ServiceNow’s largest telecommunications are not passive recipients of that roadmap  –  they typically drive both roadmap content and prioritisation alongside ServiceNow’s other inputs. These influences represent free R&D versus self-build.

Self-built systems face a structural disadvantage that compounds over time – domain knowledge is bounded by the organisation’s own experience. Prioritisation in self-build scenarios tends to be tactical  –  focused on immediate needs rather than long-term competitive positioning. Once initial phases are delivered, investment in the platform tends to decline as organisational attention moves elsewhere. A custom CPQ that was adequate at go-live gradually falls behind the market, not through negligence but through the entirely predictable dynamics of how internal IT investment is allocated over time.

4. Storage, Compute & AI

Infrastructure economics in the CPQ and Order Management context are more complex than they initially appear  –  and the consequences of underestimating them can be substantial.

Commercial platforms include storage and compute within licence costs, providing the financial predictability that self-build cannot offer. More significantly, mature commercial platforms are optimised by practitioners who have deployed the same system many times, at enterprise scale, across many organisations. The performance traps are known. The architecture has been refined across multiple iterations and production deployments. That accumulated optimisation is invisible in a feature comparison, but very visible in operational costs.

Telco-grade CPQ and Order Management systems are architecturally sophisticated. The volume of catalogue data, the complexity of pricing and rules logic, the number of order lines (can be a handful to tens of thousands, with often dependencies and relationships between them) and the demands of high-volume order processing mean that specific design decisions can produce orders-of-magnitude differences in storage and compute consumption. Organisations that discover this at scale,  rather than in the design phase, frequently face the additional cost and disruption of refactoring major subsystems. The risks are therefore twofold: unforeseen consumption costs, and the cost of rebuilding what was designed incorrectly the first time around. The CPQ vendors themselves have often learned the hard way but mature vendors such as ServiceNow have had time, budget and field experience to get it right and foresee, remove and mitigate risk for their customers.

AI adds a further dimension. Commercial platforms are actively investing in application-specific AI capabilities  –  smart recommendations, pricing assistance, order anomaly detection, catalogue management,  developer tooling etc. These are shared investments available to all customers. A self-build programme must fund and implement equivalent capabilities independently, at full cost, with no community of practice to draw from and no vendor roadmap to align with.

5. Integration & Interoperation

Enterprise CPQ and Order Management do not operate in isolation. They must connect to CRM, ERP, billing systems, fulfilment engines, external commerce platforms, and  –  in telecommunications  –  a wide range of TMF-standard APIs and third-party network and service management systems. The integration surface of a production CPQ/OM is large, and it grows over time.

In this dimension the difference between commercial and self-build is very tangible. ServiceNow CPQ ships with organic interoperation across the ServiceNow platform  –  Sales and Order Management, Customer Field Service Management, Procurement, Strategic Portfolio Management etc –  all operating on a single, coherent data model and technology stack and sharing common tooling. It includes CPQ headless APIs, out-of-the-box connectors to commerce platforms, hundreds of pre-built integrations via Integration Hub, TMF Open API support across product catalogue, service qualification, product ordering and quoting, and zero-copy connectors to major data platforms. These are not features that need to be designed, built, or separately procured. They are included.

A self-built system must design, build, and maintain all of this independently  –  or identify, evaluate, procure, and integrate third-party components to fill the gaps. Each of those activities carries cost, delay, and risk. The components that are selected will often imply licensing in their own right, which should be incorporated into any total cost of ownership analyses. The burden of maintaining integrations across platform upgrades and API version changes falls entirely on the enterprise. Time-to-market risks and integration costs are implicit in a self-build approach.

6. Support & Maintenance

For self-built applications, At launch, the team that built the system is present, knowledgeable, and motivated, documentation is as complete as it will ever be, architecture decisions are well understood, training materials are fresh. These conditions often do not persist, and more usually they degrade, through the application lifecycle.

Commercial platforms include structured support as part of licensing: general product support, vendor-managed infrastructure, patch management, disaster recovery, and upgrade processes handled by the vendor at vendor cost. For ServiceNow enterprise scale customers, dedicated Customer Success Managers provide a proactive channel for adoption guidance and issue escalation. Comprehensive, systematically maintained documentation is available for developers, administrators, and end users at every release, with dedicated processes for providing feedback and identifying and correcting inaccuracies and deficiencies (e.g. insufficient detail in particular aspects of the content).

A self-built system transfers all of these responsibilities to the enterprise. All levels of ‘product’ support, infrastructure maintenance, upgrades, bug fixes, and resilience processes are owned (and therefore paid for) internally. Documentation, where it exists, is typically created by teams with various other tasks and priorities. A typical result of this dynamic, that we have observed over 30 years of enterprise software delivery, is that documentation is almost never maintained to the standard the system requires.

These costs are easily underestimated because they are diverse, diffuse and occur over a long period of time. They do not appear as a single line item. The costs accumulate across helpdesk load, L2/3 support, incident resolution time, user self-service rates, and the compounding effect of documentation that is six months out of date for a system that receives significant enhancements over time. Across a five-year+ operational horizon, these costs are material  –  and unlike vendor support costs, they scale with organisational complexity rather than remaining fixed.

Conclusion: The Honest Accounting

Across all six dimensions, the pattern is consistent. Self-build programmes carry costs and risks that are structurally difficult to see at the point of decision and typically underestimated or not considered at all. This is not a reflection of organisational capability; it is a reflection of the genuine complexity of enterprise CPQ and Order Management, and of the compounding nature of the challenges that emerge over a multi-year programme lifetime.

The case for a mature commercial platform is not simply that it is cheaper over a realistic lifetime (though it often is), but also that the risk profile is fundamentally different. A commercial platform brings accumulated domain knowledge, continuous investment, a global skills ecosystem, and a support structure that no individual enterprise can replicate internally. The organisation’s energy goes into configuration, integration, and business outcomes – not into rebuilding what the vendor has already solved.

ServiceNow CPQ and Order Management has been deployed and continuously refined across telecommunications and technology providers globally. It supports the full range of product modelling complexity that telco-grade operations require, with native interoperability across the ServiceNow ecosystem and deep TMF API alignment. For organisations with an existing ServiceNow estate, the path to value is particularly direct: existing skills transfer, existing integrations extend, and the platform investment made elsewhere in the business compounds rather than fragments.

The build vs. buy decision deserves a rigorous and honest assessment – one that accounts for the full operational lifetime of the system, not just the delivery phase. Organisations that are evaluating a self-build programme, or that have already begun one, are encouraged to pressure-test their assumptions against the six dimensions outlined in this paper before committing further capital and organisational energy to a path that the evidence, often, does not favour.