Everyone who builds quoting software starts with pricing. Then they watch a real request come in and find the hard part is somewhere else: working out what the customer actually asked for.
A distributor's requests for quote do not arrive as clean tables. They come as a forwarded email with a pasted list, a PDF exported from the customer's purchasing system, a photo of a handwritten sheet, or three lines typed by an engineer between meetings. A recent thread on r/ERP, from someone building AI quoting for distributors, describes exactly this: the difficult parts were not the ones they expected.
What is actually in a request
Take a typical 14 line request from a maintenance manager. Some lines are clean part numbers from your own catalogue. Others are not:
- Customer part numbers
Their own code for an item you sell under a different number.
- Competitor numbers
A rival's part number, because that is what is printed on the old box.
- Descriptions
"Belt for the main conveyor, same as last time."
- Instructions
"Deliver to gate 3", "need by Friday", "split shipment OK".
That last kind matters most. A line that says "need 2 of these by Friday, rest can wait" is not a product. It is an instruction that changes the quantity and the delivery of two other lines. A system that treats it as an unknown item and drops it has quietly quoted the wrong quantities.
Why dropping a line is worse than flagging it
There are two ways to get a line wrong. You can flag it for a person to check, which costs a few seconds. Or you can silently get it wrong: drop an instruction, match a description to the wrong item, read a box quantity as a unit quantity. That costs money and trust, and nobody finds out until the order arrives.
A system that flags too much is annoying. A system that guesses silently is dangerous.
So the useful question is not "how many lines does it handle without a person?" but "when it is unsure, does it say so, and does it say why?" A good quoting tool separates products from instructions first, matches what it can with a stated basis (same part number, cross-reference, or a match by description), and puts the rest in front of a person with the reason it stopped.
Count quotes, not lines
The same r/ERP thread made a point I agree with. Measuring the share of lines that need a human is the wrong unit. If one line in five gets flagged and the flags are spread evenly, nearly every 14 line quote still needs a person to open it. Nothing has changed for the rep.
What changes the job is when flags cluster: on a few new customers, on free-text descriptions, on one awkward product family. Then most quotes go straight through, and the rep's time goes to the few that need judgement.
Then price it
Only after every line is matched, in the right unit, with instructions applied, does pricing start. That is where the margin is, and it is what Elastly was built for. But I have stopped thinking of quoting as a pricing problem with some data entry in front of it. It is a reading problem first.
The distributors who quote fastest are not the ones with the cleverest prices. They are the ones whose systems read a messy request correctly, say plainly when they are unsure, and learn the customer's own part numbers so the same question never has to be asked twice.