Every Gap in Your Battery Pack Sample Request Gets Filled In by the Supplier

A sample request is a requirements document, not a shopping message, and every line you leave open in it gets filled in by the supplier. That is the whole mechanism behind a mismatched sample: it is rarely a communication failure, it is a specification failure. The lines that actually decide the build are the target electrical specification with tolerances, the BMS protocol and required signal list, the connector and harness definition, the enclosure and IP target, and the label and marking requirements. Pin those and you are evaluating your own requirements. Leave them open and you are evaluating the supplier's defaults.

Sit at my bench for a minute. There is a 6S2P pack in front of you, wrapped in black shrink, two leads out the end, a BMS board you can feel under the wrap but not see. You put a caliper across the widest point and get 4 mm more than the cavity in your enclosure. You reach for the harness you already built and the connector is not the one on the pack. You clip onto the CAN pair and the analyzer sits silent, because the board was set up to broadcast a couple of voltages and nothing else. None of that is the supplier being sloppy. Each of those three mismatches started as a blank cell in my request, and the supplier filled it with the most reasonable default it had on the shelf.

The blank line is an instruction

That reframe is the thing I wish someone had put in front of me years earlier. When you write "6S2P pack, ~22V, XT60, with BMS" and hit send, you have not left the rest unspecified. You have told the supplier to choose. And the supplier's choices are optimized for its own build flow, its own stock positions, and its own idea of what a reasonable customer wants. That is not malice. It is just the only thing it can do with a partial document.

The failure shows up later as a conversation. The supplier says the sample is to spec. You say the spec was never written down in the first place. Nobody wins that argument, and it costs you weeks you did not budget.

So the request has to be a requirements document. Not long, necessarily. Complete on the lines that move the hardware.

The five lines that decide the build

Electrical specification, with tolerances

Nominal voltage and capacity are the least useful numbers on the page without limits attached. State the operating voltage window, the continuous and peak discharge current, the charge current, the cutoff thresholds, and the tolerances you will accept on capacity and internal resistance at the pack level. If you need the pack to hold up at a low-temperature discharge, say so, because that changes cell choice and sometimes changes the whole architecture. A capacity target with no tolerance is an invitation for the supplier to test at a temperature and rate that flatters the number.

The BMS is a protocol document

This is the line buyers skip most often, and it is the most expensive one to skip. What you need in the request is the communication interface, the protocol it speaks, and the explicit list of signals you expect to read: pack voltage, cell voltages, temperatures, state of charge, current, fault flags, and whatever else your system actually consumes. Then the hardware side of it, meaning the transceiver, the wake line, the enable line, the isolation if there is any. A BMS that works perfectly and speaks a protocol your controller does not read is a dead board with a nice heatsink.

Connector, harness, enclosure, label

Two things go here that get treated as details and are not. The connector needs a part number, not a family name, plus pinout, wire gauge, harness length, and how the harness is dressed and strain-relieved. The enclosure needs dimensions with a tolerance and an IP target stated as a rating you will actually verify, along with the material and the mounting points. And the label and marking need to be specified down to the content, the placement, and the durability you expect, because a pack that cannot be identified on your line is a pack that gets quarantined.

If a line genuinely is open, do not leave it silent. Write that it is open and require the supplier to state the assumption it made. A declared assumption is something you can evaluate. A silent one is something you discover later with a caliper.

Acceptance criteria you did not write are the supplier's

Every supplier has internal limits for what counts as a passing pack. Those limits are usually wider than your application needs, and that is rational, because they were built to cover a broad customer base rather than your product. If you do not put your own acceptance criteria into the sample request, the sample will be judged against theirs and it will pass.

What that looks like in practice: capacity measured at a rate and temperature that is not how you use the pack. Leakage or self-discharge judged loosely. Balance behavior checked only at rest. A hi-pot test at a voltage that proves continuity but not much about your insulation margin. Put the tests, the conditions, and the pass thresholds in the request, and ask for the results to come back with the sample rather than after it.

Three pins that make the sample comparable to production

A sample is only useful if it is a fair preview of the unit you will buy later. Three items in the request protect that:

• The cell designation, by part number, not by chemistry description. Cells get substituted when a line runs short, and a substitution changes the discharge curve, the impedance, and the thermal behavior.
• The BMS model and the firmware revision. Ask for the revision to be printed in the response. Firmware drifts, and a sample running a different revision than the production build is a different product wearing the same part number.
• The assembly line you intend the production unit to run on. If the sample comes off a bench and production is planned for a line with a different fixture set, you have learned almost nothing about manufacturability.

Where the firmware revision genuinely is not settled yet, I write it as a requirement that the supplier declare what it used rather than pretending I know. Same for the line, if the production decision is still open. Declared beats guessed.

Ask for the build steps, especially the tabs

One short section in the request changes how you read the sample when it lands: ask the supplier to list the build steps it intends to use, and specifically whether the tabs will be hand-soldered, spot-welded, or laser-welded, whether the balance leads are hand-routed, and whether the pack will be built on a fixture or on a bench.

You are not asking for a process audit at this stage. You are asking a question whose answer tells you how far the sample sits from a production process. A hand-soldered tab sample can be electrically fine and still tell you nothing about joint repeatability at volume, about heat damage to the cells during assembly, or about how the pack behaves when the same joint is made a thousand times by a different operator. Knowing beforehand keeps you from over-reading a good result.

A sample request is not a small RFQ

These are two different documents answering two different questions. The sample request answers: can this supplier build something close to what we need, and what does it look like when it does. The production RFQ answers: at what cost, at what capacity, under what terms, with what evidence. Loading the full RFQ apparatus onto a first feasibility sample usually slows the response without improving the sample, because the supplier ends up answering commercial questions it cannot answer yet while the hardware questions go unanswered.

That said, the five build-deciding lines belong in both. What you drop from the sample request is the commercial and documentary weight, not the engineering content. The judgement call is which stage you are actually in. If you are testing whether the architecture is feasible at all, a lean request with firm electrical and mechanical content is right. If you already know the design and you are qualifying a supplier for production, then the fuller document is doing real work.

What I do with the request afterward

I keep it as a live document and I print it. When the sample arrives, the inspection sheet is the request, line for line. Caliper on the enclosure against the stated tolerance. Connector against the part number. CAN capture against the signal list. Capacity run against the acceptance criteria I wrote. Anything the supplier declared as an assumption gets flagged and checked first, because that is where the mismatch will be hiding.

That is the practical payoff of treating the request as a requirements document rather than a message. The sample stops being a surprise and becomes a test result. And when something does come back wrong, you can point at the exact line, in a document both sides signed off on, and decide whether the fault was the supplier's build or your own blank cell.