How local transport authorities and operators can use AI in bus franchising: six moves

Franchising has handed a local authority three things it hasn’t had before. The revenue, the data and the pen. Here is what a forward-thinking authority now does with what it owns and what a smart operator does from the other side of the desk.

1. Red team your own ITT before you issue it
2. You are buying a data company, so write the data schedule like you are
3. You are now a retailer, with tens of millions in revenue and no model
4. AI-written consultation responses will hit you hard, plan for it
5. Bid against penalties, not the network
6. Automating the argument

The franchising of Liverpool City Region’s St Helens area went live on 6 September. Six regions (Greater Manchester, Liverpool City Region, West Yorkshire, South Yorkshire, West Midlands, Cambridgeshire and Peterborough) are somewhere along the same programme, with the same slide deck circulating around other regions who are undergoing the franchising process.

‘Assessment, Consultation, Scheme, Procurement, Mobilisation’

That deck is about process. This piece is about what you can do now, that you couldn’t do before.

Franchising is ultimately the transfer of three assets to the authority; the revenue, the data and the pen. Plus, the transfer of one thing back to the operator; a contract with a performance regime.

Here, I go deep into how AI can make each of those transfers worth something, right now, this autumn and not in a 2028 strategy.

I have had multiple operators and authorities ask me for practical ideas for AI right now. Shipping tools, not theory. What follows is the accumulation of that.

What the authority now owns

1. Red team your own ITT before you issue it

The authority is now the buyer of the decade’s biggest bus contracts and every ambiguous clause within a contract will be priced with a risk factor against it by the operator.

So, have AI play out five different bidders against the draft ITT and contract. Create a large incumbent AI, a consortium AI, an overseas entrant AI, an SME AI and a municipal AI and have them battle it out. Ask questions, such as: which requirements are unanswerable? Which questions will you want to clarify?

The output will be a list of items that will most likely cost you time and money across every bid. So you can then get it fixed, once, before the ITT is issued.

I estimate it’ll take two or three days of work to craft a red team, build some well-versed agents and test them out. In my view, it’s pre-market work, so it is your own preparation work before issue, not evaluation. But double check it with your procurement leader.

Use AI to de-risk your own ITTs before you issue, it will save more time and money than any other process. I haven’t seen anybody doing it yet!

Remember the key points on AI data confidentiality. Work with your data teams on this before publishing. Run any AI on your own enterprise tenancy, never a consumer chat tool and log it as pre-issue market preparation. I am no lawyer however, so double check everything.

2. You are buying a data company, so write the data schedule like you are

The contract decides who owns the operating data, plus the form it needs to be received in, at what frequency and what will be done with it. As an authority, you hold the pen here and the control.

I have been asked a few times about data and some of the schedules I have seen are structured as if they were prepared in 2010. Monthly reports in PDF format and additional data sent ‘on request’.

As an authority, you want raw ETM, AVL and cEMV data, CCTV metadata, duty, roster and incident data, in all formats. Instantly, hourly, daily. Real-time intervals that allow real-time decision making. Machine readable, by API, owned by the authority, licensed back to the operator. Remember the DPIA elements here, especially around personal data.

Think about what the data will be used for in 2028, 2030 and 2032 and build your data schedule around that. Engage suppliers, gather market intelligence, understand where technology is shifting.

We are building bus contracts for the next decade, right now. The data schedule sits as the substrate for every AI use case listed here and in the future. Missing the point now means you potentially miss the next 10 years.

3. You are now a retailer, with tens of millions in revenue and no model

The model every English scheme has followed so far has the authority taking the fare revenue and the risk, setting fares, routes and timetables. That’s great, but most LTAs have never forecast fare revenue by route, by hour.

As an authority, you have a right to demand data now, ahead of franchising. Transport Act 2000 s.143A (added by the 2017 Act) lets a franchising authority require operators to provide passenger journeys, fares and revenue, mileage, staffing and forecasts, going back up to five years.

The data is fenced, it can only be used for franchising functions and shared with people working with you, not the wider market.

Five years of that data will allow you to train your own AI revenue model before a bus hits the road and model numerous scenarios around it. The technology here is very established. Look at predictions by route, by hour, fare elasticity, event surge, and local weather effects.

I have seen authorities starting from a spreadsheet and a consultant’s ‘forecast’, this cannot be the case. Prepare to run your operations like a modern-day business, not a committee thinking it’s still 2010.

4. AI-written consultation responses will hit you hard, plan for it

We are in 2026 and AI is running away. It now costs a trivial sum to generate tens of thousands of plausible, distinct responses to anything.

As an authority, I suggest you make two moves here.

1. Defend: look to detect synthetic clusters, implement provenance checks, openly publish AI usage policies before any consultation process begins.
2. Absorb: use the same tools in return, triage, cluster and code the genuine responses. Don’t use AI to mark, use it to overcome the manual workload that slows these processes down and often gets handed to consultants on a big day rate.

Assume a flood of AI and build the consultation process around it, value human interaction and openness, then build an analysis pipeline before the first submissions hit.

AI can shorten the analysis, sadly it can’t shorten the calendar.

What the operator now runs

5. Bid against penalties, not the network

An operator’s margin can now live or die on the performance regime, not on the timetable that an operator has analysed and priced thousands of times in the past.

So, use AI to run scenario-based analysis over one year, three years and five years, looking at the KPI elements, reliability scenarios, road network situations, driver availability assumptions.

With this, you are efficiently building a digital twin of the contract. You will be able to see exactly where you could be hit hard, so you can price accordingly.

To take it one level further, I also advise that authorities do the same, on the other side of the coin, to learn whether what they have designed is biddable for an operator and understand where the fear pricing will be.

6. Automating the argument

This is a bit of a wildcard from me, but I really wanted to get the idea out into the ecosystem. I imagine every operational performance contract will carry significant ‘exemptions’. Roadworks, weather, third-party factors. I have seen it before, the monthly spreadsheet and meeting battle over whose fault it is. It genuinely poisons relationships pretty quickly.

So… why not build an AI-executed exemption engine. It can assemble the claim almost instantly, gather evidence from connected systems and feeds and submit it to the authority. The authority receives the claim in a nice format, checks it instantly against a method that’s been agreed, before accepting or rejecting with reasoning.

Most of the data feeds are already published, it needs a rules engine that mirrors the contract’s exemption schedule and an open willingness on both sides to cooperate and make decisions based on the pre-agreed set of rules.

If we want to be bold, the performance elements need to be written as code, with the prose governing. Publish the punctuality calculation, exemption logic and the other elements as code that both sides can run. Live by the rule that if a penalty formula cannot be run by a machine, it isn’t a formula, it’s an opinion.

It will save many manual hours, many arguments and take the poison out of a contract. Overall leading to a better relationship and delivery, which is what we all want.

What I am not interested in (and you shouldn’t be)

• Twelve-month AI strategy. It will be out of date by month three
• Scoring bids by machine. Let’s keep evaluation judgements human
• Chief AI Officer who wants to build a data lake
• AI consultant whose own website isn’t even crawlable by AI

What I am interested in (and you should be)

• Practical AI deliveries that can happen today, with today’s models
• Utilising data the industry already produces
• Openness and communication, with challenge and competition
• Someone to step out and build a network fit for 2030, not just re-implement 2010.

What makes all the suggestions possible

The data schedule is everything and it is what I tell authorities every day. Most focus will go on vehicles, people and depots, which are massively important, of course. But a lot of data scrutiny, data planning and data contracting has been overlooked.

This means that come 2028, the contract may not be fit for purpose, the cost of change grows and the public service is what is negatively impacted.

My overarching, whole argument here is that public transport needs to act like a data company more than ever.

How to make your bus network legible to AI assistants

1. Get your BODS feed perfect. BODS actually scores feed quality, is yours Green?
2. The DfT is running a consultation right now on cancellations and diversions in BODS. Respond and engage with it. It closes on 23 September 2026.
3. AI assistants don’t parse GTFS. They read web pages, or lean on a maps product that ingests GTFS. Everything else comes from your HTML. So, get a plain HTML page per route, with the timetable in a real table, stops listed and fares stated. Mark them up with schema.org’s transit types, so the entity graph is explicit. Check with the view source, not the rendered page.
4. Let bots in and tell them what changed. I checked 100 public transport websites, less than 50% were AI compatible. So, a robots.txt that allows GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot and Google-Extended, plus a sitemap whose lastmod actually changes when a timetable does.
5. Wikipedia and Wikidata are leaned on a lot by assistants for queries such as ‘who runs the buses in X city?’. Franchising is actually making that question harder, as there are now more entities involved in the ‘running’. One consistent brand (Bee Network for example) really helps, plus an Organization schema on the site with a sameAs to Wikidata and a Wikipedia article that’s accurate on the date you go live.
6. Check the AI tools yourself. See the questions people are asking ChatGPT, ask them yourself and see what answers you get. Log and trace the answers to ensure accuracy and update anything that is misleading.

The final challenge

The way the 2027 passenger will interact with you is changing. They will be asking an AI assistant what time the next bus is, not another app. As an authority or an operator, whoever is running the buses, focus on ensuring your timetables, fares, disruptions and network data are machine readable. Ensure your network is explained accurately by ChatGPT. The flipside risks AI hallucination, which kills public trust.

Maybe we will see an AI accuracy KPI in the next franchising contract?

---

Related: AI use cases for UK bus operators: what’s real in 2026 and the Independent Advisor Agent, a prompt you can use to pressure-test any of the ideas above. For the AI transparency rules on the bidding side, see how PPN 017 affects transport bids. For what a franchising authority’s website looks like to an AI, see the invisible industry.