How One Paving Company Uses SMS for Dispatch and Daily Reports

A paving company needs a clear dispatch decision before crews leave and reliable production records after the shift. This case study describes three SMS-led workflows designed for those needs: a morning paving summary, an end-of-day field form and a plant-performance report. It is a project example, not a measured claim about every paving business.

The project combines dispatch information, daily field records and plant reporting. The design choices below show how the handoffs work and which responsibilities remain with the company.

Tool one: a paving call, not a weather report

Every morning, before dispatch, each field manager gets a text message for their specific job site: the conditions that matter for laying asphalt — temperature, precipitation, wind — and a plain, emoji-coded rating on whether it's a paving day.

The weather component compares a government feed with commercial forecasts and applies configured rules to the relevant conditions. The design uses a median for temperature and a conservative precipitation reading. The company must set and review the job-specific thresholds; the summary supports the manager’s decision rather than certifying that conditions are safe.

A text message puts the summary into a channel field managers already use. Keep the format consistent, identify the job and observation time, and provide a way to inspect the underlying forecast or escalate uncertainty. The manager remains responsible for the paving decision.

Tool two: a short field form and an office dashboard

At the end of each shift, the foreman gets a link by text. It opens a short form — tonnage placed, crew hours, equipment used, any issues — and most of it is already filled in. Crew and equipment carry over from the job's roster and yesterday's answers; the foreman confirms, corrects, and submits from the driver's seat.

Submissions feed a dashboard of production by job and trends over time. The office can compare recorded quantities and hours, then investigate discrepancies instead of treating an incomplete submission as a reliable total.

The field-form design uses signed links that expire and restrict repeat submissions rather than separate foreman accounts. A submitted form becomes read-only, and missed submissions can trigger reminders and escalation. This reduces login friction but still requires careful handling of forwarded links, access expiry and corrections.

This addresses a familiar handoff problem: field notes scattered across paper, messages and spreadsheets. A shorter form can make timely submission easier, but data quality still needs required fields, clear definitions, review and a correction path.

Tool three: the plant report the CEO doesn't have to ask for

The plant-performance report summarizes recorded production and rate against the selected target for leadership. Its reliability depends on the plant data arriving correctly and on clear handling of missing or delayed inputs.

The useful engineering choice is to prove the plant integration before building the reporting layer around it. A bounded integration test should confirm the accessible fields, update frequency and failure behavior, then shape the implementation around what the source actually provides.

A surprising amount of what gets called "AI implementation expertise" is exactly this: the discipline to not build the exciting thing until the boring dependency is verified.

So where's the AI?

Here's the part that surprises people. In version one of this platform, the AI is small: Claude drafts the executive summaries on reports and powers a handful of admin tools. AI usage is confined to the tasks where language interpretation is useful; this article does not establish a current operating-cost figure. Nothing about reconciling weather feeds or moving field data requires a large language model, so no large language model was invited.

A possible later extension would extract structured records from crew messages, then ask someone to validate the interpretation. That remains a separate capability from the SMS forms described here. It should earn its place through a pilot using representative messages and explicit checks for quantities, dates and job identifiers.

That's the expertise, honestly stated: not knowing how to add AI, but knowing the order in which to add it — and having the restraint to sequence it.

The principles underneath

• Meet the field where it is. Every field-facing surface is a text message or a link inside one. No separate field app or field-user password is required for this design. Crews still need a clear introduction to the form and escalation process.
• Reliability needs an observable delivery path. The design includes scheduled-job heartbeats and a watchdog for missing runs. Check source freshness and delivery as well as whether the scheduler started; a heartbeat alone does not prove a manager received a usable report.
• The client owns their data. Ownership, export access and retention should be explicit in the client agreement. An AI vendor holding your operational data hostage is not a partnership.
• Prove integrations before building on them. Validate the data path and failure behavior in a bounded test, then use the result to estimate the remaining implementation work.

If you want to explore a similar workflow for your operation, book a 30-minute call at /book with Rhize to discuss the field handoff, existing systems and a useful next step.