Proactive ETA Notification Generator

A proactive ETA notification generator turns shipment tracking events into short, plain-language updates customers can act on. When a tracking platform records a gate-in, departure, dwell, scan, or predicted delay, an LLM drafts a message that states the new expected arrival in everyday language, then hands that draft to email or SMS for delivery.

The goal is speed of communication, not a new source of truth for transit time. Visibility systems such as project44 and FourKites already own event streams and ETA calculations. The generator’s job is to translate those signals into customer-ready copy within seconds of the event, so operations does not wait on a template rewrite or a manual status call.

Each outbound message must cite the triggering event ID and the ETA source (carrier EDI, GPS ping, predictive model, or TMS estimate). If no ETA is available for that event, the system produces an empty message payload and does not dispatch. Preference ownership stays with the customer: quiet hours, channel choice, and opt-out rules are evaluated before anything leaves the stack.

The pipeline starts with a normalized tracking event. Visibility feeds from project44 or FourKites (or a carrier API mirrored into the TMS) emit structured records: shipment ID, location or milestone code, timestamp, and any attached ETA fields. A rules layer decides whether the event is notification-worthy. Routine heartbeats that do not change ETA usually stay silent. Material changes, such as a revised appointment window, a missed connection, or a predictive delay flag, enter the draft queue.

The LLM receives a constrained prompt: shipment context, prior customer-facing language if any, the new ETA (or an explicit “unavailable” flag), the event ID, and the ETA source label. It returns a short message body suitable for SMS length or email subject-plus-body, without inventing stops, causes, or recovery promises that are not in the payload.

Before send, a validation step checks three conditions. First, the draft must include the event ID and ETA source as structured metadata (and, where channel length allows, as readable citations in the body). Second, if the ETA field is null or marked unavailable, the draft is discarded and the dispatch step is skipped. Third, customer preference records (opt-in channel, language, quiet hours) must allow the send. Only then does the system call Twilio for SMS or Salesforce for email (or journey orchestration) with the approved payload.

This separation matters. The model writes; the visibility stack computes; the CRM and messaging platforms deliver under policy. Collapsing those roles into one free-form generation step is what produces hallucinated ETAs and compliance gaps.

During the move stage, the costly lag is rarely the raw event itself. Carriers and visibility platforms already know the shipment moved. The lag is the time between “system knows” and “customer understands what to do next.” Call centers absorb that gap as inbound “where is my order” volume. Dock teams absorb it as missed appointments. Downstream partners absorb it as idle labor waiting on an uncertain window.

Proactive, plain-language ETA updates shrink that gap. A message that says the load cleared the cross-dock at 14:22 local time, the revised ETA is Thursday 09:00–11:00 based on the predictive transit model (source X), and references event ID evt_…, lets the receiver adjust labor and appointments without opening a portal or waiting for a CSR callback.

Speed here is measured in minutes from event to delivered notice, not in model accuracy of the ETA itself. Accuracy still depends on upstream prediction and visibility quality. For delay foresight and transit estimates that feed this generator, see Predictive Delay Detection and ML Transit Time Prediction. The notification layer should not recompute those values; it should surface them clearly when they change.

Auditability is part of the product, not an afterthought. Every dispatched message should carry:

• Event ID: the exact tracking event that authorized the send, so support can replay the chain when a customer disputes timing.
• ETA source: which system or method produced the arrival estimate (for example, project44 predictive ETA, FourKites milestone ETA, carrier appointment confirmation, or internal ML transit model). Customers and auditors need to know whether they are reading a committed appointment or a model forecast.

When the ETA is missing, the correct behavior is emptiness, not improvisation. An LLM asked to “say something helpful” will invent soft windows or recycle stale ETAs. The contract should be: no ETA field in, empty message out, no Twilio or Salesforce send. Operations can still raise an internal exception for investigation through an Exception Resolution Agent, but the customer channel stays quiet until a real ETA exists.

Empty-on-unavailable also protects brand trust. One fabricated “arriving tomorrow” message undoes weeks of proactive goodwill. Prefer silence plus an internal ticket over a confident wrong time.

Dispatch is a policy-gated handoff, not an automatic blast.

Visibility (project44, FourKites) supplies events and ETA candidates. Integrate on event webhooks or polling, normalize codes, and pass only the fields the prompt needs. Do not let the LLM call visibility APIs ad hoc during generation; keep inputs deterministic for replay.

Messaging (Twilio) delivers SMS when the customer opted into text and quiet-hours checks pass. Keep templates short, store delivery receipts against the same event ID, and treat undelivered SMS as an ops signal rather than a silent failure.

CRM / journeys (Salesforce) owns email content records, contact preferences, and often the master opt-in state. Use Salesforce to resolve who may be contacted, which language to use, and whether email is preferred over SMS. Log the outbound activity against the shipment and event ID so CSRs see the same narrative the customer received.

Customer preference ownership means marketing and logistics do not override a documented opt-out “because this update is important.” Transactional shipment notices may have a different legal basis than promotions in some jurisdictions, but the product rule for this use case stays conservative: if the preference store says no, do not send. Preference changes (channel switch, quiet hours, stop texts) should take effect before the next event, not after a batch has already queued.

When a delivery attempt fails after ETA notices went out, hand off to specialized recovery flows such as a Failed Delivery Resolution Agent rather than stretching the ETA generator into rescheduling dialogue.

Keep the generator inside clear limits so speed does not become noise.

Send on material ETA changes and customer-relevant milestones, not on every GPS ping. Cap frequency per shipment per day. Deduplicate bursts when multiple systems emit the same underlying event. Require human review for high-severity exceptions until precision is proven. Measure time-to-notify, opt-out rate, inbound contact deflection, and citation completeness (share of messages with both event ID and ETA source present).

A practical pilot starts with one lane or one customer segment, one visibility source, and one channel. Confirm empty-when-unavailable with synthetic events that lack ETA fields. Confirm preference blocking with known opt-outs. Only then widen event types and add the second channel.

Done well, the proactive ETA notification generator is a thin, auditable layer between visibility truth and customer attention: fast plain-language updates when an ETA exists, silence when it does not, and preferences that remain under customer control.