Inspiration
I live near Red Hills in Hyderabad, and every other delivery driver who's ever come here has gotten lost at some point. Streets are not well planned, multiple dead ends and definitely no boards for street names etc. So the driver calls support, gets read the same postal address they already have, and we're both stuck.
I wanted to see if a CALL-E agent could actually have that conversation instead of a bored support rep — ask where the driver's coming from, give them landmarks in the right order, and only bail to a real human number if it genuinely can't get them there.
What it does
A driver taps "request help" (or someone triggers it on their behalf), and CALL-E calls them. The agent asks which direction they're coming from, walks them through landmarks for that specific approach, confirms the building by what it actually looks like, and if there's a unit/flat number, makes sure they've actually reached it and not just the entrance, before hanging up. If the driver's still stuck after all that, it offers a real contact number, reads it out slowly, and ends the call. Nothing automated happens after: no webhook, no second call, no SMS. The number's only ever revealed if the call itself confirms it was actually read aloud.
The whole thing is config-driven. One JSON file per building, landmarks, approach directions, entrance details. So the same agent works for a totally different address without touching any code. I built two real configs to prove that: my own flat, and a bakery on a traffic circle across town. Different enough that if the schema handled both, it'd probably hold up for a lot more.
How I built it
Plain Node.js, no build step, zod for validating configs at runtime. The actual "product" here isn't the code, rather it's the wording of the call-task instruction I hand to CALL-E, and I rewrote that more than once after listening to what real calls actually did wrong. Everything's logged: every real test call's full transcript and event timeline gets saved locally so I could go back and see exactly what the agent said, not just whether it "worked."
Challenges I ran into
Building on a brand-new beta phone-call API meant some debugging detective work. My biggest one: calls to India kept failing instantly with no ring. I initially thought I'd found a locale bug (hi-IN failing, en-IN working), but a second test proved that wrong, same locale, different result. Turned out to be an intermittent thing tied to how India-destination calls are currently routed on CALL-E's platform, and their Discord support was actually pretty responsive about it, including pointing me at a US testing hotline to isolate whether it was my integration or their routing. That back-and-forth is what pushed me to build better call diagnostics that pull the per-attempt failure codes and the full event timeline, since a failed call's plain-English summary doesn't always capture what actually happened under the hood.
Also managed to accidentally commit my real phone number into git history early on and had to actually scrub that properly.
What I learned
That the hard part of this kind of project isn't the API integration, it's the conversation design i.e. how you handle a driver who gives you a landmark you don't recognize, or says "okay" when they mean "I heard you, not that I found it." And that when you're building on a beta phone-call API, you cannot trust the platform's own plain-English summary of what happened on a failed call. Read the raw event log.
What's next
Realistically, this stays scoped to what it is: an opt-in fallback for addresses worth pre-configuring, not a blanket last-mile solution. If I kept going, the obvious next step is food/quick-commerce delivery apps where we solve the exact same "driver is near but can't find the door" problem, just at way higher volume than my one flat and one bakery. Ride-hailing repeat pickups would be the same pattern, later.
Log in or sign up for Devpost to join the conversation.