Build a 5-Part RFQ Package for Lithium Battery Manufacturers

A usable RFQ package for a custom lithium-ion pack has five parts — electrical, mechanical, BMS, test evidence, and commercial terms — plus one rule that decides whether the whole thing works: every supplier responds in the same structure, in the same file, with the same assumptions written down in the same place. Standardize the response, not just the requirement. Otherwise you receive five documents answering five slightly different questions, and the lowest number on the page is usually the one with the least scope standing behind it.

I have spent more afternoons than I want to admit with five bids open in five tabs, and the tell is always the same. Three of them quote the same nominal capacity. One is at 0.2C, one at 1C, one does not say. Two list a bill of material, one lists "battery pack assembly" as a single line with a single price, and one attaches a photo of a cell label instead of a datasheet. One has a checked box next to UN 38.3. By the time I close the tabs I have not learned which supplier is cheapest. I have learned which suppliers read the same document I wrote.

So the package is not a spec sheet with a cover letter. It is a container.

The workbook comes before the words

I build the response template first, as a spreadsheet, and the specification document second. That order matters because whatever shape I ask the answer to arrive in is the shape I will be comparing in. If I write a beautiful forty-page requirement in a PDF, I get a PDF back, reformatted, with my questions answered in prose and my numbers restated in whatever units the sales engineer prefers.

What goes in the workbook: a BOM tab with locked columns for cell, BMS, housing, interconnection, and assembly, each with quantity, unit of measure, make and model, and a column headed "excluded from this quote." An assumptions tab where the supplier must state the cell they are designing around, the discharge rate and cutoff behind their capacity figure, the test conditions behind their cycle life figure, and the standard they are certifying to. A commercial tab for MOQ, lead time, tooling, NRE, and payment milestones, with no blank cells allowed. And a deviations tab, which is the one most buyers skip and the one I read first.

That last tab does a lot of quiet work. When a supplier has to write down what they are not including, they stop assuming the omission will be discovered after the PO.

Part one: electrical, stated as test conditions

The capacity number is where bids go wrong first, because "10 Ah" is not a specification, it is a headline. I require capacity at a named C-rate, at a named temperature, down to a named cutoff, at beginning of life, labeled as minimum or typical. I also require the continuous and peak discharge currents with duration for the peak, the charge profile, the operating voltage window, and the cycle life figure with the depth of discharge, C-rate, temperature, and end-of-life retention that produced it.

Leave any of that open and the returned numbers spread across a range that has nothing to do with supplier quality. A pack cycled to 80 percent retention at a mild rate and moderate temperature is not the same product as one cycled to the same retention under a harder regime, even though both say "80 percent." The RFQ has to make the regime part of the specification, or the comparison is fictional.

I also ask for the internal resistance target and how it is measured, because that number drives heat, and heat drives the field failures nobody attributes to the quote.

Part two: mechanical, returned as a marked-up drawing

Prose descriptions of an enclosure produce prose disagreements later. I send a controlled drawing with the envelope, mounting points, connector locations, and tolerances, and I ask for it back marked up with every deviation called out.

Beyond dimensions: enclosure material and wall thickness, ingress protection rating with the test method and the standard behind it, drop and vibration requirements with the referenced procedure, connector and terminal part numbers from named manufacturers, and whether the pack is potted, wrapped, or mechanically retained. If the pack goes into a product with a thermal path, I want the thermal interface described and the expected heat rejection at continuous load.

The marked-up drawing is a qualification artifact. A supplier who returns the drawing untouched either read it carefully or did not read it. Asking two follow-up questions tells me which.

Part three: BMS, where vague language costs the most

"Smart BMS" is a phrase that should never survive into an RFQ. What I ask for instead: the protection IC family and vendor, the FET configuration and continuous current rating, overvoltage and undervoltage thresholds per cell, overcurrent and short-circuit trip points, the number and placement of temperature sensors, the balancing method and current, the state-of-charge estimation method and its claimed accuracy band, and the communication protocol with a commitment to supply the protocol document.

One more question, and I put it near the top of the tab: is this a catalog BMS or a custom design? That single answer moves the commercial side of the bid more than anything else in the package, because custom BMS work shows up as NRE, as schedule, and as a firmware owner you will be negotiating with for years.

I ask for a functional block diagram too. Not because I cannot read a datasheet, but because a supplier who can produce one quickly has actually engineered this configuration before.

Part four: test evidence, with report numbers

This is the section that separates a real bid from a placeholder. I require report numbers, the issuing laboratory, the date, the standard revision, and — critically — the exact model designation tested, so I can compare it against the model being quoted.

UN 38.3 is where I see the most expensive misunderstanding in the whole package. A supplier writes "UN 38.3 compliant: yes," and what they mean is that the cells carry a UN 38.3 test summary from the cell maker. That is not the same as the pack having been tested as an assembly in the configuration you are buying. The cell report covers the cell. Your pack, with your BMS, your housing, and your interconnection, is a different article for transport purposes. If I do not pin that down in the RFQ, I find out at the freight forwarder, on a schedule I cannot move.

So the RFQ asks explicitly: is pack-level UN 38.3 testing included in this quotation, and if so, at whose cost, on how many samples, and with the report delivered to us? Same treatment for whatever safety standard applies to your end product. I list each standard I expect evidence for, note whether it is required at award or required before first shipment, and require the supplier to price it as a separate line rather than folding it into the unit price. Folded-in test costs are impossible to compare and easy to quietly delete later.

Where a report exists for a similar but not identical configuration, I want that stated in the deviations tab with the differences listed.

Part five: commercial terms, asked once and in writing

MOQ in units, and separately the cell-level minimum that drives it. Lead time split into two numbers: sample or first-article timing, and recurring production timing, because a single lead-time figure usually describes the optimistic case. Tooling and NRE itemized by line, with ownership stated and with a clear answer on whether tooling is charged once or amortized into unit price. Payment milestones tied to something observable — sample approval, first-article acceptance, functional test sign-off — rather than to calendar dates. Quote validity period. Price breaks at the volumes I actually forecast, not at a round number the supplier chose.

I do not draft contract language in the RFQ and I do not try. What I want at this stage is the shape of the deal in comparable fields, so the lawyers are arguing about wording later instead of about whether the scope was ever discussed.

Normalizing what comes back

When the bids land, the first pass is not a cost pass. It is a scope pass. I add a column to the comparison called scope delta and I fill it by reading the deviations tab against the exclusions column of the BOM, line by line.

The UN 38.3 case is the cleanest example. One bid includes pack-level testing with a report delivered to us. Another excludes it and notes that cells are certified. Those two bids are not comparable at face value, and the difference is not a discount — it is work that has to happen somewhere, on someone's schedule, before the product can move. Bringing the excluded scope back into the comparison at the point where it will actually be incurred is the step that turns a bid into a landed number. Same treatment for tooling that one supplier amortized and another billed up front, for testing one supplier scoped at award and another scoped at first shipment, and for payment terms that change the cash profile even when the unit price is identical.

The number that comes out of that exercise is rarely the number that led the bid sheet. That is the whole point of doing it.

Gates on the left, scores on the right

My evaluation matrix is two matrices wearing one hat.

The first is pass or fail, and it runs before anyone looks at price. Does the bid meet the electrical specification as written? Is pack-level test evidence included or credibly scheduled? Does the BMS have documentation and an identified design path? Are the commercial terms answered rather than deflected? A bid that fails a gate is out, and I write the reason down so that the decision survives the meeting where someone rediscovers the low number.

I am deliberate about the ordering because price is sticky. Once a low bid is on the screen, every subsequent judgment bends toward it. Gating first removes the temptation to talk myself into a supplier who simply answered fewer questions.

The second matrix is weighted scoring across cost, manufacturing capability, schedule confidence, quality system maturity, and engineering responsiveness. Weights come from the program, not from habit. A program with a hard launch date weights schedule harder. A program with a long field life weights quality harder. Cost is a weighted criterion here, not the tiebreaker.

What the package actually buys

Not a lower price. A comparable one, delivered earlier in the process than it would otherwise arrive.

The real return is that the argument about scope moves from month nine to week two, when it is still cheap to have. Every ambiguity I leave in the RFQ gets resolved by the supplier in the way that is best for the supplier, and I pay for that resolution later in rework, in schedule, or in a test campaign I did not budget. Writing the five parts tightly is boring work. Reading five bids that all answer the same questions is not.