Tsia outcome-based-pricing-sqs

A TSIA Member Publication

Outcome-Based Pricing Taking the Plunge By Thomas E. Lah, Executive Director, TSIA Including a Case Study from Riccardo Brizzi, COO, SQS

The service offerings in the technology industry have been very weighted toward standing up a technology in the customer’s environment and then ensuring that technology was available for use. As TSIA has discussed in the book B4B,1 the service offerings in the industry are shifting from an “asset” focus to an “outcome” focus. The traditional implementation, education, and support service offerings are losing their bloom in the marketplace. As the service portfolio shifts to being more focused on business outcomes, these traditional service categories become less relevant. What is the specific business challenge the technology provider can solve for the customer? This is what becomes relevant. Instead of services that are centered on keeping the technology asset up and running, the technology provider will have services that are designed to reduce operational complexity, accelerate the usage of technical capabilities, and ultimately deliver quantifiable business impact.

Figure 1: The Great Divide

SERVICE INSIGHT

TSIA-SI-14-014

May 14, 2014

PROFESSIONAL SERVICES

FIELD SERVICES

SUPPORT SERVICES

EDUCATION SERVICES

SERVICE REVENUE GENERATION

MANAGED SERVICES

2

17065 Camino San Bernardo, Ste. 200 | San Diego, CA 92127 | Tel. 1.858.674.5491 | Fax. 1.858.430.3571

© Technology Services Industry Association | www.tsia.com

This Service Insight will tackle one of the very specific challenges facing technology companies as they begin to pivot their service portfolio from an asset focus to an outcome focus: How do we price outcome-based services? This is no simple question. But the first step in the journey is to clearly define the concept of “business outcome.”

OUTCOME CATEGORIES

In 2013, while we were working on B4B, TSIA reached out to several member companies and asked the following question: “Have you ever delivered a service offering where you only were paid if the customer achieved a target business outcome?” There were long and short answers to this question, but a majority of the responses were remarkably similar:

“Well, we once had a customer that only wanted to pay us if they achieved the ROI defined in the business case that was used to justify this significant technology purchase they were going to make. Our finance team and legal team were engaged with their counterparts on the customer side. We tried to craft some type of gain-sharing contract, but we could never get both parties to agree to all the parameters. In the end, we fell back to a standard contract with standard terms.”

There were two variations in the responses. One variation involves some type of outcome-based contract actually getting signed, only to have the provider lose their shirt attempting to achieve the outcomes for the customer. The second variation involves an outcome contract being signed, only to have the customer back out of the terms because they feared how much they might owe the technology provider because success seemed imminent. What story we did not hear was one that involved the successful and ongoing execution of outcome-based service contracts with customers. Why?

TSIA believes one of the challenges creating friction in offering outcome-based services is a clear definition of what type of business outcome you can actually deliver for your customer. As we have scanned the industry for outcome-based services, it is clear that there are three distinct types of outcomes technology companies can deliver to a customer:

• Type 1: Consumption-based outcomes. These are outcomes that are measured per click, per user, per megabyte.

• Type 2: KPI-based outcomes. These are outcomes that are measured by achieving a target reading for a defined key performance indicator (KPI). For example, the customer satisfaction rating for a company improved by three points. The hold time for customers decreased by three minutes.

3



• Type 3: Financial-based outcomes. These are outcomes measured in dollars. The customer saved $500,000. Average spend per website visitor increased $40.

Figure 2: Outcome Types, provides a graphical view of these three categories. There are clear industry examples of offers in each of these three categories. From Rackspace’s Type 1 consumption-based hosting model to the Type 3 revenue sharing model that Redflex puts in place with cities that purchase the Redlfex red-light camera technology.

Figure 2: Outcome Types

With this simple taxonomy in place, we now know there are three distinct types of outcomes a technology provider can attempt to deliver to a customer. Clearly understanding what class of outcome is in play is a significant first step in the journey toward outcome-based pricing. The second step is understanding the difference between revenue streams, offer types, pricing models, and pricing mechanisms.

REVENUE STREAMS, OFFER TYPES, PRICING MODELS, AND PRICING MECHANISMS

To set up strategies for outcome-based pricing, it is helpful to separate four distinct concepts:

1. Revenue Streams. The distinct ways that technology companies make money. 2. Offer Types. The distinct types of service offers a company may have. 3. Pricing Models. The model a company uses to set the price of a specific service offer. 4. Pricing Mechanism. The way the company charges the customer for a service offering.

4



Five Revenue Streams

A technology company has five distinct ways it can monetize with a customer:

1. Product. Customer pays for a technology asset. For example, the customer pays for hardware or pays for a software license.

2. Subscription (Technology). The customer pays to access technology. SaaS and hosted storage are examples of paying for access to technology that the customer never owns outright.

3. Annuity Services. The customer signs an annual or multiyear contract for services from the technology company. Traditional support service contracts fall into this category as well as managed service contracts designed to assist a customer in their IT operations.

4. Project Services. The customer signs a contract for specific deliverables from the technology company to be delivered within a project plan that has a beginning, an end, and milestone deliverables in between. PS implementation projects are the classic example here.

5. Transactions. Last but not least, a technology company may have a revenue stream that is transactional based. This means every time a certain activity occurs, the customer is charged. Examples would include charging the customer per invoice issued or user added.

Historically, product companies have weighted their revenue streams in three of the five categories: Product, Annuity Services, and Project Services. Figure 3 shows the most common revenue mixes that existed within product companies pre-cloud era.

Figure 3: Common Revenue Mixes for Product Companies

5



Many Offer Types

Within the five revenue streams, there are many types of product and service offers a technology company may provide. TSIA has documented a B4B Offer taxonomy that identifies the following key offer categories:

• Product Services. These are the traditional services technology companies have offered that are designed to implement and support a technology. These are the services weighted toward the “asset” side of the B4B spectrum. This service category includes implementation, customization, technical training, support, and many premium support offers.

• Optimize Services. These are services designed to help customers optimize their use of technology capabilities. There are three distinct types of optimize services TSIA believes product companies will provide to customers:

o Operational Services. These are services designed to reduce operational complexity for customers. They include capacity planning, remote monitoring, risk audits, and system administration. The main objective of these services is to minimize the cost of operating a technology.

o Adoption Services. These are services designed to help customers maximize their usage of technical capabilities. Unlike traditional education services, these services involve usage analytics, user adoption reports, and intelligent feature provisioning. The main objective of these services is to maximize technology adoption.

o Information Services. These are services designed to help customers maintain the integrity of their own customer and business data and accelerate business insights from their own data. The main objective of these services is to improve the customer’s ability to leverage their own data or leverage industry data that has been aggregated by the technology provider.

• Outcome as a Service. These are not the historical “bundles” created by product companies where service offerings are wrapped around a product and sold to the customer at some bundled price. These are offerings where a provider bundles the products and services required to guarantee a target business outcome for the customer. In other words, the provider is masking any complexity from the customer and simply committing to deliver a specific outcome for the customer. A simple real-world example of this service category would be how red-light camera technology is sold to cities throughout the country. Cities do not pay for the cameras or the installation of the cameras. The vendor is given a percentage of each ticket (the outcome) issued from the cameras.

Figure 4: The B4B Services Portfolio documents these service categories and offer types within the categories.

6



Figure 4: B4B Services Portfolio

Some of these offer types are not commonly found in the marketplace. Yet, technology companies are already migrating their services into these categories. Software giant Oracle offers Advanced Customer Services designed to monitor systems and reduce operational complexity. SaaS provider salesforce.com has a set of Premier Success services that are designed to monitor usage and help customers accelerate adoption. Siemens offers workflow optimization services for laboratories using Siemens equipment. LivePerson offers an outcome-based managed service designed to improve agent productivity in call centers.

The revenue from every offer type described in Figure 4 will fit into one of the five service revenue streams outlined in the previous section. In other words, these offers will appear as product revenues, subscription revenues, annuity service revenues, project revenues, or transaction revenues. So different offers drive different types of revenues in the economic engine of the company. Now, the question arises: What model should the company use to price these service offers?

7



Three Pricing Models

Every service offer is priced using one of three fundamental models:

• Cost Plus. In this pricing model, a company first determines the cost to deliver the offer. Then, the company layers a target margin on top of those costs. This then determines the list price for the offer.

• Market Based. In this pricing model, the company first determines what the market is currently bearing for similar offers. The company then determines what margin is acceptable on the offer to support the company’s financial objectives. Finally, the company determines if it can deliver the offer within a cost footprint that will achieve the desired margin at the current market price point.

• Value Based. In this pricing model, the company first calculates the specific business value the offer should deliver to the customer. Next, the company determines the costs that will be required to deliver that value. Finally, the company sets a price for the offer that lives somewhere between the value line and the cost line. Ideally, in value-based pricing, there is plenty of room between the value line and the cost line that allows a company to set a price that easily meets or exceeds margin targets.

For more content on these three pricing models, refer to a TSIA paper titled “The Pricing Pentagon.”

TSIA has been studying service pricing models for years. There is no doubt that, historically, the vast majority of service offers from technology companies have been priced using the cost-plus model. True value-based pricing has been a rarity. TSIA predicts that emerging Level 3 and Level 4 service portfolios will require technology companies to frequently apply both market-based and value-based pricing models. This will not be an easy transition for the industry, as the SQS case study documented below attests. However, there is one more component of the pricing discussion that needs to be defined before we can review the SQS experience.

As technology companies migrate away from traditional offers with known pricing models, TSIA predicts there will be four distinct pricing quadrants that will emerge for technology offers. These four quadrants will be defined by two questions:

1. Structured service: Is this an offer that is custom for each customer, or is this an offer that is well defined and repeatable from customer to customer?

2. Unique value proposition: Has our company created and defined a unique value proposition related to this offer?

How you answer those two questions will determine which pricing model will be sustainable: Cost based, market based, or value based. Figure 5 documents these pricing quadrants. Figure 6 maps different offers to recommended pricing models.

8



Figure 5: Pricing Quadrants

Figure 6: Mapping Offer to Pricing Models

9



FIVE PRICING MECHANISMS

So far we have defined three critical components related to pricing service offers:

• The type of revenue stream the offer represents. • The type of offer being priced:

o There are three distinct types of outcome offers. • The pricing model being used to set the initial price of the offer:

o Is the offer unique or similar from customer to customer? o Have we defined a unique value proposition for the offer?

The final component to understand is the pricing mechanism. In fact, when most people think about pricing strategy, they are really thinking about pricing mechanisms. The pricing mechanism is how the customer is actually charged for an offer. In the world of technology services, there are five common pricing mechanisms:

• Percentage of “Other.” In this approach, the amount a customer is charged for an offer is a percentage of what the customer paid for another item. This is the classic approach for how customers are charged for software support (18% to 21% of the software license price).

• Time and Materials (T&M). Customers are charged for the actual effort of specific resources. This is typically presented to the customer in hourly or daily rates.

• Fixed Price. Customers are charged a fixed price for a service offer. In this scenario, there are usually specific milestones or deliverables that must be achieved to receive payment. This pricing mechanism could be applied to offers that are designed to deliver Type 2 and Type 3 outcomes.

• Outcome Volume. The customer is charged based on the volume of a specified activity. For example, the customer is charged for every add, move, or change processed for the customer. This is transaction-related volume. Another example is the customer being charged for additional storage they are consuming in a hosted storage solution. This is consumption-based volume. This is the common pricing mechanism for offers designed to deliver a Type 1 outcome. Both transaction volume and consumption volume are classic Type 1 outcomes.

• Percentage of Outcome. The customer is charged a percentage of the value they achieved from the offer. For example, a customer may be charged 10% of all the total savings experienced because a service offer was executed. This is often referred to as gain sharing. This pricing mechanism could be used for offers delivering Type B or Type C outcomes.

10



Just as the technology industry has relied heavily on cost-plus pricing models, the industry has relied heavily on three pricing mechanisms:

• Percent of Other • Time and Materials • Fixed Price

The shift toward outcomes is forcing companies off of these three pricing mechanisms. Also, TSIA is seeing the emergence of complex managed service contracts and premium support contracts that may employ multiple pricing mechanisms within one annuity service contract. Now, how should a company approach these dramatic changes in pricing? That is the topic of the next section.

PRICING PROCESS

Why did we go through all of this effort to define the concepts of outcome types, revenue streams, offer types, pricing models, and pricing mechanisms? Because these concepts will help accelerate your outcome-based pricing strategy.

As companies brainstorm new outcome-based service offerings, TSIA recommends the following process:

1. Identify the type of revenue the offer will generate. Annuity service revenues? Project service revenues?

2. Identify the offer type. Optimize offer? Information service? Outcome as a service? 3. If this is an outcome-based offer, identify what type of outcome the company is committing to

deliver. Type 1, Type 2, or Type 3? 4. Determine the pricing model that will be used to establish the target price for the offer. Cost-

plus, market-based, or value-based pricing? 5. Finally, determine what pricing model makes sense for this offer. Fixed price? Volume?

Percentage of outcome?

We can easily apply the five-step process to legacy service offers. Table 1 itemizes three common offers and how they are structured using this model.

11



Table 1: Traditional Offers

Revenue Stream

Offer Type

Outcome Type

Pricing Model

Pricing Mechanism

Annuity Service

Standard Support Service

Not Applicable Market Based

% of Other

Project Service

PS Implementation Project

Not Applicable Cost Plus Fixed Price

Annuity Service

Managed Service Not Applicable Cost Plus Fixed Price

Now, what if your company is considering a new offer where the customer only pays if they achieve specific outcomes? Table 2 outlines the parameters of some potential outcome-based offers.

Table 2: Outcome Offers

Revenue Stream

Offer Type

Outcome Type

Pricing Model

Pricing Mechanism

Annuity Service

Premium Support Offering That Minimizes System Downtime Due to Security Risks

Type 2

Outcome (KPI Improvement)

Value Based

% Reduction in downtime

Transaction Managed Service for System Admin

Type 1 Outcome (Consumption)

Cost Plus % of Volume (Transaction Fee for Every Add/ Move/Change)

Project Service

Professional Services Project That Results in Specific Cost Savings for Customer

Type 3 Outcome (Financial Impact)

Value Based

% of Outcome

12



By using this approach to document the key attributes of a new outcome-based offer, a management team can align its understanding of the offer. Also, the management team can use the model to test the assumptions of the offer’s attributes with other key stakeholders. The approach minimizes critical misunderstandings that could exist regarding exactly what the new outcome offer represents. Finally, once the attributes are documented, the company can roll up its sleeves to work on the specific organization capabilities and data streams that will be required to execute the offer.

CHALLENGES

Technology companies are quickly being forced to enhance their organizational capabilities related to pricing offers. This will not be a quick or painless journey. Specifically, as technology companies attempt to define new outcome offerings, they are encountering a common set of challenges:

• Specific costs to deliver the outcome. How much will it cost our company to make sure the customer achieves the target outcome?

• Predicting volume. For volume-based transaction revenue streams, how do we predict the transaction volume? The volume clearly influences how much we want to charge per transaction.

• Predicting impact. Can we accurately predict the financial benefits the customer will receive if they purchase the offer?

• Understanding success science. Do we understand what the customer must do in order to achieve the targeted outcome? What processes will they need to improve that are not our direct responsibility?

• Pricing model. What pricing model is sustainable for outcome offers? Cost plus is probably not the answer, but we have little experience drawing the value line.

None of these are insignificant challenges. In general, management teams will have little or zero experience with outcome-based pricing when they first embark on this journey. For this reason, TSIA strongly recommends the following tactics:

1. Introduce a clear framework for pricing offers. 2. Clarify the taxonomy surrounding pricing. 3. Start by documenting a pricing table for new Level 3 and Level 4 offers. 4. Leverage the lessons being learned by peers in the industry.

The next section of this paper documents the story of SQS as they migrated from a traditional time-and-materials, project-based service offering to an outcome-based offering.

13



CASE STUDY: SQS

Company Profile

SQS is a leading specialist in software quality and offers a range of services:

• Software testing for projects. • Improving development quality in IT projects. • Requirements verification. • Specialized consultant services. • Managed services for software systems in operation and maintenance.

SQS has more than 3,500 employees located in 18 countries. The company generates revenues exceeding $270 million. Riccardo Brizzi, the COO of the company, makes this following observation concerning SQS: “We take pride in the fact that SQS is a highly rated testing services provider that is engaged in some of the most challenging and critical business software change initiatives on the globe.”

However, the testing services marketplace is highly competitive—even for a differentiated brand like SQS. This is a case study on how SQS took the plunge from traditional service pricing models to an outcome-based pricing model.

Legacy Service Offer

Historically, independent software testing services were offered in a classic time-and-materials model. Companies would contract SQS to rigorously test new software. The total cost of the service was based on the effort required. SQS, like the majority of service providers, had a cost-plus pricing model. A rate for testing resources was created based on the cost of those resources. Table 3 provides the parameters of the legacy offer at SQS.

Table 3: SQS Legacy Offer Parameters

Revenue Stream

Outcome Type

Offer Type

Pricing Model

Pricing Mechanism

Project Service Not Applicable Testing Service Cost Plus T&M

Catalyst for Change

The challenge faced by SQS is the challenge being faced by many service providers today: the rate customers were willing to pay for technical resources was under pressure. Testing had become a

14



globally resourced activity. This globalization led to intense pricing pressure. Customers expected the cost of testing resources to decrease.

SQS soon found itself in price wars that were leading to thinner and thinner contract margins. The management team was frustrated. They knew SQS brought much more to the table than just technically competent testers. SQS had over a decade of experience optimizing testing strategies and procedures. How could the company better leverage this deep expertise in the marketplace?

Outcome Offers

In October of 2010, the SQS management team decided to initiate a move toward Managed Testing Services. The company defined the service as follows:

“Managed Testing Services are the provision of test activities by SQS to a Client, where SQS undertakes the end-to-end responsibility for the delivery and management of the relevant test services and solutions.”

The SQS management team felt customers would be attracted to the service for the following reasons:

• SQS would take responsibility to mitigate impact of delays/issues in test delivery. • SQS would be measured on delivery rather than effort. • The customer contract would mandate accountability by SQS for additional cost reductions

through service optimization over the lifespan of the contract.

The management team envisioned an outcome-based service offering with the following attributes:

• Type 1 Outcome Offer Type. Customers only pay if they consume a specific outcome. In this case, if bugs are identified

• Annuity Revenue Stream. Customers would establish multi-project, multiyear relationships with SQS.

• Value-Based Pricing Model. SQS had to determine and articulate the business value of a bug identified in the testing process.

• Outcome Volume Pricing Mechanism. Customers would only pay for bugs actually identified by SQS.

Table 4 summarizes the parameters of the new offer.

15



Table 4

Revenue Stream

Offer Type

Outcome Type

Pricing Model

Pricing Mechanism

Annuity Service

Managed Testing Service

Type 1 (Consumption)

Value Based Outcome Volume

Of course, envisioning a new outcome-based offer and executing a new outcome-based offer are two completely different milestones. The SQS team engaged with several customers before crafting an approach that met the customer’s business needs and was profitable to SQS.

Key Lessons Learned

Riccardo Brizzi, the COO of the company, was intimately involved, together with the SQS leadership, in the process of launching this new service. Mr. Brizzi has many insights regarding the challenges of pivoting to an outcome-based offer. Here are a few of his key insights related to the following topics:

Initial Pricing: Setting the Initial Price/Contract Structure

The biggest challenge with outcome-based pricing is to define a price acceptable to the client and profitable to SQS. Typically this cannot be done without a deep understanding of the client environment. While for the client the pricing is outcome based, for SQS we still needed a thorough understanding of the effort required to get to the point of, in these cases, an almost fully automated regression testing situation. The steps required to get to this point require a close collaboration with the client, and the client needs to be educated in the process of how to arrive at the point where both sides benefit. There is no quick fix. The key lesson learned here was partner with clients who have the maturity to migrate to this kind of offer—clients who see the benefits of the long-term relationship (since the up-front costs are not always immediately lower than current costs, you need a long-term contract to realize the value). Obviously showing the clients wins along the path to this contractual arrangement is key to keeping them interested and confident in the process. Proof of concepts and contracts where prices drop year-on-year are useful ways of showing these wins.

Another concept we adopted in the initial pricing models was to differentiate between pricing and billing. The price was determined on the basis of requirements (output of a previous step/activity) as a price per requirement. However, our billing was based on the actual test cases executed. This was important to our clients, as typically the number of requirements can vary considerably leading up to the implementation freeze. This gave our clients the confidence that only functionality that was actually implemented was tested, and only that testing was paid for.

16



Selling Outcomes: Changing the Sales Pitch. Different Buyer?

Selling managed services is all about selling long-term value. And for a client, it is about entrusting a piece of their business to a trusted partner. The people inside a client organization typically used to buying services are often either threatened by the managed service process or are not interested, as they have short-term goals to meet. What is needed in these situations is a C-level relationship with someone who understands the longer-term value of these contracts and who buys into the process for setting them up. Clearly, these executives have little time, and so the sales pitch has to be value based, solve a defined problem, and have interim value milestones to keep any detractors at bay during the process.

Contract Structure

The contract has to reflect the journey that both the client and the supplier need to go through. This is about partnership, shared risk, and clear roles and responsibilities. The end state must be clear, as must be the interim milestones. To automate testing, for example, there are strong prerequisites for a stable development and operating environment. The client’s applications strategy must be defined, and the requirements-gathering process time must be boxed. Without these prerequisites, arriving at an outcome-based or consumption-based operating model is not possible, as too many variables can impact either the cost of the service, which is bad for the supplier, or the value of the output, which is bad for the client.

Piloting

An effective way of embarking on the journey is through pilots or proof of concepts. In our case, we often, at our own cost or a reduced cost, take a subset of the work that needs to be done and run a pilot or POC. For example, automating a small number of test cases to show that this can be an effective quick win—even if done on a T&M basis. This gives the client confidence, and potentially shows the value that can be delivered (and then used to fund the transition to a fully fledged output or consumption-based model).

Choosing the Right Customers

Client maturity is a key factor in selling managed service deals and eventually moving toward outcome-based pricing. The role of the client changes significantly from delivering a service to the organization, to managing SLA-based delivery through a third party. The client no longer needs deeply technical people, but rather contract managers with an understanding of what is required from both sides to make the contract work. Without these strong managers, the risk of failure is great, and the temptation to bring the service back in-house or revert to a typical T&M body-shopping model is strong. Getting away from the clichés of “not invented here,” “this is how we have always done it,” “too risky to give this to a partner,” and “we need to maintain ownership to maintain control” all have to be overcome.

17



Fortunately, choosing the right customers has a snowball effect. Clients want to hear success stories, and if someone else has gone through the pain of learning how to do it and has been successful, it reassures them.

Financial Results

The most amazing aspect of the SQS story is how the company successfully experimented with new outcome-based offerings without negatively impacting the overall performance of the company. Figure 7 shows the stock price of SQS during the time period the outcome offers were piloted (January 2013 to March 2014).

Figure 7: Stock Price of SQS During Outcome Offers Pilot (January 2014 to March 2014)

Figure 8 documents some of the key financial metrics related to these new managed services.

Figure 8: Managed Services Key Financial Metrics

18



Finally, it is important to observe that SQS actually reduced the number of clients during this period. As highlighted above, not all clients were well suited to the new outcome-based pricing models. However, as documented in Figure 9, the average revenue per client increased dramatically.

Figure 9: Average Revenue per Client

SUMMARY: SUCCESS TACTICS FOR OUTCOME-BASED PRICING

Taking the plunge into outcome-based pricing will not be like entering a nice warm bath. This experience will feel more like jumping from a cliff into churning ocean waters. To swim safely to a shore of profitable outcome-based pricing, TSIA recommends members pursue the following success tactics:

• Document the pricing strategy parameters. The first step in this journey is to align key internal stakeholders regarding the nature of a new outcome-based offering. Discuss, debate, and document offer type, revenue stream, pricing model, pricing mechanism, and target outcome type.

• Identify key data gaps. To commit to outcomes, you will most likely need specific data streams. They may come from your product; they may come from the customer. What are the data streams you will need to consistently deliver the outcome?

• Pilot with customers to understand volume and success science. As the SQS case study demonstrates, you will likely need to learn as you go with new outcome offers. Identify customers that want to partner on this journey. Structure initial contracts so there are clear milestones where pricing can be revisited. Also, avoid long-term contracts until it is clear you can profitably deliver an outcome-based offering.

19



• Establish two-way SLAs with customers. It is very unlikely you will be able to generate specific outcomes for the customer without their engagement. During pilots, identify what is required from the customer. Codify those requirements in the SLAs that the customer must meet in order for the outcome pricing to be valid.

• Wind down unprofitable outcome-based customers. As SQS learned, not all customers are well suited for outcome-based offers. Create clear criteria for selecting customers, and create clear criteria for evaluating which outcome-based contracts should be terminated.

• Can’t be easy to say no. Once again, this is a plunge. Many internal stakeholders will have many reasons for why this is too risky or too hard to attempt. However, think of the risk involved if a competitor masters this model before you do. If you were providing testing services on an hourly basis, would you want to compete against SQS’s outcome-based model? If key stakeholders raise concerns, they should be responsible for finding ways to mitigate the risks they have identified.

The migration to outcome-based pricing will take time. For this reason, TSIA recommends organizations begin the journey today.

1 Wood, J.B., Todd Hewlin, and Thomas Lah. 2013. B4B: How Technology and Big Data Are Reinventing the Customer-Supplier Relationship. San Diego, CA: Point B, Inc.

Documents

Tsia outcome-based-pricing-sqs