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 gaining traction 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. 

1. How do you want the system deployed? Fare Payments as a Service vs Bespoke System

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.

2. Can your prospective supplier work with shorter contracts? 

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, and often longer. 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 supplier with a better ability to provide market-leading solutions. 

3. Will you get constant updates, and what’s the product roadmap?

Again, if technology isn’t evolving its 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 10 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. 

4. One ticketing app or an open ecosystem?

The introduction of apps for mobile ticketing and journey planning has totally changed the way in which 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. At Masabi, for example, we have pioneered this open approach through our work alongside partners such as Transit, Uber, Moovit, and Jorudan. 

5. Configure vs Build. What is your agency's appetite for risk?

It seems strange to think that beyond a few unique integrations or edge cases a custom code systems build for an agency is a consideration. 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 they 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 which 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. 

6. Who are your prospective supplier’s customers, and can you talk to them? 

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. 

7. Do they enable a best-in-class and open approach with proven partnerships?

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. 

8. Does your prospective supplier provide both bespoke systems and platform services?

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 dedicated software 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. 

9. What experience does their team have?

It’s 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 solution, 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.

10.  How many journeys and fares are they processing through their platform?

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.