Designing a Conversational Railway Enquiry

In 2020, passengers pieced railway information together from enquiry staff, station displays, official services, and third-party applications. Each source covered only part of the journey. Enquiry counters remained trusted because they combined live information with a staff member's judgment, but queues made that help difficult to access when passengers were in a hurry.

Displays could show arrivals, departures, platform numbers, or coach positions, but passengers still had to find the right display and interpret it. Mobile services helped with advance planning, yet the information was fragmented and people often returned to staff for an immediate answer on the station.

“The opportunity was not another chatbot. It was a clearer way to coordinate railway information around a passenger's question.”

I observed how the enquiry counter worked at Vijayawada Junction and interviewed enquiry staff at Mumbai CSMT. The staff used a railway enquiry system with approximately 30 categories, moving between live train information, reservation status, fares, platform information, and other station services according to the passenger's question.

I also documented station displays, coach-position systems, navigation maps, and ticketing machines, then interviewed three passengers about planning, station enquiry, mobile applications, payment, and assistance from family members.

A remote card sort with five users grouped the enquiry system into reservation, booking and cancellation, station amenities, destination and fare, train arrivals, and booking status. The first prototype narrowed this system to trains to destination, platform number, arrivals and departures, delays, reservation, and fare.

Those categories became more than navigation. They provided the foundation for intents, alternative utterances, conversation states, error handling, and the visual cards shown during the exchange.

With permission from Central Railway, I used recorded enquiry-counter exchanges to study how passengers actually asked for information. The dialogue model documented the intent, the many ways it could be invoked, what context needed to survive between turns, and how Tulasi should confirm or repair an uncertain exchange.

• Intent and alternative ways to invoke it
• Context carried between turns
• Implicit confirmation
• Explicit confirmation for low-confidence input
• Conversational markers and progress
• Error handling and recovery

When a passenger named a city instead of a station, the agent needed to disambiguate without sounding as if it had failed to hear. When several trains were available, they had to remain addressable as the first, second, or third option, or by departure time. The conversation also had to carry a selected train into ticketing rather than force the passenger to start again.

Voiceflow and Twine supported scenario and conversation prototyping. Dialogflow handled the natural-language layer, while Google Assistant supplied automatic speech recognition and text-to-speech. Whimsical supported the larger flow model.

Voice was useful when typing was difficult, but a station is noisy and railway details are easy to forget. I therefore designed a multimodal interface with conversation starters, train-result cards, expanded journey details, tickets, payment choices, and onboarding for a preferred station, IRCTC account, and payment method.

The station concept added a presence sensor, a directional or noise-cancelling microphone arrangement, and a visual display. A printed token acted as a cash fallback. These hardware details remained conceptual: COVID-19 prevented deployment and evaluation on the station.

Seven Android users completed a scenario on a device configured with Hindi Google Assistant. They had to find trains from Mumbai CSMT to Solapur and book a general ticket. Afterward, they answered fifteen seven-point Likert questions, each with a mandatory written reason.

The questionnaire covered likeability, conversation flow, ease of use, advice, accuracy, concept, and the authenticity of the conversation. The study was qualitative and exploratory; it did not establish a commercial success rate or a production performance benchmark.

“I find that sometimes it becomes tricky just to use the voice assistant; visual feedback makes it a bit easy.”

“I like the interaction of voice and I think my parents will use this more.”

The next iteration needed to carry context from train discovery into ticketing, vary confirmation language, and make the transition into a specialised railway agent more legible. Speech Synthesis Markup Language offered a way to separate spoken Hindi from English train names and alphanumeric details shown on screen.

Discoverability could come from a station-aware prompt, an entry point in Maps, or a phone-call version for passengers without smartphones. Error paths were defined for unheard input, low confidence, unavailable destinations, and requests outside the prototype's scope.

The project's strongest contribution is the service and dialogue model, not the visual chatbot shell. Real enquiry conversations produced better intents, confirmation strategies, and repair paths than a generic FAQ structure could have.

A production version would require a live railway data connection, language specialists, accessibility testing, privacy review, and field deployment. Voice and visual interaction would need to remain complementary because a station is public, noisy, multilingual, and time-sensitive.