Concrete delivery / batch record Workflow

Why should we automate concrete delivery records instead of using paper dockets or spreadsheets?

Manual docket handling often means details are recorded inconsistently or lost between site and office. This workflow captures every field — docket number, mix, slump, batching times, water added — directly into a record with a reference number and status, so the information is available immediately rather than transcribed later. It also removes the need to chase down who has the paper docket when a rejection needs following up.

What is the ROI of using this workflow compared to handling rejections manually?

When a load is rejected, the workflow automatically assigns a task to the concreting supervisor and notifies the receiver, so resolution starts without someone having to notice and escalate manually. The supplier response, replacement load and credit agreed are recorded directly on the delivery record, reducing time spent piecing together what happened after the fact. This can shorten the time between a rejected pour and a documented resolution reaching the client.

Who is responsible for handling a rejected load in this workflow?

When the Decision field on the intake form is set to Rejected, the record status changes to Rejected and the receiver is emailed to confirm the load was logged. A task is then assigned to the concreting supervisor to record the rejection reason, supplier response, replacement load arranged and credit agreed, and the workflow waits until this task is completed before moving forward.

What happens once the supervisor records the rejection resolution?

The details entered on the supervisor's task — reason for rejection, supplier's response, replacement load arranged and credit agreed — are saved to the delivery record. The status is then updated to Supplier Resolved, and the builder or client is emailed with the rejected load details and how it was resolved.

Can we customise what happens at the Accepted/Rejected decision point?

Yes, the routing step and the steps that follow can be adjusted by describing the change in plain English or editing the steps directly in the workflow editor. This means the acceptance and rejection paths, the tasks assigned, or the notifications sent can be changed to match a specific site or supplier arrangement, with earlier versions kept.

How is the delivery record structured and tracked over time?

Each submitted docket creates a record with its own reference number, a status such as Recorded, Accepted, Rejected or Supplier Resolved, and a timeline of what happened. Table views and dashboards show these records grouped by status, so accepted, rejected and resolved deliveries can be reviewed at a glance.

Does the receiver or builder/client need an account to take part in this process?

No. The receiver submits delivery details through a public request form, and both the receiver and builder/client receive updates by email as the delivery is recorded and, where relevant, resolved. Neither party needs to log into anything to take part.

What information gets saved permanently to the delivery record versus staying with a task?

Answers submitted on the initial request form, and any task the workflow waits for — such as the supervisor's rejection resolution — are saved directly to the delivery record. Each business should confirm its own record-keeping requirements against what this workflow captures for its use case.

How does this workflow help if we work with multiple concrete suppliers?

The Supplier field is captured on every delivery record, so rejected loads and their resolutions are tied to a specific supplier within the record timeline. This makes it easier to review supplier response patterns across records shown in table views and dashboards, though each business should apply its own criteria when assessing supplier performance.