- A transport chatbot is a conversational agent that answers the most frequent questions on a network: schedules, routes, disruptions, tickets, fares, lost property, parcel tracking. It does not replace agents: it absorbs repetition.
- The available public figures: 23 million messages exchanged with 1.8 million travellers and 5 connected regions, according to the case study published by Botnation (2026). These are the vendor’s figures: no independent SNCF confirmation was found.
- The factor that decides everything is not AI, it is data: schedules, traffic status and ticketing must be queryable by program. A bot fed with theoretical data fails silently.
- Return on investment is measured in agent hours. The tool below takes three questions and gives you the hours, the days and the full-time equivalents that your volume of requests can free up.
A traveller misses their train and wants to know if another one leaves an hour later. A passenger wants to change their ticket after a strike. A commuter is looking for the nearest stop for their connection. It is 6:20 am, it is snowing, and nobody picks up the phone. This is exactly the moment a transport chatbot is made for.
The topic is not new: SNCF has been experimenting with conversational agents for years, and regional operators have joined in with public results. But the pages competing for the query “transport chatbot” all look alike: they sell, they do not demonstrate. This one takes the question the other way round: the six real missions, the public figures, the method, and a tool to situate your own case.
A transport chatbot is a conversational agent deployed by a transport operator (passenger network, airline, airport, coach operator or logistics provider) to answer the recurring requests of its users and automate simple interactions: passenger information, disruptions, ticketing, complaints. It can be connected to the operator’s operational data, which sets it apart from a simple scripted bot.
The organisations concerned are more numerous than one might think. Rail and urban networks, regions, airports, airlines, coach operators, logistics and delivery platforms: they all share the same symptom. Thousands of identical questions, pouring in at all hours, exploding precisely when the support team is busiest.
- Schedules, next departures and routes: the most frequent question, and the easiest to automate if the data is good.
- Disruptions: strikes, works, bad weather, incidents. This is the highest-value use case, because it happens when the network is saturated.
- Tickets, fares and season passes: compare offers, explain discounts, renew a pass, direct towards online booking.
- Complaints, refunds and lost property: qualify the request, collect the documents, pass a complete case to the right department.
- Logistics tracking: for freight carriers and logistics providers, the passenger equivalent of the parcel on its way.
Transport chatbot: the six typical missions, and what they require
Most debates on transport chatbots stay abstract. Here is what it looks like once translated into concrete missions, with, for each one, the condition that makes it genuinely automatable. It is the condition, not the technology, that makes the difference between a demo and a service.
One point runs through every row of the table: the announced features depend on access to real-time data and to the APIs of each network. Without schedule APIs, without a network status feed, without a ticketing interface, the mission remains a promise.
| Mission | Example question | What makes it automatable |
|---|---|---|
| Schedule information | “What is the next train to Bordeaux after 6 pm?” | Up-to-date schedule data, queryable through an API, with connections |
| Journey planning | “How do I get from Lyon to the airport?” | A journey planner (the same one as the operator’s mobile app) |
| Traffic status and disruptions | “Is my line disrupted tonight?” | Real-time feed of the network status, otherwise the bot answers in the past tense |
| Tickets, fares, season passes | “What is the fare for a round trip this weekend?” | Answers validated by the commercial department, and a handoff to online booking |
| Complaints and refunds | “My train was late, how do I get a refund?” | A written procedure, a data collection form, and a clear owner for the case |
| Lost property and assistance | “I left a bag on the 9:12 train” | A defined process: declaration, information gathering, handoff to the right department |
The six missions do not carry the same weight. On almost every network, schedule information and traffic status represent more than half of the requests. That is where you start, and that is also what makes the rest easier to sell internally.
Proof in numbers: SNCF TER and its 23 million messages
The debate about the usefulness of a transport chatbot is rarely settled with figures. So here are some, according to the case study published by Botnation: 23 million messages exchanged, 1.8 million engaged users and 5 connected regions. The vendor calls it one of the largest public chatbot deployments in France, and this figure is theirs: no independent confirmation of these numbers was found on the SNCF side.
What is interesting in the deployment described by Botnation, beyond the announced volume, is what the chatbot centralises: the fare offers, the services and the assistance of each region, while every TER region has its own formulas, its own passes and its own lines. This is exactly the difficulty every transport player meets: the right information exists, but it is scattered.
“The agent developed with Botnation lets us support travellers at any time, on all their everyday topics. It is a real gain in responsiveness and accessibility for the users of the TER Centre-Val de Loire network.”
Guillaume Gillot, marketing and communication manager at SNCF Voyageurs TER Centre-Val de Loire, quoted in the case study published by Botnation.
Two practical lessons to take from this before launching any project. The first: a regional network with its local specificities lends itself better to a chatbot than a unified national network, because the question “where do I find the right information” is precisely the one users ask. The second: volume is not the obstacle. A flow like the one described by Botnation is not handled with a ten-question script, but with a platform that keeps control of the data, the answers and human handoff.
The SNCF TER case is the most quoted, but it is not an isolated one: Transilien, the RATP and several urban networks currently run or have run conversational agents. The question is no longer “does it work” but “what does it take for it to work here”.
The full details of this deployment, with the problem statement and the figures, are on Botnation’s transport industry pages, which also cover use cases for airlines, airports and logistics providers.
What the other French deployments tell us
The SNCF TER case is a proven success. Still, looking at two other historical experiences helps avoid the same traps, because they document precise limits.
The Tilien chatbot, deployed by Transilien on Facebook Messenger, was benchmarked by the MC2i consultants in 2020, after several months of development and a beta version launched in 2018. Of the six tested features, the results were uneven: traffic and works status scored highest, next departures and journey search were average, first and last departures scored poorly, and transport tickets redirected to the website, giving a disjointed journey. The report also notes that the tool did not recognise stations when misspelled.
The same lesson appears on the SNCF Numerique side: in its first beta version, the Transilien chatbot answered schedules and routes, showed next departures in real time, but explicitly stated that it could not yet report on disrupted situations and that routes relied on theoretical information.
- Real time costs once, not in imagination: traffic status cannot be invented, it must connect to a source, and access to that source is a project condition, not a detail.
- Routes built on theoretical data give right answers on an ideal network, and wrong ones the day it actually rains.
- Station name spelling is a classic trap: count it in the acceptance tests, not in the surprises.
- Systematic redirects to a website break the journey: redirection must be the exception, not the rule.
The Transit Bot product, dedicated to public transport, points the same way: its three flagship features are real-time information (connected to vehicle location data, in SIRI or GTFS-RT format), mobile ticketing and demand-responsive transport. Data again, ticketing again, a messaging channel again.
If you want to understand what happens technically between the user’s message and the bot’s answer, the page on how a chatbot works details the steps, and the guide to building a chatbot compares the three paths: custom code, no-code platform, provider.
How many hours can a transport chatbot save you?
Saved hours can be calculated, and the calculation comes down to three questions: the volume of requests you receive, the share of these requests that is repetitive and qualifiable, and the time an agent currently spends on each. The three answers give the order of magnitude of what a well-sized chatbot can absorb.
Your situation
1. How many traveller requests do you receive per month?
2. What share of these requests is repetitive (schedules, traffic, fares, tracking)?
3. How long does an agent take on one question, without a chatbot?
A targeted script is enough
At this volume, what you need is not a platform project: it is an agent that takes over the twenty most asked questions from your users, with an answer validated by the relevant department and a handoff to a human when it does not know.
Prioritise schedules and disruption information, measure what the bot actually absorbs, and only scale up with the figures in hand.
A real content project
Here, the script alone is no longer enough. You need structured content: fare offers, refund procedures, lost property, accessibility questions, and a method to keep it all up to date.
This is also the moment to connect the data: real-time network status feeding becomes the factor that decides perceived quality.
A full multichannel chain
You move from “a bot that answers” to “a customer relationship channel”. The chatbot must be published where your users are: website, WhatsApp, Messenger, Instagram, SMS. It becomes the main contact for ticketing, complaints and disruptions, and agents are reorganised around what it cannot do.
Human handoff becomes a position in the organisation: who takes over, when, and with what elements already collected.
Industrial scale, like SNCF TER
This is the French proof regime: millions of conversations, regional content to maintain, multi-source data, and teams measuring the effect on inbound calls and on satisfaction.
At this level, the value is no longer in the chatbot alone but in what it reveals: the quality of your data, your procedures, and the way your departments talk to each other.
Calculation assumptions: a working day of 7.5 hours, 21 working days per month. The repetitive share corresponds to the share of requests a well-sized chatbot can handle alone; the rest stay human.
The goal is not to reach the last percentage: most well-run networks aim for 60 to 80% absorption of recurring requests, and that figure drops quickly if the data is not up to date. The operation that really matters is this: measure, publish, measure again.
The six-step method, from the first month to rollout
Here is the sequence that recurs in almost every successful deployment, whatever the size of the network. It has an order, and this order is not a detail: you start with the most asked question, not the most impressive one.
- Count the real requests before choosing the script
Spend a week noting the questions that come in, or ask an agent to keep tally. You are looking for the forty recurring phrasings; on a passenger network, schedules and traffic information top the list.
- Write the answers with the business department
The right answer about a reduced fare, the refund procedure or lost property does not come from IT: it comes from the person who gives it today at the counter. Writing is the slow part of the project, and that is a good thing.
- Settle the data question
A chatbot displaying theoretical schedules fails silently. Identify the API or feed the operator already has for schedules and network status, or decide to start on a scope that does not depend on it.
- Publish on a single channel, and measure
Start on the website, measure what the bot absorbs, what it hands off and where it fails. Thirty days of measurements are worth more than three months of intuitive tweaks. The available channels then let you expand without starting from scratch.
- Expand to the other channels
WhatsApp for regular users, Messenger and Instagram where the community is, SMS for targeted alerts. The script carries over, with channel-specific rules to respect.
- Organise human handoff and maintenance
Name who takes over unresolved conversations, at which times, and who updates the content when fares change. A poorly maintained transport chatbot is worse than no chatbot: it looks right, and it no longer is.
Who builds the chatbot: the three-way trade-off
Once the scope is set, the question is no longer “do we need a chatbot” but “who builds it”. The three paths that exist for any chatbot project carry over to transport, with sector-specific nuances: data is shared across systems, procedures change with every new fare campaign, and the slightest passenger information error is immediately visible.
No-code platform
- The script is built without a developer, and the business department keeps control of the answers.
- The first journey is up in half a day, immediately measurable.
- Channel connectors (website, WhatsApp, Messenger, Instagram, SMS) are managed by the platform.
- The language model is set as a parameter, not as an infrastructure project.
Custom development
- The code connects directly to internal systems, with no middleman.
- The cost is measured in person-days, and maintenance follows after the team that wrote it leaves.
- The project takes weeks before the first useful message, not hours.
- Adding a channel or a business rule requires development: a debt that accumulates.
The third path is the provider one. It makes sense for a very specific trade, on-site staff, or an integrator already in place with the operator, provided the contract clearly settles ownership of the account, access to the editor after delivery and the exact list of what is delivered. In every case, the common point of projects that succeed is the same: someone, on the operator side, owns the truth about the answers.
The three traps that sink a transport chatbot project
The demo works, the service does not. Between the five questions chosen by the sales deck and the 40 real variations of the same request lies all the work. The honest recipe: a question set supplied by the operator, not chosen by the provider.
A language model writes a nice answer, but it does not know that line 12 is 20 minutes late. For passenger information, truth is a datum, not a phrasing.
The chatbot hands off, but nobody takes over, and the complaint stalls. Human handoff is designed before launch: who, when, and with which elements already collected by the bot.
What the law changes for a transport chatbot
Since 2 August 2026, the EU AI Act requires an interactive AI system to inform its interlocutor that they are talking to an AI, unless this is clear from the context. This is Article 50(1) of Regulation (EU) 2024/1689, already applicable and not postponed. For a transport chatbot, the application is simple: the first message announces the automated agent, then the bot does its job.
Two limits to keep in mind. The first: for AI-generated content, the obligation to mark content as artificial is linked to the production of synthetic text, not to the simple dissemination of schedule information. The second: personal data collected in a complaint or a lost property report remain subject to the GDPR, as on any channel. Nothing new, but it belongs in the specification.
How long does it take to deploy a transport chatbot?
The first useful journey is up in half a day on a no-code platform: schedules, FAQ, handoff to a human. The version that holds up, with real-time data, validated content and human handoff, is counted in weeks. The schedule is almost entirely determined by data availability and the writing of business answers, not by technology.
Who answers when the chatbot does not know?
Human handoff is decided before launch, not after. Two models dominate: transfer to a live agent, with the full conversation history, or opening a ticket sent to the relevant department. In both cases, three things are written down: coverage hours, the response time announced to the traveller, and who verifies that the case is complete.
Frequently asked questions
What is a transport chatbot?
A conversational agent deployed by a transport operator to answer the recurring requests of its users: schedules, routes, disruptions, tickets, fares, complaints, lost property. Its specificity, compared with a simple scripted bot, is the ability to connect to the operator’s operational data.
How much does a transport chatbot cost?
The cost depends almost entirely on scope: number of contents, quality of available data, channels targeted, human handoff to organise. On the platform side, Botnation’s public pricing grid reviewed on 3 August 2026 shows a Free plan at EUR 0, a Basic plan at EUR 39 per month, a Pro plan at EUR 59 per month, and a custom Enterprise offer, excluding VAT, which literally includes chatbot creation services. A project handed to a provider is priced on a quote, on the basis of the real scope.
What percentage of requests can a transport chatbot handle?
The realistic share of requests handled alone often sits between 60 and 80% of recurring requests, once the data and answers are validated in place. The rest is handed to a human, and that is normal: the value of a good chatbot is also measured by its ability to hand off cleanly the cases it must not take.
Can a chatbot handle real-time disruptions?
Yes, provided you have a network status feed. This is exactly the point that was missing in the first beta versions of historical chatbots: they clearly stated they did not cover disruption information. A transport chatbot connected to a network status source is, on the other hand, the ideal tool to broadcast information at the exact moment it matters.
What are the best channels for a transport chatbot?
The website remains the first channel, because it is frictionless and measurable. Then come messaging channels depending on the users: WhatsApp for everyday and subscribers, Messenger and Instagram for audiences that live there, SMS for targeted alerts. The key is to start on one channel and measure before expanding.
What is the difference between a transport chatbot and a tourism chatbot?
A transport chatbot talks about journeys, networks and chosen or imposed mobility, and relies on operational data. A tourism chatbot, on the other hand, talks about discovery, accommodation and activities: its role is to attract visitors. Both share the same channels and the same script logic, as shown in our article on chatbots for tourism.
Where to start, concretely
The sequence is the same for a metropolitan network, a regional airline or a freight carrier: identify the question that comes back most often, write the right answer, connect the data if it exists, and measure for thirty days. The SNCF TER case shows what it becomes at scale; the Tilien and Transilien experiences remind us what it costs when you skip the data.
If you want to test the scope on your own volume, go back through the tool above. And if you are starting from scratch, reading the guide to building a chatbot gives you the comparison between the code path, the no-code path and the provider path.
Get your transport chatbot running, on your own or with us
The platform lets you set up a first informational script without commitment, on a free plan. For a complete deployment with real-time data and human handoff, the Enterprise offer includes chatbot creation services, on a quote.
Sources and data: SNCF TER figures and Guillaume Gillot’s quote according to the case study published by Botnation (SNCF clients page, consulted on 25 August 2026); vendor figures, no independent confirmation found; the French version relies on the same source and is not a second validation; MC2i benchmark of the Tilien chatbot (2020); SNCF Numerique article on the beta version of the Transilien chatbot; Transit Bot features from its website; Botnation pricing grid reviewed on 3 August 2026; Article 50 of Regulation (EU) 2024/1689, in force since 2 August 2026.
