Your Capacity Fade Guarantee May Not Cover the Robot Fleet You Actually Run

Date Author Lot Trace

A capacity fade guarantee only covers the fleet you actually run when the warranty term is written as a measured number: a named test method, a stated ambient temperature, a stated charge and discharge rate, a stated end-of-life threshold such as 80% of beginning-of-life capacity, and a duty cycle that matches what your robots do on the floor. A defective-materials clause covers a pack that stops working. It says nothing about a pack that works a little less every month, and that is the failure a fleet actually experiences. Turning fade into a term means attaching a protocol, a population definition, and a field-data path to it before the RFQ closes, not after the first pack comes back short.

Come stand at the bench with me. The pack on the pallet came off an AMR that the maintenance lead describes as "running short" — no fault code, no charger complaint, no swelling, nothing a technician can point at. That combination is the signature of fade, and it is the reason the pack is sitting in front of us instead of staying on the floor. I bolt the terminals to a load bank, set the discharge to the protocol we wrote into the purchase order, and watch the fan spin up while the laptop logs. The curve flattens earlier than it should. Say it lands somewhere in the low seventies as a percentage of the beginning-of-life capacity we captured at incoming inspection — that number is not a malfunction, it is wear, and it is exactly the thing the supplier's warranty exhibit does not address.

I keep that exhibit taped inside a binder. Three sentences: defects in materials and workmanship, a period, an exclusion for misuse. Nothing about capacity, nothing about temperature, nothing about how the pack is cycled. The supplier did not write a bad clause. They wrote a normal one, and normal is the problem. When I take that clause to a supplier and say the pack faded, I am not making a warranty claim. I am starting a negotiation about what the word "defect" means, and I am holding a graph nobody agreed to.

The number means nothing without the test that produced it

The first time I accepted a cycle-life figure, I accepted it off a cell datasheet. One line, a cycle count, a rate, a temperature. What I did not ask was whether that number was a cell in a fixture at a controlled ambient, or a pack in a housing with a BMS deciding when to stop charging. Those are different experiments, and only one of them describes what I am buying.

So now I ask for the report, not the number. What charger, what load, what ambient temperature, what state-of-charge window, how deep the discharge, how many packs in the sample, and how beginning-of-life capacity was measured in the first place. If the pack-level test conditions do not exist, that is information too — it means the fade figure on the quote was inherited from a cell datasheet and nobody has actually run the assembly.

The other half of this is that whatever protocol I accept for the lab has to be the protocol I use in the field. I have watched a claim die because the supplier tested at one temperature and rate and we checked at another, and both sides spent the meeting converting units instead of resolving anything. Pick the protocol once — ambient, current, cutoff, rest, the whole sequence — and use those exact words in the warranty exhibit and in the verification procedure your service team will follow.

Match the test to the site, not to the lab

Before I write the protocol, I pull the fleet data. Amp-hours through the pack per shift. Where the robots sit when they charge, and what that aisle reads on a gauge in August. Whether they opportunity-charge between tasks at partial state of charge and dwell there, or run a full cycle and rest. A gentle lab cycle at a comfortable ambient is a fine thing to publish and a poor description of a machine that charges in a hot corner of a warehouse in short bursts all day.

I do not need the supplier to redesign anything for this. I need them to either run the cycle life at conditions resembling mine or state the derating out loud in the exhibit. A derating line is honest and useful. Silence is what gets me into a conference room two years later with a graph and no leverage.

Write the population, not just the pack

This is the part that gets skipped, and it is the part that decides whether a fade guarantee is worth the paper. The warranty covers "the pack." My fleet is not a pack. It is dozens of them, with different duty, different sites, different operators, and a few units that live easier lives than the rest.

So the exhibit has to say which one is being measured. A floor — no individual pack falls below the end-of-life threshold within the term — is a very different promise from a fleet average, where one bad unit is absorbed by the healthy ones and nobody ships you anything. Neither is wrong. They are different commercial bets, and I want to know which one I bought.

Then the mechanics: how many packs get tested, who selects them, whether the supplier or we run the capacity check, and what triggers a remedy. If the term only fires when every pack fails, it never fires. If it fires on a single pack, the supplier will argue about test conditions on that one unit. Somewhere in between is a sample size and a threshold that both sides can live with, and it is worth arguing about that now rather than during a claim.

Split the causes so claims do not stall

One bucket for every failure is how claims go quiet. I write four, each with its own evidence standard and its own remedy.

Manufacturing defects — assembly, welds, a connector that was never seated — usually show up early and are the easy one. Cell lot issues are the dangerous one, because a bad lot fades fast and evenly across every pack built in the same window, and the symptom looks exactly like normal wear until you plot it by build date. BMS failures present differently again: state-of-charge drift, weak balancing, cutoffs that arrive early, a pack that reports a healthy number and delivers a smaller one. And then normal wear under the duty cycle, which is not a defect and should not be argued as one.

Each of those needs a stated remedy. A BMS that misreports is a replacement conversation. A cell lot that fades uniformly is a lot-level conversation, and only useful if the agreement obligates the supplier to tell you which serial ranges share a lot. Wear is a pro-rata credit. If all four live in a single sentence, every claim becomes an argument about categorization, and the clock runs while the robot sits.

The pro-rata line needs a meter

Pro-rata is fine. Pro-rata without a stated basis is a placeholder. The agreement should say whether the credit is measured in months in service or in accumulated amp-hours, and then it should name the counter that reads it and who is allowed to read it. Months in service is simpler to administer and blunt. Amp-hours tracks the robot's real work and rewards the site that runs two shifts, but only if the telemetry is trustworthy and both parties can audit the same log. Pick one, write it down, and stop pretending the choice is neutral — it moves real money depending on how hard your fleet works.

Decide who pays before there is a disagreement

Nothing in a fade clause matters more in the moment than freight. A disputed pack has to travel. Somebody pays to palletize it, somebody pays to ship it as a regulated article, somebody pays the lab that runs the capacity check, and somebody pays the technician who pulls and refits it. In a healthy relationship that is a short conversation. In a contested claim it is the conversation, and if the agreement is silent, the claim stalls on a shipping label.

I write the default: we pay return freight up to the point the test confirms fade beyond the threshold, and the supplier reimburses if it does. Same for the independent capacity test. Same for labor. It is not about winning — it is about making the disputed path cheap enough that people actually walk it.

Alongside that sits the service side of the term, which is separate from capacity and often missing. Response time when a pack drops out of service. How fast a replacement pack ships, and whether it ships from stock or waits in a build queue. Whether the remedy is a credit, a repair, or a swap, and who decides. A fade guarantee with no replacement path just tells you when your robot stops. I want the downtime answer written in the same exhibit as the capacity number.

The baseline moves when the bill of materials moves

Here is the one I have had to argue hardest, because it is invisible until it bites. The pack on the pallet today may not be the pack you qualified. Cells get second-sourced. A cell part number changes quietly. BMS firmware gets updated to fix an unrelated issue, and the charge profile shifts slightly with it.

If the warranty baseline does not move with the bill of materials, you are measuring against a spec nobody is building anymore. So the agreement should list the triggers — cell manufacturer, cell part number, pack assembly location, BMS hardware revision, BMS firmware revision — and state that any change to a trigger requires notice, a revalidation run, and a recalculated beginning-of-life baseline. Not a new negotiation, a new baseline. That single sentence has saved me more arguing than any threshold I have ever written.

I will be honest about the limits of all this. A well-written fade term does not make an unreliable supplier reliable, and some suppliers will simply decline to offer a fade guarantee at all. That refusal is worth hearing early. It tells you the price you are being quoted is carrying an unmeasured risk, and you can decide to buy it with your eyes open or move on. What the clause buys me is not protection from physics. It buys me a short, factual conversation instead of a long, emotional one.

Back at the bench, the discharge finishes and the load bank winds down. I have a number, a protocol, and a beginning-of-life figure from the same test. That is either a claim or it is wear, and I know which within about ten minutes. The difference between those two outcomes was decided months earlier, in a document, by whether anybody wrote down how we would measure.

Lot Trace

About the author

Lot Trace

Lot Trace is a byline shared by sourcing, quality, and compliance professionals who have spent their working lives on the buyer's side of custom battery pack programs. They have walked pack assembly lines in the Midwest and in Guangdong, reviewed cell lot records and UN 38.3 test summaries, and sat through PPAP reviews for robot programs built on both sides of the Pacific.

More about us