Immediate response · missing information requested
On this page
AT A GLANCE
An anonymized case study that turns continuous job-ad leads into a structured pool of potential drivers and connects that pool with operational matching for changing delivery demand.
My contribution
Process discovery · workflow design · conversational intake · data modeling · human-in-the-loop operations.
Key facts
Key engineering decisions
Build a pool, not a payroll roster
Continuously capture structured potential-driver data—vehicle, documentation, coverage area, and availability—without assuming hire, payment, or confirmed availability until a specific operational need exists.
Respond while interest is active
Use a guided conversation as the first response when someone clicks a job ad instead of depending on later manual follow-up.
Connect recruiting to demand
Use the candidate pool as the source for matching incoming capacity requirements rather than treating recruitment as a separate process.
Confirm, do not assume availability
Treat stored candidate data as eligibility information and use outreach to establish current availability.
Keep the final assignment human
Automate preparation and coordination while keeping assignment authority with operations.
Project evolution
- Job-ad lead capture
- Immediate conversational response
- Structured candidate database
- Matching workflow
- Availability confirmation
- Operations handoff
Start by understanding the operation
The project began with a discovery session with the client to understand how the operation worked day to day: how delivery requests arrived, how new drivers were recruited, what information was collected, how availability was checked, and where manual work created the most friction.
From that process map, I identified the information needed at each decision point and distinguished the steps that required human judgment from those that could be structured or automated. Technology came after the complete operating process was understood.
Capacity changed faster than the driver pool
A last-mile delivery operator received requests for delivery capacity tied to particular dates and areas. Meeting those requests depended on having enough suitable drivers ready, but recruiting, validating, and coordinating people was largely manual.
To maintain a broad pool of potential drivers, the operator continuously ran job ads on Meta and Google. Those leads were handled manually, even though responding quickly after someone clicked an ad was important to retain their interest.
The operational question was not simply how to recruit more people. It was how to continuously build a usable pool: who had a vehicle, whose documentation and insurance were available, which area they covered, and who could work when demand appeared.
That created two connected workflows. One continuously gathered and organized candidate information. The other began when an incoming delivery request needed an available group of suitable drivers.
My contribution
From the process map, I identified the information needed at each decision point and designed a workflow connecting recruitment, candidate data, matching, and capacity coordination.
The project began with conversational intake to process leads from job postings, collect driver and vehicle information, and create a structured candidate database. From there, the system connected a delivery request with explicit constraints, eligible candidates, availability confirmation, and a prepared shortlist for operations to make the final assignment.
From recruiting to assignment
Continuous driver onboarding
Leads from job postings entered a conversational qualification flow. The system collected vehicle type, driver's licence, insurance, service area, availability, and other required information while creating or updating the candidate record in the database. If information or documentation was missing, the conversation requested it before completing the profile. Leads that previously required manual processing therefore became structured records the rest of the system could use.
Continuous candidate pool
The intake records turn scattered conversations into an organized pool of potential drivers that can be used when an operational need appears.
Incoming capacity need
Operations receives a requirement defined by date, area, required capacity, and applicable vehicle or documentation constraints.
Candidate matching
The workflow filters the pool against those constraints to identify people who meet the conditions.
Availability confirmation
Suitable candidates are contacted and their responses are tracked, turning eligibility into a current confirmation.
Operations decision
The workflow returns confirmed candidates; operations retains the final decision and assignment control.
The end-to-end operational workflow
Simplified architecture
A simplified view of the system that makes the transfer point between automation and operations explicit.
Delivery request
A capacity need enters with a date, area, and operational requirements.
Structured constraints
The request is translated into fields that can be compared consistently with candidate data.
Candidate pool
Conversational onboarding supplies organized records for potential drivers, vehicles, documents, coverage areas, and availability details.
Eligibility matching
Matching logic narrows the pool to candidates who meet the stated requirements.
Outreach and confirmation
The coordination workflow contacts suitable candidates and records whether they are currently available.
Confirmed shortlist
Operations receives a prepared group and keeps authority over the final assignment.
From leads to an operational system
The project started by turning leads from job listings into structured driver records. Once that information was available in a consistent format, the same data model could support the rest of the operation: matching incoming capacity requirements with suitable candidates, contacting them, confirming availability, and preparing a shortlist for operations.
Information that had previously lived inside individual conversations became consistent records for drivers, vehicles, documentation, coverage areas, and availability. With that data in place, recruitment and capacity planning no longer had to remain separate processes.
Structuring the operational data first is what made the broader automation possible.
Lessons
- Understand the complete process before choosing what to automate.
- A chatbot can be the entry interface without being the complete system.
- Structuring data well early enables much more valuable automation later.
- Not everything needs AI: part of the problem is better solved with rules, workflows, and strong data structure.
- Automating coordination does not mean automating the final decision; operations can retain control.