Start-ups and SMEs can bring lots of value to large organisations and TfL is no exception. Through our open data activity, there are over 600 apps in London using TfL data with an incredible 13,700 registered users of our open data. This has generated an economic benefit of up to £130m per year in terms of customer, TfL and city wide value through new businesses being developed by using TfL’s open data.
It’s vital that TfL continues to engage with the app developer community, academics and others through promoting the right challenges, access to the right people and tools, and continually seeking feedback from our open data users. I know we do this through several channels such as the Tech Forum, events and this blog but I’m hoping that we do some more. So, it was great to be involved in two events this weekend:
We are excited to launch our new TfL Oyster app on iOS and Android, which allows customers to top up their Oyster cards, purchase Travelcards and view their journey history. The app was launched last week, and has already received lots of great feedback. We wanted to offer you more insight into how we developed it.
An API – or application programming interface – is a set of subroutine definitions, protocols and tools for building application software¹. We already have a wide range of public APIs, which provide information such as line status, bus status and journey information. To build a mobile application allowing customers access to their Oyster card data through, we needed to write a new API to support this.
Back in March I posted this blog about Nitrous and their accelerator programme, which was focusing on some key transport challenges, and asking for applications to the programme. This short video looks at some of the participants in the accelerator programme, filmed at the event at City Hall on Thursday 22 June, as guests were treated to an evening of presentations and networking.
As you may already know if you’re following this blog, we recently released the TfL TravelBot on Facebook Messenger. If you haven’t read them yet, Steven and Charul’s posts will give you a bit of background. Check out TravelBot here or search for TfL TravelBot in the messenger application. In this post I will explore the reasons for introducing a conversational bot and our learnings around the design of conversation.
Diverse backgrounds, cultures and lifestyles mean that we all use different words to talk about things. This can become frustrating when you’re trying to find something on a website.
In our team, we try to label things in a way that most users will understand, but are well aware of the fact that we will never be able to cater for everyone. This means that some users have to change the way they think to match what they are looking for.
The Blackwall Tunnel (A102) is one of the busiest places on London’s road network. In recent years, journey times have increased and drivers can expect delays to their journey at some times of day. We’ve released this data to the open data community, to enable developers to build the information into their products.
1) The busiest time in the northbound tunnel on a weekday is from 07:00 – 07:30. In heavy traffic conditions, drivers’ journeys could be 15 minutes quicker if they travelled between 06.30-07.00 instead of 07:00 – 07:30.
2) The busiest time in the northbound tunnel on a weekend is from 13.30 – 15.00. In heavy traffic conditions, drivers’ journeys could be 15 minutes quicker if they travelled between 12.00-13.00 instead of 13.30- 15.00.
We have made this data available to the open data community so you can use it to create products which display the busiest times at the tunnel, allowing drivers to choose to travel outside of these periods or create products for planning quicker and more reliable journeys.
Tell us what you think
We encourage the community to provide feedback on our new data sets to help us continue to enhance and improve our open data products. Please let us know your thoughts in the comments section below or on our tech forum.
We recently launched our first ever Chatbot – the “TfL TravelBot” on Facebook, which uses artificial intelligence to help answer customer queries expressed in everyday language. The bot was launched just two weeks ago and we have already received lots of great feedback. We wanted to offer you more insight into the thinking behind the TravelBot, and shed some light on how we developed it.
Why the TfL TravelBot?
Millions of people already use our website to help them get around London, and we’re constantly seeking new channels to make the process even easier. Research indicates that more than half of the world’s population is now online, and more than 50% of those online are active social media users*. Facebook is comfortably the biggest social media platform, and hence we wanted to take the opportunity to provide them with information via their channel of choice.
Instant messaging has emerged as the primary platform for communication these days**. With the advent of digital solutions making it easier to provide conversational platform, we felt it was the right time for us to enter the world of bots. We pride ourselves on being early adopters of technology, and wanted to leverage the potential of existing solutions to come up with a product which is one of the first of its kind in the world of travel.
How was it made?
We designed the logic behind the chatbot and it is hosted in the cloud. Every customer message passes through our logic, and the bot then seeks to deliver the best response. We use artificial intelligence enabled by the machine-learning framework to process the customer messages (Natural Language Processing). It works by understanding intent rather than phrases. Once the message is processed, the bot replies with either a response from our unified API or a friendly retort. The bot is intelligent and has the potential to learn over time.
How does it help?
Apart from being the channel of choice for receiving information, our bot will help the customers in many ways. It will help our customers get the information in the quickest possible time with a 100% response rate. For instance, queries like ‘When is my next bus due?’ can be easily automated, saving customers time and meaning they don’t need to wait for a customer services agent to get a response. In the case of more complex queries, the chatbot can prompt you to speak with an agent.
As a business, this frees up the time of our customer service agents and helps them focus on more complex customer queries. We are also be able to handle many more queries in the same time, therefore improving our response rate.
Over the last few months we’ve received lots of useful feedback on some of the buses-specific features on our website, and we’ve noticed some recurrent themes. We’ve worked hard to act upon your feedback in as short a time as possible, and in this post I’ll address some of your key questions and concerns, as well as what we’ve done about them.