A rider waits at Main and 5th a little before nine in the morning. The 22 is not at her stop, and she starts work at 9:15. She calls the agency's customer service number.
She hears a menu: "Press 1 for schedules. Press 2 for routes. Press 3 for service alerts. Press 4 to speak to a representative." She presses 1 and hears the printed timetable. She presses 4 and waits on hold. Then she hangs up and books a ride-hail trip.
Now picture the same call on a different system. She asks, "When is the next 22 coming to Main and 5th?" The system answers, "The next 22 eastbound arrives in four minutes." She stays at the stop, and the agency keeps the trip.
That difference is what people mean by a next-generation IVR. This guide explains what changes and why transit feels the gap more than most industries. It ends with what to check before you buy.
What "next-generation IVR" means
A traditional IVR is a phone menu. It plays recorded or synthesized prompts and moves callers through numbered options. It works for simple questions with stable answers. It does poorly with everything else.
A next-generation IVR is different in four ways.
1. Natural language instead of a menu tree
Riders say what they want in their own words. "When is my bus coming?" "Is the 14 on detour?" "Is there service on the holiday?" The system works out the request from the words, not from keypad presses.
2. Live data instead of fixed prompts
A traditional IVR plays recordings that someone made weeks or months ago. A next-generation system reads the agency's GTFS and GTFS-RT feeds. It answers with current arrival predictions, active service alerts, and detours.
3. Your service data instead of generic scripts
A general-purpose voice assistant does not have your route names, stop names, or service patterns. A transit voice agent works from your own schedule data. When a rider asks for "the 22," the agent reads your Route 22 from your feed.
4. Answers instead of deflection
Many legacy IVRs count success by how many callers leave the menu without reaching a person. Some of those callers got an answer. Others gave up. A next-generation system should be measured on a different question: did the rider get a correct answer?
Why a traditional IVR fits transit badly
Most industries have one or two IVR problems. Transit has several at once.
Rider questions depend on the route, the stop, the direction, and the time. "When is my bus" means one route at one stop right now. No phone tree of reasonable size covers every route, stop, and direction. So the menu sends the rider to a person, or to the app or website. In both cases, the phone system did not answer the question.
Real-time information also cannot be recorded in advance. Weather, construction, and vehicle problems change the answer through the day. Staff cannot re-record prompts as fast as service changes.
Call center capacity is the third problem. Arrival-time calls are among the most common calls a transit agency receives. When calltakers answer them one after another, complaints and harder calls wait in the queue. The post 5 Signs Your Transit Agency's IVR Is Holding You Back lists the warning signs in more detail.
What to look for in a next-generation transit IVR
If your agency is evaluating AI voice agents, these criteria matter more than a polished demo.
- Language understanding for transit. A generic model can confuse a rail line with a queue. Test the system with the words your riders use, including local names for routes and stops.
- Direct use of GTFS and GTFS-RT. A voice agent that does not read your real-time feed cannot give real-time answers. Ask to see it answer from your feed, not a sample feed.
- Careful handling of unclear requests. A rider may ask for "the 22" when you run a 22A and a 22B. The system should ask which one. It should not guess.
- A clear path to a person. Complaints, upset callers, and questions outside fixed-route service need your staff. Ask how the call reaches them and what your staff see when it does.
- A record of every call. When a rider disputes an answer, you need the recording, the transcript, and the data used to answer. Without them, you cannot check what happened.
- A realistic timeline. If your agency already publishes GTFS and GTFS-RT feeds, the data work is done. Ask the vendor what work remains and how long it takes.
- Your existing phone number. Riders should not need to learn a new number. The system should work with the phone setup you already have.
For a direct comparison of the two approaches, read IVR vs AI Voice Agent: What Transit Agencies Need to Know.
What an AI voice agent does not fix
A new phone system does not solve every problem. Plan for these limits before launch.
- The answers are only as good as the feed. If your stop names are unclear or your predictions drift, the voice agent repeats those errors. Check the feed before riders hear it.
- Not every mode fits. Fixed-route questions match GTFS data well. Paratransit trips and demand-response bookings depend on other systems and often need a person.
- Riders need a way to reach a person. Tell callers how to reach staff, and keep that path short. A rider who feels trapped in an automated system will not call back.
Where Pulse RideInfo fits
Pulse RideInfo is an AI voice agent and IVR replacement for public transit agencies. It answers rider calls, texts, and web chats 24/7. It reads your GTFS and GTFS-RT feeds for arrival predictions, route details, stops, and service alerts.
Agencies deploy it as a standalone voice agent or as a replacement for a legacy IVR. Either way, riders call the same number. Pulse RideInfo covers fixed-route bus service. Paratransit and demand-response callers still go to your call center staff.
Getting started
If your agency publishes GTFS and GTFS-RT feeds, most of the technical work is already done. The open question is whether a next-generation IVR fits your service and your procurement timeline. Request a demo, and we will show what Pulse RideInfo answers on your own routes.
