Failed Delivery Resolution Agent

When a stop fails (no one home, access denied, refused shipment, or an unsafe drop), the clock starts on redelivery cost and customer frustration. A failed delivery resolution agent is an automated workflow that receives the exception from the delivery system, contacts the recipient through SMS or voice, presents clear next options (new time window or pickup location), records the choice, and writes the update into the transportation management system (TMS) or last-mile platform without waiting for a dispatcher to dial out.

The agent does not invent a new operating model. It compresses the loop between “driver marked attempt failed” and “next attempt is scheduled with a confirmed preference.” Every automated action should cite the exception ID from the delivery event and the recipient choice ID from the conversation turn that selected reschedule or pickup. If contact fails (no answer, invalid number, or explicit opt-out), the agent returns an empty resolution payload and leaves the exception open for human escalation. Dispatchers remain accountable for edge cases; the agent owns first-touch recovery for standard failures.

This pattern pairs with upstream classification and windowing. A delivery exception classifier decides which failures are safe to auto-resolve. A delivery time window optimizer supplies feasible slots once the recipient chooses reschedule. Proof of delivery disputes stay on a separate track via CV proof of delivery verification. Broader exception handling beyond failed stops is covered by the exception resolution agent.

The happy path is short and auditable. The last-mile system (commonly Onfleet or Bringg) emits a failed-attempt event with stop ID, exception reason code, recipient phone, and preferred channel. The agent opens a Twilio conversation (SMS first for most consumer deliveries; voice when SMS bounce or accessibility requires it). The message states why the attempt failed, lists two or three concrete options with deadlines, and asks for a single reply. When the recipient picks an option, the agent creates a recipient choice ID, maps it to a TMS status and appointment record, and pushes the change through the Onfleet or Bringg API (or a middleware connector into Salesforce Field Service or Service Cloud when the CRM owns the customer case).

Speed is the outcome that matters here. Manual call-backs often sit in a queue for hours; an agent can start contact within minutes of the failed attempt and lock a next action before the same driver leaves the zone. That reduces “orphan” exceptions that only surface at end of day. It also cuts duplicate driver work when recipients would have accepted a nearby locker or retail pickup if asked promptly.

Data hygiene is part of the design, not an afterthought. The agent must never update the TMS without both IDs: exception ID (why this stop is open) and recipient choice ID (what the customer agreed to). Downstream reporting, SLA clocks, and dispute handling all hang on that pair. If the recipient never confirms, the agent must not invent a preference. Empty resolution plus open exception is the correct state; silent auto-reschedule without consent creates wrong-door attempts and erodes trust.

Onfleet and Bringg typically own task state, driver assignment, and recipient-facing tracking links. They are the source of truth for the failed attempt and the destination for the new task or appointment. Twilio provides the messaging and voice rails, delivery receipts, and conversation history used to reconstruct what the recipient was offered. Salesforce often sits as the customer system of record: case creation for VIP accounts, consent flags, and escalation queues when the agent cannot resolve.

Integration boundaries should stay explicit. Twilio should not become a second TMS. Onfleet or Bringg should not become a CRM. Salesforce should not invent delivery slots the last-mile optimizer cannot serve. The agent orchestrates: read exception from last-mile, contact via Twilio, write choice back to last-mile, and open or update a Salesforce case only when policy requires human follow-up or when contact fails.

Consent and channel preference live in Salesforce or an equivalent customer profile store. The agent should respect Do Not Contact flags and quiet hours before the first message. Failed contact after retries still escalates to a dispatcher queue in Salesforce or the dispatcher console, with the exception ID attached so the human sees the full attempt history rather than starting from scratch.

Automating recipient contact is high-impact and easy to get wrong. Limit the agent to exception types the classifier marks as recoverable by self-service: not-home, soft access issues, and customer-requested hold. Hard failures (damaged goods, fraud flags, unsafe neighborhoods after dark) should skip straight to dispatcher or investigation workflows.

Offer only options the network can actually fulfill. If the delivery time window optimizer returns no capacity for tomorrow, do not show that slot. Prefer pickup locations that already exist in Onfleet or Bringg as valid destinations. Cap conversation turns so a confused recipient does not thrash the agent into contradictory updates.

Keep the dispatcher in the loop as the escalation owner, not as a rubber stamp for every message. When contact fails, when the recipient asks for something outside policy, or when two exceptions collide on the same order, the agent stops, posts an empty or partial resolution with the exception ID, and routes the case. That preserves speed for the majority path without pretending every conversation ends cleanly.

Audit trails should be readable by operations and compliance. Store Twilio message SIDs, exception ID, recipient choice ID, timestamps, and the exact option text shown. When a customer disputes “I never asked for locker pickup,” the trail must show what was offered and what they replied. Empty contact outcomes need the same rigor: log attempt count, bounce codes, and why escalation fired.

Treat resolution latency as the primary metric: minutes from failed-attempt event to confirmed next action in the TMS. Secondary metrics include contact success rate, share of exceptions closed without dispatcher touch, reattempt success on the chosen option, and escalation volume by failure reason. Watch for regressions: rising empty resolutions may mean bad phone data; rising dispatcher overrides may mean the option set is wrong.

Compare agent-handled lanes against a control set before full rollout. If average time-to-reschedule drops but same-day pickup acceptance does not convert into successful retrievals, fix location messaging or pickup SLA before expanding. Pair this agent with delivery exception classification so you only auto-contact where policy allows, and escalate the rest through the wider exception resolution pattern.

A failed delivery resolution agent earns its place when it turns a failed stop into a confirmed next step fast, leaves a clean ID trail, and gets out of the way when contact fails. That is how last-mile teams reclaim dispatcher time without giving up control of the hard cases.