Taking value-based pricing too far

Jonathan Christopher writes about taking value-based pricing too far.

He addresses the popularity of value-based pricing, as well as its tendency to be defined many ways. But he ends up focusing largely about some of the common pitfalls of not talking money early, and managing value pricing while also making good use of our time, as well as our clients' time:

Providing the highest value for a client should take into consideration their budget. We are likely dealing with a never-ending flow of inquiries, spending time on proposals is not something we should take lightly. In an ideal world yes, the budget would not be a consideration and the client would be ready to spend what it takes to get their problem solved. There is truth in that, I agree, but at the same time I feel that a budget gives a discussion gravity, something to facilitate a wise use of time.

I frequently enter conversations where either I or the potential client is anxious to start talking money. For me, it's because I'm afraid based on early indicators that there isn't a budget. For some clients, they want to know if they can afford me or they just want to check another person off their list while price shopping. Both are understandable.

Value pricing, I think, is often inappropriately conflated with flat rate pricing. Flat rate pricing simply provides a ceiling for the client, but most flat rate projects are estimated upon hours expected that we'll spend. True value pricing takes a lot of work, because you have to do research to identify what is valuable to a particular type of client.

If I'm being totally honest, I do a lot more fixed rate pricing than true value pricing. I did it today when talking to a potential client — and the client had even read my article on pricing WordPress websites before we engaged in the conversation.

Especially with lower priced projects (in my experience, less than $10,000 is probably a decent barrier), the sale justification may be centered on value but the true calculation on my end more often ends up being a simple fixed-rate hourly estimation.

Similar Posts