In this post, I will share with you something I learned as a consultant working with Configure Price Quote vendor software. It is basically pre-built app, that the customer or modeler can adapt to their business model and requirements

This kind of approach is mostly used when the answer to the client’s question/request is NO, but there is also something good in it (upside or a good alternative). If they asked a question incorrectly (something that can be done both ways), then elaborate that the actual requirement is a NO, but what they really need is a YES.

Example : Can you edit configuration data of a product from within a Quote page?

Answer: Yes and No. We do not support that trough UI customization and easy setup configuring, but Yes, we do have some scripting capabilities that could help in some instances. But, although scripts can change the configuration, there is no UI to allow people to play around and define what would be changed.

This is an example with little to no chance of Yes answer, but you can also ask:

• No, but let’s see what are your exact use cases?

• That can be a problem, tell me more details around your exact requirement?

There is no point in giving “Firm No” answers, except if the question is crystal clear, and we can’t do much about it.

Example 2: Can your software provide scheduled actions that do certain job at certain times?

This is a clear No (This is the case with vendor software, so no heavy customizations without software upgrade).

But, if the question is: Can CPQ software provide automated approval reminder after X days? Then, you can say: Yes and No, and propose a good alternative with approval reminder action.

Yes and No approach is mostly used when the question is asked the wrong way, due to lack of CPQ knowledge of Customer asking. So, in all essence - the answer is No, but I do think that you are interested in ‘this and this’ - and there lays the Yes answer.