- A bus chatbot is a conversational assistant deployed by a bus or coach network (urban, school, interurban) to answer passenger questions: next departures, disruptions, journey planning, tickets and passes, how the network works. It lives wherever the passenger asks the question: the network website, then WhatsApp on travel day.
- Bus is not like other transport modes on the data side: since the French mobility orientation law, organising authorities must make their static and dynamic data accessible and reusable (article L. 1115-1 of the Transport Code). As of 5 October 2026, the National Access Point lists 221 real-time datasets for public transport, 200 of which publish next departures.
- French networks are already doing it, dates included: a Messenger chatbot at RATP as early as September 2017, the Bonjour RATP connector on ChatGPT (checked on 5 October 2026), the NomadCarBot of Nomad Normandie on 3 November 2025, the WhatsApp chatbot of AuxR’M le bus in Auxerre on 28 May 2026.
- Four architectures are enough to cover every case: an editorial FAQ, plugging in the real-time feed, door-to-door journey planning, tickets and booking. The router in the middle of this article decides between 72 real situations (network × need × volume × channel).
- The cost comes down to three lines: the licence (from 39 € per month excluding VAT on the Botnation grid checked on 5 October 2026), AI credits (25 € per 1,000), and the build, free if you do it yourself or on quote through Botnation’s Enterprise offer.
A bus chatbot mostly makes the news through announcements: a network launches one, a vendor praises its own, and the story stops there. Nothing on how to build the service, on what the law already hands to a network, or on what it costs on a public price list. That is precisely what this article does.
Bus concentrates difficulties that rail does not know: hundreds of networks run by different organising authorities, timetables that change with every school holiday and every new school year, passengers who will not install one app per network, and a spike of questions on the very morning of the trip. A well-built bus chatbot answers all four constraints at once, and the dated examples below show this is no longer theory.
The plan follows the order that matters: what the passenger asks, dated French evidence, what regulatory open data already provides, the four possible architectures with a router to choose, the method, the channels, the law, and today’s public prices. Botnation appears on both sides that count: as the editor of the no-code platform, and as a custom-build provider through its Enterprise offer.
What the passenger asks a bus chatbot, mission by mission
A passenger never asks for “a chatbot”. They ask whether their bus is coming, whether it is late, how much the ride costs, and how to get to the station. Here are the six missions that come back on every network, with the concrete condition that makes each one automatable. The condition, not the technology, separates a demo from a service.
| Mission | Example question | What makes it automatable |
|---|---|---|
| Next departures | “When is the next bus to the station?” | A real-time feed per stop (GTFS-RT or SIRI), otherwise the bot states theoretical times and says so |
| Disruptions and roadworks | “Is my line diverted tonight?” | A feed of the network state, and a written rule: what the bot says when it does not know |
| Door-to-door journeys | “How do I get from home to the shopping centre?” | A journey engine queried by the bot, often the one the network already exposes |
| Tickets, fares, passes | “Which pass for a student?” | Answers validated by the commercial team, then ticketing to sell or resend |
| Understanding the network | “Where to buy a ticket, does the line serve the school?” | An editorial FAQ kept up to date: points of sale, accessibility, rules, back-to-school |
| Complaints and lost property | “I left my bag on the 5 pm bus” | A defined route: declaration, information collection, transfer to the right department |
On almost every network, the first two lines of the table (departures and disruptions) weigh more than half of the questions: that is where a bus chatbot starts, and that is where open data, a bit further down in this article, changes everything. The last four demand validated editorial content, not plumbing: that is writing work with the network’s departments, not an integration project.
Collect the questions actually asked to the network over the last three months: email, phone, social media, counter queue. That is the raw material. A bus chatbot that answers the questions that actually arrive beats a chatbot that guesses.
Three French networks have done it: the evidence, dated
The story starts badly, and it is useful to know it. As early as September 2017, RATP launched a chatbot on Facebook Messenger, built with the start-up Minsday: personalised journeys, departure times at favourite stations, disruption alerts. The consulting firm mc2i tested it feature by feature in May 2020, during the lockdown: of the five features assessed, none scored above 2 out of 3, journey planning dropped to 1 out of 3, and the finding repeats like a leitmotiv: the user journey falls apart, the bot sends users back to the website for what it should display itself. The lesson fits in one sentence: a chatbot that redirects is not a chatbot.
Six years later, the same ambition is served by other channels and real data, this time on bus and coach networks:
- Bonjour RATP on ChatGPT (page checked on 5 October 2026): the Paris-area service offers a connector to activate in ChatGPT, then to call with @BonjourRATP. The service page presents it as giving access to “itinéraires, trafic en temps réel et titres de transport en Île-de-France, directement dans vos échanges” (journeys, real-time traffic and travel passes in the Paris region, directly inside your conversations; published in French only, translation ours), covering metro, RER, Transilien, bus and tram. The passenger gets a journey, the status of a line or a fare tip without leaving the conversation.
- NomadCarBot, Nomad network (Normandy): in its announcement of 3 November 2025, for the fifth anniversary of the NOMAD Car coach network, the region presents an assistant available on its website around the clock, seven days a week, plus a “Next departures” module showing the theoretical coach times at a given stop, for commercial lines, on any date. The announcement states it is experimenting with real-time timetable diffusion, roadworks and diversions included, starting with a first batch of lines.
- AuxR’M le bus (Auxerre urban area): on 28 May 2026, the network announced a chatbot built into WhatsApp. The announcement text deserves quoting, because it lists the actual scope: “accompagnement pour comprendre le réseau, recherche d’un horaire, recherche d’un tarif, prendre rendez-vous en agence virtuelle ou encore vous rediriger vers les réservations Flexibus” (guidance to understand the network, timetable lookup, fare lookup, booking an appointment at the virtual agency, or redirecting you to Flexibus bookings; published in French only, translation ours). That is three of the six missions in the table above, plus appointments and demand-responsive transport, on the channel the passenger already holds.
The triptych speaks for itself: a national multi-network operator goes through ChatGPT, a regional coach network puts the assistant on its website, a medium-sized urban network picks WhatsApp. Three channels, one movement. For rail, our transport chatbot overview documents a much larger regional deployment, with its 23 million exchanged messages; this article deliberately stays on bus and coach.
Open data changes the equation: what the law already provides
Here is the point commercial pages do not make: since the French mobility orientation law of 24 December 2019, connecting a chatbot to a network’s data is no longer a commercial negotiation with the operator, it is a right set by the Transport Code. Article L. 1115-1 (created by article 25 of the law, version in force checked on 5 October 2026 against the consolidated text) requires organising authorities and their ecosystems to make their data accessible. The text is explicit: data holders must “mettent à jour et rendent accessibles et réutilisables” (update and make accessible and reusable) the “données statiques et historiques observées ainsi que les données dynamiques concernant les déplacements et la circulation” (observed static and historical data as well as dynamic data on travel and traffic; published in French only, translation ours). And to remove any ambiguity about who supplies what, the text says: “Pour les services de transport qu’elles organisent, les autorités mentionnées au 1° du présent article sont responsables de la fourniture des données” (for the transport services they organise, the authorities mentioned in point 1 of this article are responsible for supplying the data), the task being delegable to transport operators or to operators of passenger information and operating aid systems.
Concretely, this data lands on the National Access Point, transport.data.gouv.fr, whose home page reminds producers in these words: “vous êtes tenus de publier vos données relatives à l’information voyageur sur le Point d’Accès National” (you are required to publish your passenger information data on the National Access Point; French only, translation ours). Its dashboard, checked on 5 October 2026, gives the real state of the reservoir:
The formats are not exotic: theoretical timetables arrive as GTFS or NeTEx, real time as GTFS-RT or SIRI. These feeds are exactly what a chatbot queries to answer “when is the next bus” without inventing: vehicle positions, next departures at the stop, traffic information messages. If the reader’s network is among the 362 organising authorities whose theoretical timetables are published, the technical question is not obtaining the data, but consuming it properly: polling frequency, handling stops without a feed, an explicit fallback on the theoretical timetable.
The National Access Point counter counts datasets, not freshness commitments. Before writing “real time” on the network’s page, check on the dashboard that your network actually publishes next departures in GTFS-RT or SIRI, and test the feed on a roadworks day: that is the day the answer matters.
Four bus chatbot architectures, and a router to choose
Every successful project stacks on the same ladder: start with what does not move (the network FAQ), plug in what moves (the real-time feed), add journey computation, and only then selling and booking. Each step justifies itself, and the router below tells you which one your project starts with.
Which architecture for your bus chatbot?
Four answers, one verdict, the rule that wins. Or load a real case from the table below.
1. Your network is mostly
2. The passengers’ dominant need
3. Questions per month
4. Target channels
Level 2: plug in the real-time feed
The heart of a bus chatbot: the next departures at the requested stop, and the state of the line during roadworks. If the network publishes on the National Access Point, this level is mostly clean integration work: feed polling frequency, an explicit fallback on the theoretical timetable, and a fixed formula when the feed does not answer. This has been the level of AuxR’M le bus since 28 May 2026.
Level 1: the editorial FAQ, kept by hand
Fares, points of sale, accessibility, rules, how the network works: everything that changes twice a year, at holidays and at back-to-school. For a small network under a thousand questions a month, this level already delivers a measurable service, with no data connection at all. The condition: someone at the network re-reads the answers at every change of period.
Level 3: door-to-door journeys
“How do I get from home to the station” is not answered by an FAQ: it takes an engine crossing timetables, connections and walking. The good news: most organising authorities already expose one. The chatbot then becomes a conversational front end over that engine, which is exactly what the Paris-region connector checked on 5 October 2026 does. The trap already observed in 2020: a journey that ignores ongoing disruptions makes the whole service lose credibility.
Level 4: tickets, passes, booking
Selling a ticket, managing a pass, booking demand-responsive transport: the bot enters orders and personal data. This level requires the network’s ticketing as an API, a passenger account, and the legal rules around selling: our article on the ticketing chatbot details those rules, which apply to a bus ticket as much as to a show seat.
School network: the calendar before the technology
On a school or peri-urban network with real volume, everything is decided in a few weeks: back-to-school registrations, catchment areas, whether the line serves the school, the first days of September. The winning architecture crosses the back-to-school FAQ, line alerts (roadworks, snow, strikes) and WhatsApp, where the parents are. That is the choice announced by the Auxerre network on 28 May 2026, which also routes to demand-responsive booking.
The cascade applies in order: selling or booking first (level 4), then journeys (level 3), then real time (level 2), the FAQ holding the bottom of the ladder. The school case departs from it: when back-to-school makes the volume, the calendar picks the architecture. One network, one step: copy this table into your specifications.
| Real question | Network | Volume | Verdict | Load |
|---|---|---|---|---|
| “When is the next bus to the station?” | Urban | 1,000 to 10,000 | Level 2 | |
| “Is my line diverted because of roadworks?” | Urban | More than 10,000 | Level 2 | |
| “Which pass for a student?” | Urban | 1,000 to 10,000 | Level 4 | |
| “I cannot book my demand-responsive ride” | Interurban | Fewer than 1,000 | Level 4 | |
| “Where to buy a return ticket for line 40?” | Interurban | 1,000 to 10,000 | Level 4 | |
| “Does the line serve the high school since September?” | School | 1,000 to 10,000 | School network | |
| “School transport registration: which documents?” | School | More than 10,000 | School network | |
| “How do I get from home to the shopping centre?” | Urban | Fewer than 1,000 | Level 3 | |
| “Is the network wheelchair accessible?” | Urban | Fewer than 1,000 | Level 1 | |
| “Line 40 timetables on Sunday?” | Interurban | Fewer than 1,000 | Level 1 |
For reference, the same ladder in one table, with what most often jams at each step:
| Level | What the passenger gets | What needs connecting | What often jams |
|---|---|---|---|
| 1. Editorial FAQ | Fares, points of sale, rules, accessibility | Nothing: content written and validated by the network | Content ages at every holiday: schedule the re-read |
| 2. Real time | Next departures at the stop, state of the line | The network’s or the authority’s GTFS-RT or SIRI feed | The fallback on the theoretical timetable must be stated, never hidden |
| 3. Journeys | Door-to-door routes with connections | The network’s existing journey engine, queried by the bot | A route ignoring ongoing disruptions serves the passenger poorly |
| 4. Selling and booking | Buy a ticket, manage a pass, book demand-responsive transport | Ticketing as an API, a passenger account | Selling law and personal data, to frame in the specifications from day one |
The method in six steps, from the feed to the first announced departure
- Collect the real questions. Three months of requests to the network: email, phone, social media, counter. Keep them with their exact wording, typos on stop names included: they will serve as recognition tests later.
- Check what exists on the data side. On the National Access Point, search for the network: theoretical timetables in GTFS or NeTEx, real-time feeds in GTFS-RT or SIRI. This ten-minute check decides whether the project starts at level 1 or level 2 of the ladder.
- Pick the starting step with the router. Network, dominant need, volume, channels: the verdict above gives the starting architecture and its actual scope. Never promise more than the step holds, above all never “real time” without a feed.
- Write the answers with the network’s teams. Fares with the commercial team, rules with legal, accessibility with the department in charge. The bot assembles these validations, it does not replace them.
- Connect, and test on a roadworks day. A real-time feed is judged when it is useful: polling at different hours, stops without a feed, a diverted line. Fallback behaviour is part of the requirements, on the same level as the nominal answer.
- Measure, and grow the ladder. Questions resolved without human takeover, response time, top of misunderstood questions: these three numbers decide the move to the next step. Human takeover is settled before going live, not after.
These six steps are the bus declination of a general method described in our article on the transport chatbot, which covers the topic beyond bus alone: that is where you will find the mission panorama, the build-versus-outsource decision, and the rail-side evidence.
Web, WhatsApp: the channel follows the passenger, not the other way round
The channel choice is not aesthetic, it is calendar-driven. Before the trip, the question is born on the network website, while checking timetables: the widget lives on the home page and on the timetables page. On travel day, the passenger is outside, on their phone, and will not install an application for a network they ride twice a week: that is where WhatsApp wins, and it is the explicit choice of the Auxerre network on 28 May 2026. One scenario lives on both channels, the history following the conversation.
The argument is not new, but it has changed scale: back in 2017, the Paris Messenger chatbot showed you could reach the passenger without a dedicated app, with the limits of the time; in 2026, the same reasoning deploys on WhatsApp for a medium-sized urban network, on the website for a regional coach network, and even inside ChatGPT for the Paris multi-network service. Our pages on deployment channels detail these integrations, and the Hello Scoot testimony shows another kind of mobility, shared this one, that automated its recurring questions on social media with the same platform.
AI and personal data: the minimum, without ghost laws
Three rules frame a bus chatbot, and none of them is decorative. The first comes from the European AI regulation, in application since 2 August 2026: its article 50, paragraph 1, requires that AI systems intended to interact directly with people be designed so that the people concerned “are informed that they are interacting with an AI system”, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect (text of regulation (EU) 2024/1689 on EUR-Lex). For a bus chatbot, the application is simple: the first message announces the automated agent, then the bot does its work.
The second is the GDPR, as soon as the bot touches personal data: a lost-property claim, a school file, a passenger account at level 4 of the ladder. Stated purpose, retention period, legal basis: nothing specific to bus, but it gets written into the specifications. The third is a referral: selling tickets inside a conversation adds the rules specific to ticketing (withdrawal, resale, proof of purchase), which our article on the ticketing chatbot documents rule by rule with the consolidated texts. Finally, the open-data obligation seen above is not a constraint on the chatbot, it is its fuel: it is what puts the feeds within reach.
What a bus chatbot costs: three lines, not thirty
The tally always comes down to the same three lines: the platform licence, the credits consumed by the AI, and the build. Botnation’s public grid, checked on 5 October 2026, fixes the first two:
| Cost line | Checked on 5 October 2026 | What makes it vary |
|---|---|---|
| Platform licence | Free 0 €, Basic 39 € per month, Pro 59 € per month, Entreprise on demand (excluding VAT) | The number of users to serve and the advanced features; the Entreprise offer literally includes “Chatbot creation management” |
| AI credits | Packs of 1,000 credits at 25 €, 5,000 at 100 €, 15,000 at 250 €, 60,000 at 900 €; user outside a plan 0.05 € per month | The volume of AI requests (answers on the network’s connected data, like theoretical timetables, do not consume generative AI) |
| Build | On your own on the platform: your team’s time; entrusted to the Botnation team: on quote | The scope: amount of content to validate, feed connections, channels, human takeover to organise |
For a delegated build, the public FAQ of the grid itself gives the market order of magnitude: outside a SaaS subscription, “it will generally cost between €5,000 and €30,000, or even more, depending on the features you need”. That range is the market’s, not a Botnation price: the quote is built on the actual scope, and nothing else. This is also where Botnation’s dual positioning makes sense: the team that builds is the team that edits the platform, so there is no intermediary to take over, and the network keeps control of its account, its scenarios and its database in the no-code editor after delivery. A third-party agency remains legitimate when an integrator already knows the network’s information system: what matters is that the choice is made with full knowledge.
Frequently asked questions
What exactly is a bus chatbot?
A conversational assistant deployed by a bus or coach network, reachable on the network’s website, on WhatsApp or on messaging apps, answering passenger questions: next departures, disruptions, journeys, tickets and passes, how the network works. Its specificity, compared with a scripted bot, is that it can plug into the network’s data, theoretical as well as real time.
Can a small network afford to start?
Yes, and it is actually where the return is most visible: a few hundred questions a month are enough to measure the service. Level 1 of the ladder (the editorial FAQ) requires no data connection, and the platform’s free licence lets you build before paying. The real starting expense is the time spent writing the answers with the network’s teams.
Is real time mandatory to be useful?
No, but you must not claim it without having it. A network without a real-time feed already delivers a service with theoretical timetables, provided it says so: “theoretical times, taken from the timetable in force”. The worst is ambiguity: an answer presented as real time that comes from a theoretical file destroys the credibility of the whole service. Before promising, check what your network publishes on the National Access Point.
How long does it take to deploy a bus chatbot?
The first useful path, timetables FAQ and transfer to a human, is assembled in half a day on a no-code platform. The version that holds the road, with a real-time feed, content validated by the network’s teams and organised human takeover, is counted in weeks. The calendar depends almost entirely on data availability and answer validation, not on technique.
Does the chatbot replace the network’s app?
It does not replace it, it comes first. Many passengers do not download an app for occasional use: the chatbot serves them where they already are, on the web and in WhatsApp. For heavy uses (named ticketing, push notifications), the app keeps its advantages; for the question of the moment, the conversation wins. The two meet at level 4 of the ladder, behind a single passenger account.
Who answers when the chatbot does not know?
Human takeover is decided before going live: transfer to an agent with the full history, or opening a ticket routed to the relevant department. Three things get defined in writing: coverage hours, the response time announced to the passenger, and who checks that the file is complete. A bus chatbot that fails silently is worse than absent: it discourages the second question.
Your network already has its questions: start with the first twenty
Take the last three months of requests, sort them on the four-architecture ladder, and build the first scenario yourself on the platform; or entrust the build to the team that edits it, under the Entreprise offer, on quote.
Talk to our chatbot experts or request a quote for your chatbot build.
Sources. French Transport Code, article L1115-1 (created by article 25 of law no. 2019-1428 of 24 December 2019, the mobility orientation law, amended by law no. 2025-391 of 30 April 2025), version in force checked on 5 October 2026 against the consolidated text (published in French only; quotations translated by us); transport.data.gouv.fr, home page and open-data status page, checked on 5 October 2026; regulation (EU) 2024/1689 of 13 June 2024, article 50 paragraph 1, official English text on EUR-Lex, in application since 2 August 2026; RATP and Minsday, Messenger chatbot launched in September 2017, tested by the consulting firm mc2i in May 2020 (page checked on 5 October 2026); Bonjour RATP, ChatGPT connector page checked on 5 October 2026; Nomad (NOMAD Car network, Normandy), announcement of the NomadCarBot chatbot and of the “next departures” module, 3 November 2025; AuxR’M le bus (Auxerre urban community), WhatsApp chatbot announcement, 28 May 2026; Botnation pricing grid and FAQ, checked on 5 October 2026.
