Ready Mix Concrete Dispatch Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does dispatch get scoped as scheduling?

Because the artefact everyone points at is the morning board. Someone says we need a better version of this, and the requirement becomes a calendar with orders on it. That is a scheduling tool, and the schedule at 05:50 is a guess. The business is what happens to it between 06:00 and 16:00.

What makes this specific to ready mix is that your capacity is not trucks and it is not plant yardage. It is cycle time: load, haul, wait, discharge, wash, return. A job twelve minutes away with fast placement gives you four or five loads per truck per shift. The same truck on a job with poor site access and a slow pump gives you two. Your dispatchers know this in their bones and hold it in their heads, which is exactly why it never makes it into a requirements document. Nobody writes down the thing they consider obvious.

The scoping test is simple and it filters ruthlessly. Ask the developer to explain the truck cycle on a whiteboard and to say where each timestamp comes from. If they describe orders and tickets rather than states and transitions fed by geofences at plant and job site plus driver confirmations, you are buying a calendar. Ask specifically what the dispatch board shows at 09:15 on a continuous pour, and whether it shows demand rate against supply rate with the gap forecast forward. If the answer is a list of today's deliveries, the build will not change a single decision your dispatchers make.

What goes wrong when you pull mix designs and ticket history off the batch computers?

Mix designs are the trap, because they look like recipes and behave like rules. What sits in a batch computer is quantities, moisture compensation behaviour, admixture dosing logic, and for structural and public agency work an approved status tied to a specific job and specification. Export the quantities alone and you have a list of ingredients with no idea which mixes are approved for which jobs, which is the fact dispatch needs when deciding which plant can serve an order.

The second problem is duplication across plants. A producer that grew by acquisition has the same mix under three codes at three plants, sometimes with small differences that are real and sometimes with differences that are transcription errors from a decade ago. Import them unreconciled and multi plant balancing becomes impossible, because the system cannot tell that plant two can produce what plant one is queued up for.

The fix is a reconciliation pass owned by your quality manager, not the developer, before any import: agree one identifier per genuine mix, record the plant specific variations as variations, and mark approvals with the job and specification they attach to. For ticket history, import roughly the last one to two years for reporting continuity and leave the rest where it sits. Older tickets rarely carry the timestamps you need for cycle analysis anyway, so importing them dilutes your baselines rather than improving them.

Why do the batch computer, telematics and billing integrations break after launch?

Plant level integration is where these projects overrun, and the reason is heterogeneity. A vendor demonstration always shows their own batch system. Yours are mixed, often three or four brands across two generations of each, sometimes Command Alkon COMMANDbatch at one plant, Marcotte at another and an older system nobody wants to touch at a third. Some allow orders to be pushed down, some only report back. Some expose a database, some a file drop, some a serial feed a technician configured years ago.

The failure after launch is usually latency rather than outage. A ticket that appears in dispatch four minutes after batching is useless for pour rate control, and nobody notices during testing because testing happens at low volume. Ask what the expected delay is per plant type at peak, not in a demonstration.

Telematics breaks on geofence quality. A geofence drawn too large around a congested job site logs arrival while the truck is still in traffic, and your wait time charges become indefensible in a dispute. Draw them with the drivers, and review the ones that generate the most disputes.

Billing breaks on legacy. Integration with a modern accounting package is straightforward and integration with an older construction or materials system with no interface is painful, and quotes routinely assume the first. Name your system before asking for a number.

What happens when the discharge clock and quality records are not covered?

Two gaps, and the second one is where a technical conversation becomes a legal one.

The discharge clock first. ASTM C94 sets a limit of 90 minutes or 300 drum revolutions from batching to discharge unless the specifier agrees otherwise. That is not a reporting field, it is the constraint that governs your day. A system that records the breach afterwards has told you about a problem you already have. It belongs on the live board, warning dispatch before a load becomes at risk, and it belongs in the plant assignment logic so a plant that cannot serve a job inside the window is not offered.

Quality records second. Water added at the site by a driver at a contractor's request changes the water to cement ratio and therefore the concrete, and that fact needs to be on the ticket with an acknowledgement, because it is the first thing anyone examines when cylinder breaks come back low. If dispatch and quality live in separate systems, linking a 28 day result back to the exact load, its as batched quantities, the moisture compensation applied, the admixtures dosed, the site added water and the truck it rode in takes a person and an afternoon. When that link exists, a low break is a conversation about one cubic yard with the full story on one screen. When it does not, it is a conversation about your process with a lawyer present.

Should you build custom or configure what you already own?

Two plants and twenty trucks: buy, and we would say so before quoting. Sysdyne ConcreteGO is a sensible cloud dispatch product for small and mid size producers with reasonably modern batching, it costs a fraction of a build, and your money is better spent on trucks and drivers. Command Alkon has real depth if you are already inside their ecosystem and your problem is depth rather than fit. Digital Fleet handles telematics well and is the right purchase if what you actually lack is visibility of where the trucks are rather than a dispatch brain.

Be honest about which of those three problems you have, because producers routinely buy a dispatch platform when the real gap was telematics, or buy telematics when the real gap was that nobody can see cycle time.

The build case is heterogeneity, not size alone. Above roughly five plants or sixty trucks with mixed batch computer brands, any product you evaluate fits some plants and not others, and you end up maintaining phone based workarounds at half your sites. Add the other signals: dispatchers managing large continuous pours by instinct, no ability to report returned yards, wait time and short load recovery by customer, several business lines sharing trucks and drivers with no system seeing them together. Under about sixty trucks with uniform plants, buy.

How do hidden costs get into the quote?

Five ways, and four are avoidable by counting things before you ask for a number.

Batch computer brands and generations. Each adapter is separate work and older installations are slower than modern ones. Count them, list them by brand and generation, and put the list in the brief.

Two way order push versus ticket capture only. Push brings the plant control system properly into scope and is a materially different project from reading tickets back.

Driver app depth. Offline behaviour, signature capture and photo evidence at the site each add cost, and offline is not optional at rural jobs.

Other business lines. Block, aggregate haul and pumping each have their own dispatch logic and are effectively additional modules, not extra order types.

And billing, which is cheap against a modern accounting package and expensive against a legacy system with no interface. For anchoring, our bands: a first release covering order taking, the day board, live truck state and cycle tracking, batch computer ticket capture for your main plant types and pour rate management runs $70,000 to $150,000 over twelve to eighteen weeks. The full platform adding the driver app, quality records, returned concrete costing, multi plant balancing and telematics runs $200,000 to $450,000 phased over six to twelve months.

What separates a build that works from one that fails here?

Dispatchers who trust the board. That is the whole test, and it is won or lost on timestamp quality in the first fortnight. If geofences are sloppy and cycle times read wrong, dispatchers revert to the phone and never fully come back. Draw the geofences with drivers, verify them against a few known jobs, and fix the bad ones immediately rather than at the next release.

Sequencing that starts at your busiest three plants with dispatch and ticket capture, and adds the driver app only once the board is trusted. Drivers adopt an app that dispatch already relies on. They ignore an app that feeds a system nobody uses.

A driver app that stays small. Load assignment, navigation, arrival and discharge timestamps, electronic ticket with signature, added water recording, photo evidence and a way to flag a site problem. Nothing else. Drivers use it wearing gloves in bad weather, and every extra screen reduces the quality of the data everything downstream depends on.

Measurement that makes the return visible. Returned yards, wait time and short load charges by customer, job, salesperson and dispatcher, with cost applied. These are continuous losses that are currently invisible and often waived under pressure, and computing wait time automatically from arrival and discharge timestamps makes the charge defensible rather than a matter of the driver's handwriting. In our delivery experience the reporting alone changes ordering behaviour on the largest accounts within a couple of months, which is usually the fastest financial return in the project.