For some reason, my demo video link isn't being changed on Devpost. If it still didn't get fixed, please find my demo video here : https://www.youtube.com/watch?v=dh2AKMq5HFI

Inspiration

On the crowded streets of Dhaka, I see delivery riders having a hard time every day. They wait outside gates for a long time under the hot sun. They answer customer calls and messages while riding through traffic, which isn't safe. They ride all the way to a door and find no one home, and sometimes the order turns out to be fake. I noticed the same thing in Uber rides, where drivers keep talking to customers on the phone while driving.

When I saw that CALL-E lets an AI make real phone calls, the idea came right away: let the AI make those calls so the rider doesn't have to. RouteReady calls the next customers while the rider is still on the way. It finds out who is actually home before the rider gets there, and the rider can keep their eyes on the road.

Alt text

What it does

RouteReady calls a rider's next customers while the rider is still on the road.

• It picks who to call : The app estimates when the rider will reach each stop. When a customer is close enough, it calls them through CALL-E. It makes one call at a time and calls each customer at most once a day.

• The AI asks four things : It says it's an AI assistant, then asks:

1) Can you receive the parcel when the rider arrives?

2) If you can't, can a guard or neighbour take it?

3) Is the cash ready?

4) Is there a landmark near your door?

Alt text

• It turns the answer into data : CALL-E returns a strict result: ready now, in 15 minutes, in 15 to 45 minutes, later today, or not today. The result also includes the customer's exact words.

• It checks the answer first : The route changes only if the right person answered, gave a clear time and was quoted in their own words. If an answer is unclear, the route stays the same and the customer isn't called again.

• It re-orders the stops : Customers who are ready move up. Customers who need more time move later. "Later today" stops become revisits. "Not today" stops come off the route, and a dispatcher has to approve that.

• It shows the rider one instruction : The rider sees the next stop, whether the customer is ready, their landmark and the cash to collect. The call transcript shows up live, so the rider never has to pick up the phone.

• It works on real routes : Judges can paste their own CALL-E key, pin up to 5 stops on a map and ride. The rider's position comes from dragging on the map or from the phone's GPS. On the Dhaka demo day, RouteReady cut failed door attempts from 2 to 0 and time waiting at doors from 3 minutes to 0. It avoided 2 wasted trips and finished the route 16 minutes earlier. The 7 calls cost $0.35.

How it works :

Alt text

How we built it

• Calls through CALL-E : Each call uses a short script and a strict answer schema. CALL-E sends back when the customer is ready, who can take the parcel, whether the cash is ready, a landmark, and the customer's exact words.

• An evidence gate : An answer changes the route only if the right person answered, said a time and was quoted in their own words. Anything else changes nothing.

• Exact re-ordering : A branch-and-bound search tries every order of the remaining stops and picks the one that finishes soonest with the fewest late deliveries.

• Safe by design : It places one call at a time and calls each customer at most once a day. Each call has its own idempotency key, so a retry can't dial twice. If CALL-E doesn't clearly confirm a call went through, the app stops calling. The API key never reaches the browser.

• Works anywhere : You can pin stops anywhere, choose any call language and follow the rider by GPS. The Dhaka demo day uses real road times from OSRM.

• Proven without calls : A simulator runs the same day with and without RouteReady. Tests check the search against brute force and run the real SDK against a fake CALL-E API.

• Reusable skill : The core is also a CALL-E skill, route-readiness-call, and a test keeps its schema in sync with the app's.

Architecture Diagram :

Alt text

Challenges we ran into

• No Bangladesh calls : CALL-E rejects Bangladesh numbers, so I tested live calls on US numbers. "Completed" isn't always a real answer. CALL-E marked an AI receptionist's call as done. I added an evidence gate so the route changes only on the customer's own words.

• Failed requests can still ring : Idempotency keys stop double calls. If a call's status is unclear, all calls stop.

• No cancel button : A placed call always rings, so it makes one call at a time, once per customer a day.

• Messy live transcripts : Speech arrives in pieces, so I merged them into clean lines. Keeping keys safe on a public app. Keys stay in memory only, and phone numbers are masked everywhere.

• No traffic data : Arrival times are estimates from distance and the rider's speed.

Accomplishments that we're proud of

• Real calls, anywhere : You paste your key, pin stops and ride.

• It doesn't trust weak answers : It left the route unchanged when an AI receptionist answered.

• Proven results : On the demo day it had 0 failed door attempts, avoided 2 wasted trips and finished 16 minutes earlier.

• Safe by design : It never calls a customer twice, and keys and phone numbers never leak.

• Hands-free for the rider : The rider sees a live transcript and one instruction at a time.

What we learned

• Don't trust AI output blindly : Ask for the customer's own words as proof.

• Phone calls can't be undone : Design for safety before speed.

• Test early with real calls : The test hotline showed problems a simulator never would.

• Simple beats clever :A small, exact search on a few stops works well.

• Start from a real problem : Watching Dhaka's riders shaped every design choice.

What's next for RouteReady

• Bangladesh and Bengali calls : Go live in Dhaka as soon as CALL-E supports Bangladesh numbers.

• Smart retries : Call once more when a customer clearly didn't pick up.

• Live traffic : Use real traffic data for arrival times.

• Dispatcher dashboard : Approve "not today" reschedules and watch every rider in one place.

• Many riders : Plan and call ahead across a whole fleet, not just one rider.

• Fake order checks : Flag customers who never answer or keep refusing deliveries.

• Courier integrations : Connect to courier and shop systems so orders load automatically.

• Saved data : Keep routes and call history after a server restart.

Built With

Share this project:

Updates

Submission history