Auckland Transport is delivering the City Rail Link (CRL), a transformational project that will significantly change how people move through Tāmaki Makaurau. As part of this shift, the wider rail network is also being reshaped, introducing new routes, a loop, altered service patterns, and updated infrastructure. These changes require a complete refresh of the passenger communications ecosystem, including digital departure screens, platform announcements, on-board audio, and on-board information displays.
Purple Shirt was engaged to develop the content strategy for Auckland’s new rail network, ensuring messaging across every touchpoint would be clear, accurate, and timely, no matter how complex the service. With around 20% of AT customers transferring between trains or to bus services, well-timed, contextual messages are essential to improving awareness of connection points and supporting a seamless passenger experience.
Rather than manually scripting thousands of announcements, we saw an opportunity to streamline the process using AI. Our goal was to automate message generation based on a consistent set of rules and data, using templates and variables that could flex as new scenarios were identified. This approach would reduce reliance on manual updates, eliminate the need for code changes when messages changed, and enable faster iteration while we developed the content.
1. Design the database
We designed a relational database to hold all required information: line names, station sequences, platform locations, service changes, points of interest and the messaging syntax itself. This laid the groundwork for accessing and understanding the relationships between objects on the network.
2. Choose your tools
We selected tools that could support both structured data and flexible content generation. Airtable gave us a simple, powerful way to model the rail network and manage relationships between routes, stations, and messages. ChatGPT 4o was used to generate the Airtable scripts that powered the logic for message generation, allowing us to automate complex logic without writing code.
3. Run a proof of concept
We tested the concept using a small, simplified dataset. This initial proof of concept included only a handful of stations and basic routing. The goal was to confirm that we could reliably generate useful messaging using templates and data alone, using ChatGPT 4o generated Airtable scripts.
4. Iterate with increasing complexity
With the foundation in place, we began layering in more advanced use cases. These included:
Each layer of logic was built on the same underlying principles: clean data structure, flexible templates, and script-based generation.
5. Test and retest
Every iteration was tested thoroughly, comparing outputs across dozens of scenarios, identifying edge cases, and adjusting the logic to improve clarity and consistency. We validated that the messages worked across different train lengths, route variations, and service conditions, ensuring that the messaging remained consistent and accurate.
You can write complex scripts even if you cannot write code.
None of the core project team were developers, but we used ChatGPT 4o to generate the Airtable scripts that powered the logic behind the messaging. As the project progressed, our collective understanding of scripting fundamentals grew, alongside the quality and precision of the prompts we were able to give the model. This iterative process allowed us to build increasingly sophisticated scripts, without needing to manually write code.
Understanding basic database design is essential
Defining the right relationships early on, between routes, stations, templates, and messages, meant less rework later.
Manual overrides still have their place
While the majority of announcements were generated automatically using templates and scripts, we quickly realised that not every scenario could be neatly captured through logic alone. In some cases, the effort required to fine-tune the script to cover a rare edge case exceeded the time it would take to make a one-off manual update.
No-code limits
At times, progress stalled because we lacked the technical fluency to debug or structure certain logic efficiently. While we were able to work through most issues with persistence and experimentation, having a stronger foundation in programming would likely have accelerated problem-solving and reduced some of the trial and error. It highlighted the value of cross-functional collaboration, where pairing subject matter expertise with even light technical support could lead to faster progress.
Patience pays off
Testing, debugging, and refining conditional logic takes time. It is easy to miss edge cases, especially when working with dynamic content generation. Many hands make light work!
Templates with variables are your friend
By defining content templates using placeholders for station names, routes, and features, we minimised the number of updates required when something changed. In most cases, updates could be handled entirely within the database.
The result is a system that can generate consistent, human-readable audio, text, and display messaging across the entire CRL and wider Auckland rail network. The messages reflect real operational conditions, and because they are built from data and logic rather than hand-written scripts, they are easier to maintain, faster to update, and have a high degree of accuracy.
As the CRL project continues, we are confident this framework will help Auckland Transport deliver a high quality, passenger-centred experience, developed through the smart use of AI and structured content strategy.
