Chapter 2: Pricing Example - ACME Inc’s AI-powered Chatbot
The purpose of this chapter is to conduct a simulation of a pricing project using a fictitious example. The hope is to coalesce everything we’ve discussed so far and build a mental model for a process that you can hopefully repeatably run in your own organization.
Before we begin let’s lay down some context about our company and product in question.
Context
In this example we assume the role of pricing consultants to ACME Inc. ACME Inc is an established player in the Customer Experience Management domain with revenues exceeding 40Million per year. It has traditionally offered customer feedback measurement (via online surveys and call center voice analytics) technologies across a spectrum of B2C industries like Automotive, Hospitality and Healthcare and the segment it tends to do well is the mid-market (revenue $10M to $1B). After a few years of significant investments into its AI capabilities, it has now launched a customer service chatbot product that it believes to be significantly more differentiated and effective as compared to the market leaders in this technology, namely Salesforce Service Cloud and Zendesk. Our goal is now to create a packaging and pricing structure for this nascent product.
Structuring Our Project
Later in this book I have documented two interviews that speak to the right way of structuring pricing projects, one with Jan Pasternak and the other with Joshua Bloom. I would recommend taking a look at those interviews at this stage to get some external perspectives of the process we will follow.
Whether you are an internal or external consultant, you can divide up this pricing project into the following four sections:
Alignment on Goals & Process: It is always best to have a clear discussion with the project sponsors around their goals and expectations around the impact of the project. This is also a time where you can brief them on your specific process so they understand your approach to solving this problem and have an upfront discussion on what resources you may need.
Hypothesis Generation: In this phase we will generate our own directional hypothesis of what pricing for this new product will look like, inclusive of positioning, packaging, pricing variables and pricing structure.
Testing Our Hypothesis: In the testing phase we will employ both quantitative as well as primary research methods covered earlier to understand both customer and prospect feedback to our hypotheses.
Iteration & Rollout: In this final phase we finalize the packaging and pricing based on the feedback from the testing phase and iron out the myriad elements we need to consider such that the pricing can be implemented successfully.
Alignment on Goals & Process
Expectations: Our key sponsor for this project is the VP of Product Management and she sees this new product launch as eventually becoming a new revenue generating key product line for the company. The company is a few years from IPO and it is important for the company to demonstrate new growth levers making it an attractive investment. The VP notes that the company already sells to Operations and Support buyers and this product could be a convenient sale into the same persona, and that there are already a few beta customers lined up who have begun to use the product as a trial.
Our Assessment: With an understanding of her goals, we realize that since this is an early product launch we will have limited empirical pricing data and that we will need to spend some time conducting market research. On the flip side, since this is a new product there will be limited headaches around making the new pricing and packaging work for existing clients of this product line.
In this situation, given how nascent the product is, we note that it is important for us to be directionally accurate but not extremely precise with our recommendations and it is the larger pricing framework that is more important and that executing with speed will enable ACME Inc to start selling into the market faster.
Timing & Budget: We provide a rough 6-8 week estimate of project length with 2 weeks each devoted to hypothesis generation, testing and between 2-4 weeks for rollout (depending on the amount of sales readiness needed). We also ask for a ~$10k budget for potentially conducting a WTP survey and for recruiting a pool of participants for primary research.
Hypothesis Generation
We need to generate our hypothesis around the three elements of positioning, packaging and pricing in this phase. In the following table I list out what we questions we will need to answer in this phase:
Category
Question
Positioning
What/who is the targeted ICP (ideal customer profile) and market segment for this product?
What are the primary expected benefits of the product?
What buyer personas are involved in the buying cycle?
Who are our main competitors?
What is our differentiation relative to competition?
Packaging
Given the hypothesis from positioning, what is our initial packaging proposal?
Pricing
What is our main pricing variable? (Consumption vs Capability)
What is our initial take on pricing structure?
Should we display the pricing on ACME Inc’s website?
In order to generate our hypothesis we interview the following people:
The Product Manager for ACME’s Chatbot (likely to inform positioning heavily)
An experienced AE who understands ACME’s customers and competitors (likely to inform packaging and pricing more)
Two client Program Manager’s who enrolled in the beta program (will help validate prior conversations and understand customer pain point)
Here are the quick consolidated notes of our interviews:
(One of my repeated realizations on this topic is that a non product management/product marketing consultant will not be able to go this deep, and that good pricing and packaging is always a result of good upstream positioning. There is something invaluable to have a Product Manager/Marketer go all the way and price her product herself.)
What/who is the targeted ICP (ideal customer profile) and market segment for this product?
Product was built with existing customer needs in mind, but the capability could be more usable by larger customers as the AI capability automates service issues with much greater efficiency and at high volume
What are the primary expected benefits of the product?
Reduction in customer support costs (human) - expecting to see a 30 to 40% reduction in agents required as compared to live chat
Higher consumer NPS/satisfaction
Faster issue resolution times
What buyer personas are involved in the buying cycle?
Expect to sell to Head of Customer Support
Get introduction via Heads of Digital, and/or Marketing
Who are our main competitors?
Zendesk
Salesforce Service Cloud
Both offer more robust customer service offerings, out of which the chatbot is one part of the solution
What is our differentiation relative to competition?
Much better use of AI, leading much higher automation rates
Competition’s technology takes much longer to implement, our product is self-service and can literally be built and deployed in a few days
Where are we weaker relative to competition?
The agent-side of our product is bare bones and doesn’t match what companies like Zendesk and Salesforce have to offer for large agent teams
Why would companies select us?
They have a high volume of customer service requests, with relatively small teams burdened with this volume and difficulty scaling up agent counts very high
Less complicated issues, but high volume of customer issues
Industries that would be a fit:
Gaming
Digital Media
High Growth Tech Companies
What were the main reasons clients in the beta program were interested?
Fast client business growth rates and high opinion of ACME Inc’s current product offerings.
Avoid extensive external RFPs
Furthermore, our AE interviewed revealed that she thinks this product could increase win-rates of ACME’s main product line and that this product could be ‘thrown in’ to sweeten the deal. (note that this input contradicts the VP of Product Management’s intention of making this into a successful product line, so while we may not ‘throw in’ the product, it could definitely be a promising upsell for certain types of clients)
We now have enough information to come up with our hypothesis on positioning, packaging and pricing.
Positioning
Given the info provided, we can write a summary positioning statement:
ACME Inc’s Chatbot product is a purpose built solution to automate the resolution of high volume customer service issues for high growth technology enabled companies, unlike (SFDC/Zendesk) ACME’s proprietary AI technology is able to fully automate 50-60% customer service issues and go live within days.
Packaging
Since the product is still in its nascent stage, we don’t have to fret too much about packaging except for making sure we take into account differing price elasticity for ACME’s existing mid-market segment and a potential new enterprise new prospect customer segment. The packaging differentiation could simply be offering differing service levels and an option to build custom integrations which enterprise customers often need.
Given this, we will create two different plans targeting mid-market and enterprise respectively, with the former being more of a self-service deployment model and the latter being a custom implementation with additional professional services support.
Pro
Elite
The Pro package is made for clients that handle a lesser case volume per day. Some of the features included in the Pro package are:
Base chat widget
Canned service bots
CRM integration
Tech support
Training videos
Companies with higher case volumes would see more benefits by using the Elite package. It is designed to be more customizable with a greater degree of support. Some of the features included in the Elite package are:
Special AI models
Custom service bots
24x7 support
Dedicated CSM
BI analytics
Pricing
Here is where we must make a more critical decision. We could either price as the industry does, i.e. on a per agent basis (capability model) or we could price based on the number of issues processed/automated (usage model).
Given that the best potential fit of our product will be companies with smaller agent teams AND high customer support volume, pricing on usage would both be better tied to value and offer better revenue upside (since the alternative per agent price could limit revenue potential).
In the usage based model we have a few options:
Price per automated (partially or fully) support case
Price per bot interaction
Price per any initiated chat/chatbot interaction
Price per bot step invoked
How do we decide which metric to opt for? (read Mixpanel’s pricing metric case study to further dive deep into tradeoffs involved)
The metric must be a) simple to understand b) easy to track c) tied to value d) and be predictable.
While the price per automated support cases might be the most directly related to the value we offer, it can be unpredictable with some companies being better at being able to build automations than others (read a related case study on Nosto later in the book about this). Price per bot interaction suffers from the same problem. Pricing per bot step invoked is additionally too complex for easy understanding.
We hone in our hypothesis of the main pricing metric to be around any initiated chat or chatbot interaction. This extracts value based on usage of the product, but keeps the revenue predictable as the client will still be on the hook for actually implementing the chatbots. The challenge is then to convince buyers in the sales cycle that the technology indeed performs as stated.
We are being completely cognizant that this pricing is different from the industry’s established pricing model, but what enables a different metric is that the product is sufficiently differentiated.
Hypothesis Testing
Now that we have an informed hypothesis, how do we conduct a market test?
The process we follow here is roughly:
Identify a representative market sample
Select the right interview/analysis technique
Synthesize our learnings
In order to select a representative sample we will look for high-growth technology enabled companies within the company’s customer base (this will serve as a mid-market proxy) and then get feedback from larger ‘enterprise’ firms from the broader market.
The amount of companies we can test with depends on what methods we use, who we have access to as well as our own resource constraints.
Given the newness of this product, it would be hard to get enough input on pricing from just surveys (which work well for more well established product categories). I would expect that primary research would reveal a lot more information, and we can club that with a basic pricing range survey.
Since ACME’s customer base is around 100 companies, with about 40 companies fitting the high-growth tech criteria set earlier, we should be able to get enough of a sample set from ~10 live conversations and 15-20 survey responses. In the broader market we are not so constrained, so we will attempt to survey a few hundred enterprise companies (this will generally give us a 10-15% response rate) and live conversations again with ~10 companies.
For primary research we will use the template described in the earlier chapter. Specifically our live deck will have the following sections:
Intro to the technology/product
Force rank pain points (relating to handling customer support issues)
Demo
Unprompted feedback
Force rank benefits
Open-ended feedback on pricing metric
Low price (poor quality) and High price (too expensive) bounds
To test a specific price point we would need to translate our metric to approximations that a business will understand.
Let’s take the example of warbyparker.com, on checking its traffic from sitechecker.pro the total monthly visits are around 4 Million, with an average order volume of ~$150 and a 2% total conversion rate, it would work out to a monthly revenue of $12Million. Now how do we create numeric options, both for in-person interviews or surveys?
We need anchors and industry standard assumptions.
Assuming a company such as Warbyparker spends about 10% of revenue on customer support and gets a 50-50 split in phone calls vs online support needs, and that roughly 10% of monthly visitors need help via chat. We can estimate a total spend of $1.2 Million/month on support, $600k of which is via the online channel, from about 400,000 interactions (assuming this will also automate any email support). So their customer support spend is about $1.5 per online interaction. Now we estimate that we can reduce this number by 50%, we arrive at 75 cents per interaction as the ceiling of upside we bring.
Will clients be willing to pay 10% of this? A fourth? Half?
Another way to look at this is we reduce the $600k/month number by half ~$300k/month and as a percent of revenue it works out to 2.5%. Can we charge .25% of revenue or .5%? These are our anchors which we will quote side-by-side with the cost per interaction.
While this can be explained in-person, it will need to be posed a few different ways in a survey for us to converge on a good answer.
Here is what one of the survey questions will look like with different anchors:
Q. Below what price (cost per interaction) will you question the product’s quality or effectiveness?
• 60 cents per interaction (~2% of revenue)
• 50 cents per interaction
• 40 cents per interaction
• 30 cents per interaction
• 20 cents per interaction
• 10 cents per interaction
• 5 cents per interaction (~0.20% of revenue)
Here is another way to ask this question again, with different anchors:
Q. Below what price (cost per interaction) will you question the product’s quality or effectiveness?
• 60 cents per interaction (~20% of total support costs)
• 50 cents per interaction
• 40 cents per interaction
• 30 cents per interaction
• 20 cents per interaction
• 10 cents per interaction
• 5 cents per interaction (~2% of support costs)
Let’s now assume we conduct the primary research across our two key segments, the following is an example of what aggregated feedback could look like:
Topic
Mid-market customers
Enterprise customers
Top pain points (from force rank)
Top rank by 7/10 customers, “personnel crunch with inability to scale to demand at peak times”
Second rank by 5/10 customers, “high cost of phone support”
Third rank by 6/10 customers, “customer complaints due to long phone and chat wait times”
Top rank by 8/10 customers, “customer complaints due to long phone and chat wait times”
Second rank by 5/10 customers, “personnel crunch with inability to scale to demand at peak times”
Third rank by 6/10 customers, “cumbersome agent-side workflows”
Unprompted feedback on the demo
“This is cool, seems like we can offload a large chunk of our support issues to a bot”
“It will help reduce our need to constantly hire”
“As a tech company, we like such a seamless tech solution vs throwing humans at the problem”
“This looks like it could mitigate customer hold times and improve NPS”
“Would be a nice addition to have during peak season”
“I wonder if we can also offer the automation to our agents who have to deal with clunky manual workflows in our current system”
Unprompted feedback on features within package
“I like it, it's simple yet effective”
“We might want a little bit more service available as this is a new tech for us”
“The BI capability is important for us to measure our performance. Can we equip all our managers with it”
“Can we build customer feedback bots to measure quality?”
Top benefits (from force rank)
Top rank by 8/10 customers, “reduce personnel costs”
Second rank by 5/10 customers, “move to digital channels”
Third rank by 6/10 customers, “increase customer NPS”
Top rank by 7/10 customers, “increase customer NPS”
Second rank by 6/10 customers, “move to digital channels”
Third rank by 5/10 customers, “reduce personnel costs”
Open-ended feedback on pricing metric
“I think it can work as long as the price isn’t exorbitant”
“I like that it scale with usage, we don’t like paying a large capex type amount”
“Our online analytics vendor uses a similar metric”
“We pay our current vendor on a pay per seat, but I understand this is a different concept”
“The metric is fine, I hope you can discount it because our usage will be high”
“We’re ok with the metric as long as the product actually automates as much as you claim. A pilot will help”
“We will use this with our main support solution, so it would help to only pay for when we really use it”
Price below which product will be deemed poor quality
The mode (highest freq selection) for this question comes out to be 10 cents per interaction
The mode (highest freq selection) for this question comes out to be 30 cents per interaction
Price above which product will be deemed too expensive
The mode (highest freq selection) for this question comes out to be 40 cents per interaction
The mode (highest freq selection) for this question comes out to be 70 cents per interaction
And here is a summary of the output of the WTP survey (refer our discussion on cumulative survey tables in the prior chapter):
Mid-market-Enterprise
Based on this feedback we can surmise that the mid-market customers a) care more about the cost of providing support (often because of high cost phone channel usage and personnel required) and that customer satisfaction is important but a second priority b) they are more price sensitive than enterprise on price point, with the highest frequency WTP (85% willing to spend) occurring at 30cents per interaction. Enterprise customers care more about customer satisfaction and NPS scores, as well as an ability to be agile to customer needs. Their highest frequency WTP (55% willing to spend) occurs at 50 cents per interaction.
It seems there is no significant resistance to the pricing metric itself.
The feedback on packages themselves is largely validating our hypothesis, with a few differences. It seems even mid-market customers may need more support and enterprise customers asked about consumer feedback measurement.
We will now take this feedback into account into refining/defining our pricing and packaging model in the next section.
Iteration & Rollout
Finalizing Our Pricing & Packaging
Pro
Elite
We tweak this package to include more service options.
Base chat widget
Canned service bots
CRM integration
Tech support
Training videos
Add-on: Bundles of Service Hours
30 cents per interaction with a gradual volume discount down to 20 cents per interaction.
We will select the 3 part tariff as it has proven to have the highest uplift in revenue, as we read in the prior chapter.
Additionally, we will set overage pricing higher than the average unit price of the main bundle to incentivize customers to move up a bundle.
Pro Pricing
Included Average Monthly Interactions (x12 for year)
Price
Overage
25,000
7500
40 c
50,000
13,750
35 c
100,000
25,000
30 c
200,000
45,000
25 c
300,000
60,000
25 c
And so on...
We highlight here an existing ability of measuring customer feedback as a separate entity (which we will also tweak as a separate module in the product). It shows us the importance of drawing out and naming features that add value.
Special AI models
Custom bots
Customer Feedback bot
24x7 support
Dedicated CSM
BI analytics
60 cents per interaction with a gradual volume discount down to 40 cents per interaction.
We will select the 3 part tariff as it has proven to have the highest uplift in revenue, as we read in the prior chapter.
Additionally, we will set overage pricing higher than the average unit price of the main bundle to incentivize customers to move up a bundle.
Elite Pricing
Included Average Monthly Interactions (x12 for year)
Price
Overage
25,000
15,000
70c
50,000
27,500
65c
100,000
50,000
60c
200,000
90,000
55c
300,000
120,000
50c
And so on..
Operational Decisions
Should the new pricing be on the website?
This depends on the GTM model. Right now the product is new and we won’t be dedicating a large chunk of the sales team to selling this. Hence, it might be better to show the pricing and packaging during the sales process and not on the website. As the process scales, and we have more sales and marketing budget to devote to this product, publishing pricing on the website at that time will help increase deal velocity.
What sales collateral will we need?
We will need the following:
A packaging grid listing out all the features per package along with constraints
A sales deck / first call deck for the product
An excel based pricing calculator
A working demo with a demo script
How do we get ops ready?
We will need the following:
Making sure CRM/CPQ is updated with these 2 new SKUs
Making sure a SOW template is ready for the product
Ensuring verbiage around the usage limits per interaction is included in Order Forms along with language around overage rates
.png)
.png)
