The combination of cloud technologies and the Software-as-a-Service (SaaS) approach have revolutionized pretty much every industry in the world. The change from software being something you buy and run has shifted with the realization that it is never a “finished product,” turning traditional business models on their heads while also leading to huge efficiency and cost gains and, most importantly, a quantum leap in the service offered to end consumers.
While not in the first wave of adopters, this shift is now common in the world of fare payments, with more and more agencies around the world making use of this approach.
Traditional systems that were procured to be custom built and then run for decades risk looking long in the tooth far before their time compared to more innovative and continually developing solutions taking advantage of modern technologies.
At Masabi this has been our ethos from day one — leveraging the benefits of cloud computing and the SaaS model, at first to pioneer the use of mobile ticketing in transit, and then evolving our Justride platform to be the world’s first Fare-Payments-as-a-Service (FPaaS) offering.
The following are 10 questions that agencies should be asking of their fare payment supplier to ensure they are procuring a solution for today and tomorrow — rather than committing themselves to a costly legacy approach.
The answer to this may seem obvious, would you prefer a solution that will continually evolve, adding cutting-edge features and functionality at a lower cost, or would you like to build an expensive bespoke system for your agency which will then be maintained as is until it’s replaced — unless expensive and time-consuming change orders are fulfilled. The benefits of the platform approach are so clear that, outside of a few edge-case exceptions where cities have hundreds of millions of dollars allocated in a short-time frame to spend on a bespoke solution, it’s hard to understand adopting such an approach in this day and age.
(To give you an example. The consultancy firm Consult Hyperion recently launched a White Paper showing how agencies can save between 42-73% on the cost of fare collection by moving to a shared platform solution.)
Hand-in-hand with how a system is deployed is the term length of the contract. For a bespoke approach to make sense for a vendor it requires a significant contract period, typically running to over a decade sometimes two decades. While this is understandable for both parties under this model, the result is vendor lock-in, a monopoly on expensive change orders, and less innovation — which is important in a world in which the cycles of technology development are accelerating rather than slowing down.
Would you be happy using a cell phone from a decade ago? Or even four years ago? This is the danger faced by long-term bespoke contracts. Meanwhile, contracts with more agile and innovative providers can often be shorter, which affords greater accountability and offers a wider choice of suppliers with a better ability to provide market-leading solutions.
Again, if technology isn’t evolving, it's stagnating, and you’re missing out on innovations and new features. It is hard to predict quite how the world will look in five to ten years’ time, and there is the risk that a system built today with no upgrades will look obsolete. There’s also the mundane but essential requirement to keep every part of the system continuously patched with the latest security updates to avoid hacking. It is important to ask your vendor how often they upgrade and what their development roadmap is for the next 12 months, including if and how they charge for those upgrades. Additionally, it’s also worth understanding what their longer-term strategic vision is for the next 18 to 24 months and beyond.
(To give you an example. Masabi's Justride platform updates around 4 times a day on average that's around 1000 free updates a year.)
The introduction of mobile ticketing and journey planning apps has totally changed how riders plan, pay for, and undertake journeys. While agencies should rightly have their own branded apps if they choose, to deliver the best possible experience to as many riders as possible in a convenient way it’s also hugely valuable when fare payments and ticketing are supported across the broadest possible ecosystem of app partners to make tickets available in applications riders already use.
It's also important that agencies get a choice of front-end application, instead of being locked into the vendor's preferred app. Agencies know their riders best and should have the choice.
(For Example. At Masabi we have pioneered an open approach through our work alongside partners such as Transit, Uber, Moovit, Lyft and Jorudan, giving access to tickets to large existing user bases of passengers quickly and cost-effectively. Agencies can choose Masabi's agency-branded app, build their own custom app and integrate ticketing using the Justride SDK, or select their preferred 3rd-party application.)
It seems strange to think that a custom code system built for an agency is a consideration beyond a few unique integrations or edge cases. A simple analogy would be your corporate email. Would you like the software to be developed bespoke for your company with the overhead of having a specific engineer write code for only your organization and then must update the system every time there is a patch or security update, or would you rather use Gmail and simply receive all updates and security patches included, that all users get pushed from Google? Do you want responsibility for identifying and solving outages, or do you want to make it someone else’s problem via an SLA? When a system is built it comes with inherent build and system update risks that are impossible to avoid. However, once functionality is built on a platform, it’s then ready to configure and deploy which is significantly less risky, and quicker to deploy, with updates and security managed for you.
If you want to find out the full details of how a fare collection deployment has gone, there is nobody better to speak to than the vendor's existing agency customers. And importantly at an agency that is similar in size and scope to your own. Customers should be some of a vendor’s strongest advocates, and why wouldn’t they be happy to put potential clients in touch with them to learn more about what it’s like to work with them and deploy their solutions? It’s also important to understand the depth and breadth of a provider's customer base when selecting a platform to ensure that it has gone through any growing pains and is robust and reliable.
(For Example. On our 'Why Choose Justride' page you can watch two videos from both EZfare agencies and Denver RTD on Masabi and our work together.)
Closely linked to the partner ecosystem and delivering a best-in-class service to riders is the level of openness in the system or platform you select. If the vendor offers an open approach with proven APIs, then we think this is going to help set up agencies for success in the delivery of new innovations and best-in-class services, as well as reducing lock-in.
Almost as important as customers are the partners a fare payment supplier has. By working with an ecosystem of best-in-class partners, you can deliver the best services to riders instead of having to use potentially subpar services from a single vendor. It’s important to understand a vendor's partner ecosystem and where their services are live.
You want to hire the best company for the job, whether that be a SaaS business or a bespoke developer, who will build and maintain a dedicated system for a specific customer. It's hard for a company to ride two horses in this race as the skills, expertise, and ethos from SaaS business must be both part of your technical and your business DNA, as the whole approach and business model is completely different.
While some vendors are attempting to deliver both, the reality is that it’s likely that they will be less effective when attempting to shift from their core area of expertise and are papering over a lot of old repurposed legacy tech under the hood — or worse, could bring incompatible business or technical decisions into the SaaS world.
It's crucial when selecting your supplier that they are Account-Based Ticketing (ABT) specialists, as that's the type of solution most agencies and operators are deploying. We won't go into Account-Based Ticketing here, but an understanding of where they have deployed ABT and their capabilities is crucial.
It’s also important to look at the team which will be developing your product. If you’re opting for a bespoke solution, then it’s important to pick the vendor who has the best experience in delivering custom-developed solutions and has the ethos and structures in place for this. Similarly, if you are looking to adopt an FPaaS platform, it’s important to pick a company with a proven track record at productization and platform experience. The difference between the two is such that it requires a completely different approach, corporate culture and ethos that is very difficult for vendors to switch between.
This is only appropriate when selecting a platform, as comparing bespoke systems does not provide a reliable reference, as some may be built and delivered well and others poorly. However, it’s crucial when selecting a platform that the one you select is robust, proven, and reliable. One of the best ways to understand this is by assessing and comparing how many journeys and fares they handle through the system. If the platform is only processing small volumes there may well be productization and growing pains still to endure as the platform develops, stifling innovation and potentially leading to outages.
Interesting in learning about agencies who have adopted a Shared Platform (Fare Payments-as-a-Service approach)? Check out these fare collection case studies.
This article was first published in Metro Magazine.