Since CPQ (Configure, Price, Quote) suppliers are often referring to their products as platforms, a question arises as to what extent present CPQs have such characteristics supporting platform ecosystems. In this paper, the features of seven case CPQs are compared to each other and to the critical characteristics of a multisided platform. CPQs have diverse features, and most are very similar to their competitors. CPQs are internal platforms, but they typically do not have the characteristics of industry platforms that enable multisided ecosystems. Some CPQs are clearly on the way to becoming true multisided platform ecosystem enablers, but none of the case CPQs studied was ready yet.
Digital platforms and platform ecosystems have recently received a lot of interest among scholars and practitioners. Digital technology is increasingly integrating digital and non-digital products. This interlocking happens because of the increasing pervasiveness and rapid development of digital technologies [1]. Simultaneously, corporations are facing a challenge to re-think their value-capture mechanisms. Customers are expecting more, better and even individual personalization and customization for their products and services.
Product configuration stems from the ability or need to come up with different product variations. Variability in a product refers to the different features or subcomponents a product retains. The ability for a company to customize its product according to customer needs in an efficient and cost-effective manner is a product and manufacturing strategy that has been the focus of mass customization [2]. Mass customization dates back to late 1980s which operates on the concept of combining product or service customization and big production volumes with low costs [3]. Sales configurators with product variability and configurability (also stemming from the 1980s) are closely linked with mass customization [4].
Trentin et al. [4] define sales configurators as “knowledge-based software applications that support a potential customer, or a salesperson interacting with the customer, in completely and correctly specifying a product solution within a company’s product offer.” Product configurators interplay with the sales configuration concept. Product configurators deal with technical aspects of configuring a product based on user selections (e.g., bill of materials and technical specifications) [5]. The optimal design of sales configuration, from the user interface point of view, has been studied by both scholars and practitioners [6]–[8]. The studies show that attribute-based and user-friendly selections of product variation are recommended, whereas alternativebased complex selections are not. [4], [6].
Developments in digital and mobile technology are adding possibilities and features to sales and product configurators. The newest applications in this field are the Configure, Price, Quote tools (hereafter referred to as CPQ) which have their origins as product and sales configurators. Academic literature discussing the definition of CPQs is scarce. The International Data Corporation (IDC) defines CPQ as an enterprise software application that helps the customer to configure products of different complexity levels and receive price information and quotations. Services supporting the product in the customer’s environment are within the CPQ definition also [9]. However, technological development is adding features to CPQs continuously, and the definition today may not apply tomorrow. Some CPQs already have self-service abilities. It could be stated that the value co-creation has already started and customers are taking more control of their product and service consumption [10]. CPQs are the one set of software solutions included in the definition of software ecosystem that consists of “the set of software solutions that enable, support and automate the activities and transactions by the actors in the associated social or business ecosystem and the organizations that provide these solutions.”[11]
CPQ technology is undergoing a dramatic evolution that will significantly elevate the value and impact of such products to commercial concerns. This transformation is due to the expanding support of processes, democratization of setup and administration, incorporation of machine learning and AI (artificial intelligence) to deliver guidance to different parties (i.e., subject matter experts, sellers, partners, and end customers), along with enablement of diverse business models. One of these business models is multisided commerce, where configuring unique transactions involving multiple parties becomes much more dynamic, manageable, and compelling.
Since CPQ suppliers often refer to their products as platforms, we frame our research question as follows: RQ1: To what extent do present CPQs have characteristics that support platform ecosystems?
We started by elaborating on the theoretical background of platforms and platform ecosystems. In this paper, we look at the available capabilities of the case CPQs and compare them with characteristics of platform ecosystems. We conclude with a synthesis of the case findings, theory and suggestions for further research.
To establish the theoretical base, we will outline the meaning of a digital platform, and a platform ecosystem. 2.1
Platform as a concept has been developed in three phases. In the early 1990s, product development researchers started to use the term platform when referring to product development projects that aimed to create a new product [12]. At that time, the platform described a product that met the needs of the core customer group but simultaneously was easily modified by adding or removing features. In the second wave, platforms were identified as valuable control points of an industry. The third wave started when industrial economists started to use the term platform to characterize transaction mediators like digital marketplaces [13], [14].
One common factor for the three development phases of the platform concept was reusability. In the first phase, reusability focused on components and parts. In the second phase, when many industry standards were created, reusability focused on information. In the third phase, process reusability was combined with product and information [15]. Gawer [16] has also suggested a typology of platforms which organized and categorized the different types of platforms by business context. The platforms were classified into three categories: internal platforms, supply chain platforms, and industry platforms.
In this study, we concentrate on multisided markets and industry platforms. Multisided markets have a minimum of two sides [17]. In this context, the platform enables value creation and capture for all its participants. The platform can be viewed as a digital matchmaker that facilitates the exchange of products, whether they are goods, services, or information (i.e., social currency) [18, pp. 3–5]. According to Choudary [19], the platform enables interactions that are sustainable and repeatable when designed properly. To ensure this occurs, the platform needs to balance the quantity and quality of interactions [19].
The platform business model differs significantly from traditional models. A major difference is the necessity to capitalize upon the so-called network effects. Platform participants gain more value when the number of participants increases (i.e., the direct network effect is positive). However, the effect can become negative when the number of participants increases to the extent that the platform usability starts to deteriorate. There are also two types of network effects: direct and indirect. The network effect is direct when the number of same-side participants affects the value. The network effect is indirect when the number of participants on another side of the multisided platform affects the value. [20]
The platform type of business model has been shown to shorten lead times and increase cost effectiveness, speed of development, and desirable variety in portfolios. Although some disadvantages have been found, the platform-based approach to business seems to have more positives than negatives. [21] According to Parker et al.[22], to change the business model from a traditional one-sided pipeline to a platform, three transformations need to take place. First, the company must understand that the most important asset it has is its network of producers and consumers. Second, the company needs to become more acclimated to external interactions; optimizing its own production or other product activities is not enough. Finally, the company mindset must be altered from focusing on customer value to enabling ecosystem value. [22] 2.2
The ecosystem concept is currently used in management studies [23]–[30], yet the literature on ecosystems is still underdeveloped.
The business ecosystem can be characterized by orchestration and mutuality. Ecosystem participants operate out of mutual interests and consequently create value within the ecosystem. The participants can create even greater value when acting together than they could ever create individually. Mutuality describes the ecosystem’s ability to share ideas in both formal and informal ways. Orchestration describes the coordination of interactions among the ecosystem participants. Informal orchestration influences interactions through cultural norms, and formal orchestration focuses on controlling participant interactions through enforcement of the ecosystem rules. [31]
The platform ecosystem is, by definition, multisided (minimum two-sided). This
differs significantly from the traditional one-sided pipeline business model. Rochet and
Tirole [
According to Davidson et al.[31], ecosystems enable three types of value capture. The first type of value is similar to a traditional pipeline business, where participants capture value directly from their transaction (i.e., seller gets money in exchange for goods a buyer receives). The second type of value occurs when ecosystems enable indirect value capture: The platform orchestrator’s role here is to allocate the value indirectly to the ecosystem participants. The third type of value capture is a combination of direct and indirect value capture. [31] Both direct and indirect types of value capture are employed when a pay-to-play experience is implemented in an orchestrated environment and combined with usage-based transactions. A basic solution is when a participation fee gives a standard service, but with extra payment the participant can get more services or more valuable services.
In this study, the critical characteristics of a platform business model are defined according to the platform canvas proposed by Sorri et al. [33]. In their comprehensive literature review-based study, they found eight characteristics that need to be in place. These characteristics are Value, Value Producers, Value Users, Network Effects, Filtering, Value Capture / Monetizing, Governance, and Resilience. These characteristics are used in this study to evaluate the extent to which CPQs fulfil the platform characteristics. When designing a platform business ecosystem, the first step is to define the key interaction (i.e., the producers and users of the value) and the value proposition itself. During the design phase, it is important to keep in mind that one participant can both produce and use the value. Hence, it is imperative to document all possible roles and needs. The ecosystem should also enable network effects. To sustain positive network effects as long as possible, the platform owners must create governance and filtering methods. Filtering helps the users connect with the producers of the value. Proper governance lowers the barriers of platform usage by providing appropriate tools for the participants. The platform owners should also create a plan for how to capture value for itself.
Typically, this means defining ways to monetize; but in some cases, the value can include things like information about the users. Finally, the platform owners should define the level of openness of the platform and to what extent the boundary resources, both technical and co-operative, shall be shared. [33]
Considering CPQs as ecosystem enablers may lead to improved customer experience as they may make the configuration by themselves. For the ecosystem owner, this could lead to increasing revenues and profits if the network effects can be realized, and provide advantage in the competition. 3
The case study was conducted by analyzing seven CPQ products (mainly based on public information). The case companies were identified and selected together with experts in the industry. The cases include large global corporations with a wide range of products and smaller SME companies that are focused more on CPQs
First, the functionalities of the CPQs were collected from company websites. The gathered information included functionalities such as whether the system, 1) includes order management functionalities, 2) enables guided selling, 3) has reporting capabilities, and 4) supports promotion management. The data were collected into a table format and the CPQs were compared to each other. Then the CPQs were evaluated against the platform-critical characteristics defined in the platform canvas [33]. The companies were contacted, and two of them (Apttus and Wapice Ltd) were interviewed. The interviews focused on how the CPQ suppliers expected the system requirements to change in the future. The results were documented in a platform canvas sheet.
The case companies were very diverse; some had a wide selection of software, while some were focused purely on CPQ products. The study focused on CPQs only. For example, though IBM had multiple products, this study focused on IBM Sterling. The functionalities listed in this study included all capabilities the CPQ suppliers introduce in their web pages. In cases where terminology differed between the companies, the most commonly used term was selected for this study. Hence, some companies had thousands of employees (even hundreds of thousands) and some only a couple hundred employees. Similar differences existed in their revenues. Sofon is a privately held company. Official revenue information was not available from year 2016, but, based on previous years (latest information from 2015), it was a medium-sized [34] company.
As expected, all studied cases had configuration, pricing, and quoting abilities. As mentioned earlier in the Introduction, CPQs have evolved from sales or product configuration systems. The sales configurators were originally designed to solve an industry-specific configuration challenge. Hence, some CPQs were based on complex engineering configurations, whereas some were based on less-demanding assembly configurations. Though the history is still visible in the strengths of the systems, each of the CPQs could solve different configuration challenges and had customers from many areas of industry – from service or mass production to companies delivering large investment projects.
One might assume that the size of the company would significantly affect the software capabilities. Therefore, the companies are listed in the tables below from left to right in descending order of size (revenue and number of employees). As shown in Table 1, six out of ten (6/10) capabilities were available in all the CPQs. In addition to configuration, pricing, and quoting abilities, all systems had a guided selling feature. Guided selling is the process that helps potential buyers of products to choose the product best fulfilling their needs, and guides the buyer to purchase the product. To implement this, a configurator must use design criteria in combination with optimization. All systems included an order management feature, meaning the sales and production orders are created based on the accepted quotation. All the systems supported promotion campaigns by enabling different pricing to different geographical locations, customer groups, and so on. Finally, all CPQs included reporting features, though the capabilities may differ. In this study, we were not interested in the level of the service; so the features are not analyzed in detail.
The most significant differences between the CPQs were found in the quotation approval and contract creation processes, e-commerce, and machine learning. Quotation approval requires an automated workflow to be implemented in the system, which may also be a part of the customer relationship management (CRM) system. All the CPQs could be integrated into some CRM systems. Contract management includes rules of discounting, contract terms, agreement clauses, and technical documentation. All CPQs can create the technical documentation on company-branded templates. Therefore, the rest of the documentation should be relatively easy to include in the system. There are two ways to integrate e-commerce capabilities with CPQs. Tacton and Wapice Ltd had not created their own e-commerce capabilities, but they had enabled their CPQs to be integrated into e-commerce systems supplied by other companies. In the other cases studied, e-commerce capabilities had been designed inhouse by the CPQ supplier.
An “x” in the table indicates that a particular functionality can be found in the particular CPQ (“-” refers to “not available”).
IBM
Oracle
Salesforce
Apttus
Tacton
Wapice
Sofon x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x (x) (x) x x x x x x Capabilities Configuration Guided selling Pricing and quoting Contracts Order management Reporting Approval process E-commerce Promotion management Machine learning Revenue (in millions) Employees $79,900
$37,000 380,000 136,000 $6,670 2,5000 $140 1,200 €25 180 €22 330 The value propositions of the case CPQs were also very similar. All suppliers promised to reduce manual work, consequently eliminating quoting errors and reducing the time from quote-to-customer payment. All the systems were also cloud-based and available to the sales organization offline without an Internet connection, which made them accessible from anywhere. Changes made in the configurator while offline were updated in the CPQ during the next online connection. In all cases, customer selfservice was already enabled. The main difference in value propositions came from availability of community. The bigger companies had created developer and partner communities through which they offered training and enabled peer support. All the CPQs were offered as software-as-a-service (SaaS) products, and most of them were also offered under a license.
When comparing the CPQs against the critical characteristics described in the platform canvas, the situation changed completely. As represented in Table 2, the CPQs were not currently used as multisided platforms. Companies use CPQs as a tool to support their own sales personnel in serving their customers. In most cases, it could also be used as an e-commerce tool where the customer makes the configuration. In both cases, the value is created in only one direction — the supplier produces and supplies the value and the customer pays the bill. Hence, the market is single-sided. The configuration requires products and services of several participants to be included (where the value capture is orchestrated by the platform) before the market could be considered as two-sided or multisided. Since the market is single-sided, filtering and matching of the value producers and value consumers is not necessary. However, these capabilities are vital in multisided market ecosystems. One way to improve the matching capabilities is the enablement of partners, who are guided through the product catalog, bundles, and possibilities in selling variations of products. This requires delegating administration, enabling branding, and managing proprietary content for each partner.
The ability to capitalize network effects is a success factor of the platform ecosystem. In single-sided markets, network effects do not emerge. Based on the data gathered, Salesforce and Apttus have begun to engage app developers, creating new market sides.
Platform owners share boundary resources to minimize the effort required from third-party developers [35]. Boundary resources are divided in two categories: technical and cooperative [36]. In the CPQ context, the most commonly shared technical boundary resource is the application programming interface (API) between applications and operating systems [37, p. 27]. The next most commonly shared technical boundary resources are software development kits (SDKs). While the API can be seen as a gate opener, the SDKs are the tools [36]. Scripts are the third most common type of technical boundary resources and include all other technical solutions that enable expanding platform functionalities [36]. Cooperative (or social) boundary resources are much rarer in the CPQ context. Terms and conditions define the agreement between the platform owner and application developers, and the trademark licensing describes the ownership of the information and intellectual property. [36] Design, review, and marketing guidelines are not as legally binding as terms, conditions, and licensing but still important in ensuring the quality of user experience. [36] Though expanding boundaries is important in creating platform ecosystems, sharing the boundary resources to enable the expansion is not common. As represented in Table 3, companies have to wide extent shared the APIs but usually not the other resources. APIs are likely to have been shared because CPQs are often connected to other information systems, such as CRM, enterprise resource planning (ERP), and product data management systems, e-commerce, and partner enablement. One of the companies has chosen to use the APIs of ERP and CRM suppliers. Only Salesforce has shared all technical and cooperative boundary resources. This is probably due to the wide range of programs it has and the fact that it is used even today as a technology provider in other CPQs. Wapice has shared all technical boundary resources, and Apttus can support scripting by leveraging Salesforce’s capability, if needed. As expected, sharing of cooperative boundary resources in the case companies is even rarer than sharing the technical boundary resources. Currently, the information ownership is clear, as it is not shared between the participants. 4
While the CPQs studied have different competitive advantages based on the companies’ interests, size, and strategies, it can be summarized that the CPQs have diverse, but still surprisingly similar, functionalities. Currently, CPQs are not used as an ecosystem enabler, and the platform ecosystem characteristics are largely missing. A newcomer, who needs a tool to disrupt a market, could use CPQs to create platform ecosystems.
Sharing boundary resources is required for platform owners who want to join the ecosystem-enabler market. According to Apttus, CPQs will include multisided platform functionalities in the future. Salesforce seems to have developed their system toward the ecosystem-enabler direction. The CPQ is already an integrator in supply chains, but it also could integrate ecosystems in the future. The customers of CPQ suppliers could create an ecosystem around their products and supplementary products and services.
Gawer [38] stated that a platform strives to increase the innovation of complementary products and services. Simultaneously, the competition between companies is fierce in many markets and industries, and customers increasingly value customization and product-service bundling. It is easy to see the future including marketplaces where a customer can order a design of a renovation, apply for licenses or permits from the authorities, put products and services out to tender, accept quotes, and even make contracts in a CPQ ecosystem. While CPQs currently have effective analysis algorithms, and some have even embedded machine-learning capabilities, the Internet of Things (IoT) may provide value-added information in the future.
The acronym CPQ is indicative of expanding process automation, from configuration to pricing management and quoting – which could further extend to interoperating with order management, billing, renewals, incentives, and different channel applications like e-commerce and partner relationship management. AI and machine learning are creating opportunities to present the “science of the possible” for tailoring guidance on how value can best be achieved by sellers, partners, and end customers through data-driven insights. At the same time, these technologies are constructing new ways to interact with applications via voice, intelligent agents, texting, and more. New business models will be enabled by supporting many-to-many transactions, or transactions involving multiple parties (multisided), that have a mix of goods and services packaged with different charge types, lead times, and fulfillment processes. More importantly, the actual setup and administration of resources (e.g., rules, catalogs, workflows, content, branding), including those delegated to third parties (to partners and even to end customers) will become more configurable and optimized for use by business persons. Simultaneously, the requirements for IT resources will be radically reduced and the responsiveness of parties to changing market dynamics on industry platforms will increase. These trends together will make it possible for CPQ to be a key asset in allowing industry platforms for multisided commerce to scale and remain compelling for ecosystems aiming to achieve value capture through collaborative network dynamics.
This case study revealed that CPQs are not yet platforms that can enable two-sided or multisided ecosystems. In order for those to become one, several characteristics need to be developed. First, the CPQ should have filtering and matching abilities; it should enable network effects and have adequate governance tools and processes in place. In addition, those should offer both technical and co-operative boundary resources. There is a need for discussion on the next development phases of configuration systems. Though not clearly supported by public information, there is reason to believe that platform ecosystems will become the next step in product and sales configuration. However, there is some indication, as supported by the interviews, that developments to enable the multisided business model are in process.
There are limitations in this study, as the number of cases and interviews was small. The results are not generalisable. However, we hope the results initiate discussion and lead to further development of CPQs. Unfortunately, the information may be incomplete as we were not able to interview all case companies. Therefore, we had to rely on online public information. While, in some cases, the terms varied between companies, some meanings of terms may have become too general. Further, even though collaboration with Apptus and Wapice has provided valuable insight for this study, the collaboration may have somewhat biased our view on CPQ prospects. Further study is required on the implications for the future of CPQs of customer needs and ecosystem developments, as well as the possibilities of including IoT capabilities in the CPQ. [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]