Why concrete gets rejected at site, and where it starts

A rejected load costs twice. There is the concrete itself, which cannot be sold and often cannot be kept. And there is the conversation with a site engineer who now watches every subsequent delivery more closely.

What makes rejections frustrating is that the decision happens at site, but the cause almost always sits back at the plant, hours earlier.

Four causes, in the order they occur

The mix that was not the mix

Approved designs exist for a reason, and they get deviated from for practical ones — a material is short, an operator adjusts to make a batch work, nobody records it. The load leaves as M25 on paper and something slightly different in the drum.

Small deviations often pass. They stop passing when two of them coincide, and by then nobody can reconstruct which batch was adjusted or why, because the adjustment was never written down.

Moisture that nobody corrected for

Aggregate carries water, and how much changes with weather and with where in the stockpile the loader dug. If the batching does not correct for actual moisture, the water-cement ratio moves — and water-cement ratio is what strength depends on.

This is the most common technical cause of a cube test failure that surprises everyone, because the batch record looks correct. It was correct, for aggregate that was drier than the aggregate actually used.

Time in the drum

Concrete has a working window, and traffic does not respect it. A load that sits waiting at a congested site loses workability, and the response at site is often to add water — which fixes placement and damages strength.

Most of this is a scheduling problem rather than a technical one. Dispatching against a pour that is not ready guarantees waiting time.

Records that cannot answer the question

When a cube fails at 28 days, the question is what went into that specific load. If the answer requires reconstructing from memory and paper, the discussion becomes about blame rather than cause — and the plant usually loses that discussion regardless of what actually happened.

What the plant can actually control

Not traffic, and not the site's readiness. But these:

• Designs stored and enforced. Approved mixes per grade, with deviations requiring a reason that gets recorded rather than a verbal adjustment.
• Actual batch data captured. What the plant really dosed — cement, aggregates, water, admixture — not what the design said it should.
• Moisture correction as routine. Applied per batch rather than assumed from a figure taken last week.
• Dispatch tied to pour readiness. Scheduling transit mixers against confirmed site readiness rather than a morning plan.
• Trip cycle times measured. Once you can see loading, travel, waiting and return per trip, chronic waiting at a particular site becomes a fact you can raise rather than a complaint.

The reconciliation nobody enjoys

Theoretical consumption against actual consumption, by material, by period.

It is unpopular because it exposes things. Cement consumed against cubic metres produced should sit within a predictable band. When it drifts, either the mixes are being adjusted, the batching is inaccurate, or material is leaving unrecorded — and all three are worth knowing about early.

Plants that run this monthly tend to catch a calibration problem as a trend. Plants that do not tend to catch it as a failed structure.

What to fix first

1. Capture actual batch data, because everything else depends on having it.
2. Enforce mix designs with recorded deviations, so a variance has an explanation attached.
3. Make moisture correction routine rather than occasional.
4. Schedule dispatch against pour readiness to cut waiting time.
5. Reconcile materials monthly, once the data above is trustworthy.

The first two are what turn a rejection from an argument into a diagnosis.

If you want to see how this is captured against a batching plant, see how our RMC system handles it or book a demo.