Who should classify your components, you or the software?

Before a quoting platform can calculate attrition, it has to know something about each component. The question worth asking any platform vendor is who supplies that knowledge.

If the answer is a person, then the platform has a data model that needs feeding and your quoting team is feeding it. Line by line, upload by upload. This is a surface mount capacitor. This is an expensive IC. This one is a connector, and yes, again on the next bill of materials.

‍

It is not an unreasonable design

If attrition rates are genuinely modelled per component type, the model needs the component type, and asking the person who has the BOM open is the most direct and most accurate way to get it. A human looking at a line item is a very good classifier.

It also produces consistency in a large organisation. If a hundred people across four sites are quoting, having each of them state the component type explicitly means the model is fed the same way everywhere, and the variance you would otherwise get from inference does not appear.

That is a real benefit. It is just a benefit that scales with the size of the organisation, while the cost scales with the number of line items, which does not. And the cost has a specific shape: somebody has to be in the loop on every upload, every time, before the model can run at all.

‍

The alternative is automation

The distinction that matters is not which attributes a model reads. It is whether a person has to be involved before it can read them.

Breadboard calculates attrition automatically, from data already in the BOM, by two methods. The first keys on package code. The second keys on the unit cost of the component. An 0402 at a fraction of a cent behaves differently in placement and handling from a connector at several dollars, and both of those facts are sitting in the file before anyone types anything.

Both methods are fully customisable. You define the categories and you set how much attrition each one adds. That is a configuration decision made once, by whoever owns costing at your shop, and then applied the same way to every BOM afterwards. It is not a judgement re-entered line by line on every upload, and it is not somebody else's industry average standing in for your process.

The practical consequence is not philosophical, it is a number of clicks. Nobody is asked, at upload, to tell the system what any line is.

Is a configured rule as precise as explicit classification? For an unusual part in an unusual package, an experienced person will sometimes be more "right" than a table. The question is whether that additional precision is worth what it costs across every line of every BOM, and for most shops between 25 and 150 people the answer is no. The rules are also where you capture the places you already know a generic table would be wrong, which narrows the gap before the first BOM is ever uploaded.

‍

The same argument applies to manufacturer names

A related tax shows up in manufacturer mapping. A supplier abbreviation arrives in your BOM export from your ERP. You tell the platform what it means. Next week, same abbreviation, same export, and you tell it again.

This usually happens because the platform keeps one master mapping table shared across every customer, which is a defensible choice. If any customer could edit the master list, one bad entry would propagate to everyone. The safe answer is to take nobody's word for it.

The cost of that safety lands on the person uploading. There is a version that gets both, which is a per-account override layer on top of the shared master table. You teach it once, it holds for your account, nobody else inherits your correction, and the master table stays clean.

‍