Welcome back to Crescendo Insights, where we provide a bite-sized piece of monetization strategy each week.

If you’re not a subscriber yet, hit the button below to keep getting these emails delivered to your inbox.

The BLUF (Bottom Line Up Front)

1. Customer interviews let you assess price metrics across all 4 necessary elements, but they really shine in communicability.

2. How you ask questions in interviews is important to distinguish between price sensitivity and price metric sensitivity.

3. Outcomes-based pricing and token-based pricing are two examples of poor communicability in price metrics. Use interviews to see if they are viable for you!

Introducing Monetization Diagnostics

After a brief turkey-filled hiatus, we’re back with more pricing content. But before we get to that, I wanted to let you know about a new offering here at Crescendo. We’re calling it a “diagnostic” - it’s a quick sprint to get you answers to all of your pricing questions in weeks, not months. We’re already booking up for January and February, so if you’re interested, reach out ASAP!

Talking to Customers About Price Metrics

The last time we posted, we talked about the quantitative signals you can see in your own data indicating you have a price metric problem. What if you don’t have good data though? Or what if you’re a startup and have no data? That’s where primary research (aka talking to customers) comes in. Today we’ll tackle how to assess your price metric through customer interviews, including some pointed questions and actual quotes we’ve heard.

Let’s dive in.

The Magic of Customer Interviews

Remember the 4 elements that make a good price metric? Good price metrics need to be feasible, communicable, segmentable, and valuable. While data analysis can help you with the last two, customer interviews can address all four! And every company can do customer interviews, so you really don’t have any excuse…

Valuable: Your metric doesn’t track willingness-to-pay

It’s not always easy to see whether a customer would pay more if they were charged off of a different price metric. You often end up conflating price level (would they pay more in general) with price metric (how would they like to pay). So how can we disentangle these?

One way is to do it explicitly. Something like…

But that’s a little bit forced. Let me replay a conversation I had in a customer interview that reveals a customer’s preference without putting on my Captain Obvious hat.

Should the company above charge for users or integrations? Integrations. They are planning on getting more utility out of the platform without hiring developers. In other words, their utility (and willingness-to-pay) is more closely tied to integrations than it is to users. Here’s another example:

The number of reports is poorly predictive of value here and monetizing reports will make customers feel like they are being “nickel and dimed”.

Feasible: You can’t track and enforce your price metric

This one is almost too easy to test. If there is any risk of customers “cheating” on their price metric (sharing logins, misrepresenting size, etc.) then that price metric is a “no go”.

“But Ian, do customers actually admit to cheating their price metric?!?!?” - you, dear reader.

All. The. Time. Sometimes they’re bragging, but you can also coax it out of people by asking questions like this…

Another issue with feasibility arises when you and the customer disagree about the true metric, or if the customer has no way of self-reporting the metric. Good metrics need to be objective; if a customer has any doubt that a metric is incorrect, it will hurt your ability to charge for it.

Communicability: Explanations and expletives

Communicability is the most important thing to test in customer interviews because interviews are THE ONLY tool at your disposal to test it. Remember, communicability is 2 things: 1) do customers understand the metric and 2) are they going to be pissed off that you’re charging for it?

Lack of understanding is the more common problem. It looks something like this:

Here, the value the customer gets may be correlated to API calls, but it’s completely obscure. This is the #1 issue I am seeing these days with AI pricing. When you price using a fabricated metric (tokens, usage units, “scroobles”, take your pick), you are inherently obscuring the price.

Then there is so called “outcome-based” pricing, where you attempt to peg the price to some result you generate for the customer. In theory, this works great. I save you 15% on customer support costs, therefore you give me a cut. HOWEVER…

I can count on 1 hand the number of outcome based pricing models I have seen that have worked. Why? Because in almost every outcomes based model, you cannot prove that it was your product that produced the outcome.

What if I flipped it around. If a customer didn’t experience the result you promised, would you take full responsibility? Probably not…

Here is a real quote from a customer when we floated an outcome-based model.

Communicability is also where customers get emotional. And by emotional, I usually mean angry. If customers think that a particular price metric is unfair, they will tell you in no uncertain terms. One time, I floated the idea of pricing hedge fund software as a percentage of the profits of each trade. Below is a not-that-over-dramatized customer quote:

I have seen outcomes-based pricing fail in industries as diverse as education, marketing technology, and obviously fintech. Stay tuned for cases on when it worked!

Segmentability: All the customers are the same

Admittedly, customer interviews are not the easiest way to judge a metric’s segmentability¹ . But, in the absence of solid data or quant studies we have to rely on interviews. One way to look at segmentability is to ask how a metric has changed over the life of a company, presumably as the company has moved between segments.

Another signal is when customers think of a metric as binary or table stakes. If adding more of a metric is not useful, but removing any of the metric makes the product break, it likely fails the segmentability test.

Case Study: Sierra’s Outcomes-Based Pricing

Sierra, an AI-based customer experience platform valued at $4.5 billion, recently announced the move to an outcomes-based pricing model. They will now charge for every “resolved conversation” than their AI handles. If a customer conversation is unresolved (presumably because the AI couldn’t handle the request), there is no charge. In theory, this sounds like perfect price - value alignment. The problem is in their new metric’s feasibility and communicability.

As is the case with most outcomes-based pricing models, Sierra will have to define and communicate what a “resolved” conversation actually entails. Then, they will have to convince customers that the resolution (or lack thereof) was due to Sierra’s AI.

When you call customer service, how long does it take for you to say “speak to representative” into the automated bot’s ear on the other line? For me, it’s immediate. Does that mean Sierra doesn’t get paid?

What if the customer ends the chat in frustration? Was that conversation “resolved”? How do you tell the difference between a conversation that was resolved well and one the was resolved poorly?

This is the type of friction that Sierra is going to run into. I saw this friction firsthand while interviewing customers for…you guessed it…an AI customer experience automation platform² . Here is a real quote from a customer - remember, they are solving exactly Sierra’s use case.

Did we recommend outcomes-based pricing, like Sierra? Absolutely not. How customers feel about a price will often overpower even the cleanest theoretical price metric. I wish Sierra the best with their new pricing, but worry that it will be an uphill battle for them.

Get in touch

Crescendo works with medium-sized software companies to improve their pricing, packaging, and promotion strategies. If you’d like to book a quick consult, reach out at [email protected] or schedule time via the button below.

1  Whether the need for a metric differs significantly among customers

2  Not Sierra, in case you were wondering