ChargeCheck

• 

  Initial Demo screen

• 

  Demo checking

• 

  Demo results

• 

  Real CALL-E call

• 

  Real CALL-E call in progress

• 

  Real CALL-E results

Inspiration

I own an EV, and I kept running into the same frustrating gap: a map or app says a charging station exists, but it can't tell me whether the charger is actually working right now, whether someone's using it, whether there's a queue, or whether it even takes my connector. That information usually only exists in one place — with whoever's physically at (or answering calls for) that station. The phone call is the missing API. That's the whole idea behind ChargeCheck.

What it does

ChargeCheck lets a driver pick a route and a connector type, then uses CALL-E to actually call a set of charging stations and ask directly: is it operational, is a charger available right now, is there a queue, what's the price, what's required to pay. It turns each real conversation into a structured, verified result — never trusting advertised info as fact — and deterministically ranks the stations so a verified "available now" always beats an unverified or advertised-only option.

How we built it

A Next.js/TypeScript app with a clean CallProvider abstraction: one implementation places real CALL-E calls (client.calls.create + polling client.calls.get), the other simulates the same queued → in_progress → completed lifecycle for demo mode, clearly labeled so nothing fake is ever presented as real. Each station gets its own CALL-E call task with a strict result schema (every field falls back to unknown rather than guessing), dispatched concurrently across selected stations. Ranking is plain deterministic scoring — no LLM involved in that step. Live calling uses the caller's own CALL-E API key, entered per-session in the UI; there's no shared or server-side credential anywhere in the app.

Challenges we ran into

Getting a real call to ask the right question turned out to be harder than expected — an early version buried the connector type deep in a checklist, and CALL-E's own paraphrasing dropped it, so a real call to a support line ended up asking about "the chargers" generically instead of the specific connector the driver needed. We fixed that by putting the connector requirement in the very first sentence of the call task. We also hit a subtle stateless-serverless bug: an in-memory session store worked locally but silently broke across separate API route invocations (both in Next.js dev and on Vercel), leaving calls stuck showing "Calling…" forever with no error surfaced. Rebuilding the whole status-polling flow to be fully stateless — and always surfacing the real error instead of failing silently — fixed it for good.

Accomplishments that we're proud of

Getting a real, disclosed AI call through an IVR maze to an actual EVgo support representative and back with a structured, verifiably-sourced result — not a transcript dump, an actual typed answer with an honest "unknown" where the call genuinely couldn't confirm something. That honesty, rather than confident guessing, is the core product bet.

What we learned

That a phone call is a genuinely different kind of data source than an API — it's slower, noisier, and sometimes gets lost in an IVR loop, but it can tell you something true right now that no static listing can. And that "the call succeeded" and "the call established the fact you needed" are two different things worth keeping separate in the data model, not conflating into one boolean.

What's next for ChargeCheck

Pull real, live station data from something like Open Charge Map instead of a fixed list, so it works for any route or country instead of a curated demo set; add terminal webhooks instead of polling; and cache verified results for a short freshness window so a popular station isn't re-called on every single visitor.

Built With

• call-e
• next.js
• node.js
• react
• rest
• typescript
• vercel