top of page

Why AI pricing recommendations get ignored by your own team

  • 5 days ago
  • 3 min read

Introduction


A firm buys a pricing tool, it produces sensible recommendations, and six months later everybody is quoting the way they always did. This outcome is so common that it is worth treating as the default rather than as a failure of a particular product.

The reason is rarely that the numbers were wrong. It is that a recommendation asks a person to accept personal risk for an impersonal benefit. If the higher price loses the job, the salesperson explains it in a meeting. If the higher price wins, the margin appears in a report nobody attributes to them. Every incentive points at ignoring the recommendation, and no amount of model accuracy changes that.


1. Why AI pricing recommendations get ignored is a question about risk


Not about accuracy.

The person quoting bears the visible cost of a lost deal and receives none of the visible credit for a protected margin. Until that asymmetry is addressed, better recommendations produce the same behaviour.


2. A recommendation without a reason is not usable


People cannot defend a number they do not understand.

"Quote £4,200" is unusable in a conversation with a customer. "Quote £4,200 because comparable jobs at this specification won at £4,100 to £4,400" is defensible, and defensibility is what determines whether it gets used.


3. Check what the salesperson is actually measured on


The answer is usually revenue.

If commission and targets are set on turnover, then discounting is rational behaviour and the tool is asking for irrational behaviour. Moving even part of the incentive onto gross margin changes the outcome faster than any feature.


4. Override should be allowed and recorded


Blocking it fails.

A hard floor with no override gets circumvented, usually by restructuring the quote. Permitting an override, with a reason and a name attached, keeps the practice visible and makes the pattern analysable, which is what you actually want.


5. Show the override rate to the people overriding


Visibility changes behaviour on its own.

A simple monthly figure — recommendations followed, overridden, and the margin difference — alters conduct without a policy. Most people do not want to be the outlier and had no idea they were.


6. Introduce it on the segment with least fear


Sequencing matters.

Start where losing a job is survivable: small work, low-stakes repeats, new enquiries from weak sources. Wins there build the confidence needed for the large quotes, and a failure there costs little.


7. Pilot with the results published either way


Credibility is the objective.

Run the recommendation on half the quotes for a quarter and report win rates and margins for both halves honestly. A published result that shows a small win rate drop and a larger margin gain settles the argument that no amount of assertion will.


8. Accept that some recommendations should be overridden


The model does not know everything.

A strategic account, a reference customer, a job that fills an empty week, a relationship worth protecting. These are legitimate reasons, and a system whose advocates deny they exist loses the trust it needs.


9. Give it an owner who is not the vendor


Adoption needs a person.

Someone inside the business has to review the overrides, correct the inputs, and answer questions about why a number came out the way it did. Tools without an internal owner are abandoned regardless of how good they are.

Watch the inputs as well. Recommendations degrade quietly when cost data goes stale, and a tool that quotes from last year's material prices earns the distrust it receives.


Conclusion


Treat adoption as an incentive and confidence problem rather than an accuracy problem.

Give every recommendation a reason the salesperson can use in front of a customer, check whether your own targets reward the behaviour you are asking for, allow overrides but record them with a name and a reason, show people their own override rate, start on the segment where losing a job is survivable, run a published pilot with the results reported either way, accept that some overrides are correct, and give the tool an internal owner who keeps the inputs current.


Related reading


 
 
 

Comments


bottom of page