Driver Attendance Agent
At a glance
- Live at: Aramex (primary)
- Channels: voice (outbound calls), WhatsApp
- Languages: EN, AR, HI
- Owner: Fleet ops pod
- Key use case: Automated driver attendance check, roster management, and reallocation
The problem it solves
Every morning, fleet operations needs to know which drivers are available, which are on leave, and which haven’t checked in. At a large LSP like Aramex with thousands of drivers across multiple hubs, manual attendance is a phone-call marathon. Dispatch coordinators spend the first 1-2 hours of each day calling drivers, confirming availability, and reshuffling routes for no-shows.
This delay pushes back first departures, which ripples into late deliveries for the entire day.
How it works
Step by step
- Roster load — At a configured time each morning, the agent loads the day’s roster from the dispatch/fleet management system.
- Check-in verification — Identifies drivers who haven’t checked in via the app or biometric.
- Outbound calls — Places automated voice calls to missing drivers. The call script confirms: “Are you available for your shift today?”
- Capture response — Records the driver’s answer: available, on leave (with reason), or requesting a swap.
- Retry logic — If no answer, retries at configurable intervals (e.g., every 15 minutes, up to 3 attempts).
- Mark attendance — Updates the dispatch system with confirmed availability or absence.
- Trigger reallocation — For absent drivers, notifies dispatch to reassign their routes to available drivers.
- Escalate — After exhausting retries, escalates to the hub manager for manual follow-up.
WhatsApp fallback
If voice calls fail (driver in a noisy area, phone on silent), the agent falls back to WhatsApp:
- Sends a structured message: “Hi [name], are you available for your [time] shift at [hub]? Reply YES or NO.”
- Processes the response and updates attendance accordingly.
Integration with dispatch
The attendance agent feeds directly into the dispatch/route optimization system:
- Available drivers → route assignment proceeds normally
- Absent drivers → routes are flagged for reallocation, optimizer re-runs with reduced capacity
- Late check-ins → routes may be partially reassigned, with the late driver picking up remaining stops
Tech stack
| Layer | What’s used |
|---|---|
| Models | Gemini 2.5 Flash (voice — fast, natural conversation in multiple languages) |
| Memory | Short-term: call context. Long-term: driver attendance patterns, usual availability. |
| Tools (MCP) | Fleet management system (roster), dispatch API, WhatsApp, voice call, follow-up scheduling. |
| Guardrails | Cannot modify routes directly (triggers reallocation request). Cannot access driver personal data beyond what’s needed for the call. |
| Evals | Scenarios: driver available, driver absent, no answer (retry), language switch mid-call, WhatsApp fallback. |
Why CS folks should study this
- Fleet ops entry point. For any LSP with a large driver fleet, attendance automation is an easy-to-understand, high-frequency use case.
- Aramex validates the pattern. Live deployment at one of the largest LSPs in the Middle East proves it works at scale.
- Connects to the marketplace model. At Aramex, this is one of several agents in their agent marketplace — see the Aramex case study.
Sources
- Aramex × AI Agents
- Aramex Architecture
- See Aramex case study for the full engagement context
Changelog
- 26 May 2026: Full content from Aramex deployment details and Drive decks.