Insights

What should RFQ quoting software check before it prices an aircraft part?

A client record in aersyn.ai: the customer quote history lists each part number with its condition, quantity, price, date and status, next to the vendor quote history panel.

Before it prices an aircraft part, quoting software has to check three things: the part number, the condition the buyer asked for and the price rule you set for that client. Condition is the one most often skipped and it is the one that moves the price. A quote built from the wrong line of your history looks perfectly credible, which is exactly why nobody catches it.

Why does condition change the price of the same part?

Because the same part number is a different product in each condition. The condition codes tell you which one you are selling: NE is new, SV is serviceable, OH is overhauled and AR is as removed. The condition sets the price and also decides which certificates travel with the part, so trace is part of the same question.

Take a part number that appears four times in your history. You sold it overhauled with an 8130-3 to an airline a year ago. You sold it as removed to a broker last month, for much less. There is an old quote in NE and a purchase in SV. Now an airline asks for it overhauled with an 8130-3 and you have one on the shelf. Only one of those history lines is the right reference and it is not the most recent.

What goes wrong when software prices from raw history?

It fills the gaps with the most probable line and the most probable line is the most recent one. The quote comes out clean and the price is the one from the as-removed sale to the broker.

I call this a silent hallucination: an answer built on your own data that is credible and wrong, because the data could be read several ways. A price of zero shows at once. This one looks right and that is why it passes. The customer finds the price very good and orders. Nobody ever tells you that you left margin on the table.

So what should RFQ quoting software check?

Three things, in this order.

  1. The part number. Including the way the customer wrote it and any alternate part number you hold.
  2. The requested condition. Each RFQ line carries one and each line of your history carries its own. The two have to be compared, not guessed.
  3. The price rule for that client. The price should come from a rule you wrote for that client tier, not from whatever the last sale happened to be.

Your senior trader does all three in a few seconds without noticing. A new hire, under pressure, often reuses the last sale and most of us have done it. Software has to do the senior’s version.

How does aersyn.ai handle it?

aersyn.ai reads the part numbers, conditions and quantities on every RFQ, checks them against your stock and your last quotes and applies the pricing rules for the client tier, T1 to T4, before a number reaches your trader. The client’s quote history sits on the screen with the condition of each line, so the trader sees what was sold and in what state. The price comes from the rule you set. Your trader then reviews the draft and decides.

That is the human-in-the-loop model applied to condition: the system lines the evidence up and the person who knows the relationship makes the call. The whole cycle is on the product page and the plans are on the pricing page.

How can you check your own desk?

Pick a part number that appears in your history under more than one condition. Look at the last few quotes you sent for it and check which price each one used. If any of them used the price of a different condition, you have found the leak and it was invisible because every one of those quotes looked right. The broader picture of where else a desk loses money without noticing is in the 4 silent revenue leaks.