Hayden’s recent article on LinkedIn explains that some USA public transit operators are using loyalty schemes to try to shift customers to their less congested (and often more environmentally friendly) modes of transportation.
But how could such a scheme work in those areas where transportation services are fragmented, deregulated, privatised or just provided by different systems and technologies?
The truth is, that unless there is a common way for each different transport operator to integrate with the accounts of other operators (and at the most basic level of functionality to view some journey and ticketing data)… then a single consolidated view of travel will not be possible.
So how do we create the ability for all accounts to be inter-operable? By the use of open and usable API standards that both:
- Private sector suppliers can adopt over time (although the faster they do this, the more competitive they make their products)
- Public sector organisations & operators embrace and mandate in all future transport tenders or franchises.
We are pleased to announce that we have created and published an initial draft Open Transport Application Programming Interface (API).
This can be found on SwaggerHub here:
The aim with any open standard is to:
- Give it away, so that it can be adopted as widely as possible
- Encourage feedback and suggestions
- Allow it to develop in the same open manner
What problem are we trying to solve?
Well… Providing a self-service digital/online presence is a necessary requirement for any transport solution. Regular customers and visiting tourists alike expect this, plus the amount of understanding & insight that can be gained from a single source of online customer data has multiple benefits for operators and authorities.
However each individual operator/provider: has already implemented, has plans to implement or would like to implement one an online account.
But each online account will be:
- Limited to a single operator or provider
- Different in the type and structure of the data they contain (often predicated by the software system/vendor/developer used)
- Developed just for the single purpose / use cases intended (and not to be extensible or subsequently integrated )
- Implemented with differing terms & conditions around data usage and governance at different times