To answer this question properly some historical context is needed.

The automotive industry underwent a significant change during the last decade. The traditional car industry, consisting of manufacturers and distributors, was challenged by technology companies like Tesla. They removed unnecessary layers and offered a complete package directly to end-users and car-sharing companies (another trend started in the last decade) with a high level of automation.

A similar story happened in the parking industry when it comes to unnecessary layers and automation. Some technology companies disrupted the parking business by digitalizing the value chain, from identification to payment.

While the automotive industry could approach the end-users and car-sharing companies directly, the new technology companies that entered the parking industry faced organizational barriers when they wanted to improve the end-user parking experience and reduce facility owner costs at the same time.

Facility owners are the decision-makers within the parking industry and can be split into two groups. The first group defines parking as not part of the core business and they outsource everything to a parking operator. For the second group, parking is considered one of several elements in which they build their business. The visitors and tenants arriving by car is often the first step in a strategy, for example increased user satisfaction, proptech, big data, loyalty programs or cost reduction. This type of facility owner either has an internal parking department or key persons that creates a contract directly with companies offering parking management systems (PMS). The same group of facility owners often have a separate contract for CCTV-monitoring (distributors of CCTV software) and a separate contract for the traditional cleaning and garbage collection tasks (facility management companies)

It is also worth mentioning there is a separate public parking operator group, usually owned by the municipality, which in addition, often has politically driven goals like: Provide efficient parking to a city’s inhabitants, parking guidance, exact occupancy and increased mobility.

In Scandinavia the arrival of technology companies in the parking industry the last decade disrupted the business and today most public tenders and private facility owners request ALPR and free-flow solutions with app as a payment option. The term smart parking has emerged as a buzzword for such solutions in later years. Like the traditional car manufacturers, the traditional parking operators had the choice of starting all over with clean sheets, trying to add modules to their legacy systems or white-label existing PMSes. PARCS (Parking Access and Revenue Control Systems) is yet another term describing the characteristics of a PMS.

With this history in mind, we can enter the discussion:  What is a Parking Management System (PMS)?

Some vendors claim they have a PMS, because they can interact and enable recurrent payment for pay per use end-users through a mobile app. Other vendors argue they have a PMS because they, in addition to handle pay per use, handle subscription customers in their system. A third group of vendors might also offer a payment kiosk for non-agreement customers on free flow off-street parking, which indicates PMS. A fourth group of vendors will say they deliver PMS, because they in addition offer detection- and identification technology for the people and cars in the roadside. A fifth group will advocate they have the key to a successful PMS, because they also have reset functions in the roadside to calibrate the system manually.

With the components and functionalities textually described above, we are getting close to what is needed to fulfill the requirements in tenders, visually summed up below.

Typical requirements in a Norwegian PMS tender

The rest of this article will evolve around the question; are the decision-makers well-informed about the differences within the PMS vendor group that can tick off all the boxes on the requirement specifications?

We encourage a deeper understanding of overall architecture and the total cost of ownership (hereunder transaction quality, payment consistency and support cases generated), not only the contract price isolated, when such evaluations are performed. We experience that adding fees on app and invoices are elements that can decide who wins the tender. From a technical point of view this configuration option is a microscopical element in what makes up a complete PMS.

In computer science the theoretical perspective of loose couplings and APIs is often recommended in order to focus on the core business. However, based on experience we know that an integration will never be better than what the third party can offer you, and you do not have control over the roadmap and backlog of the third parties. Other risks are the continuous follow-up on contracts and potential hidden costs. From the very start of Sesam we have paid attention to reduce the total cost of ownership by building our own modules. It is more expensive to build your own system, but in return you get better control over risk and operational costs. Which is essential to provide a stable SaaS PMS to Customers. Our System has been developed for approx. 300 000 hours for 10 years. We have finished the first stages all companies wanting to create a PMS from scratch need to go through.

One way to try to explain a complete PMS is to use a computer analogy. We can compare the central system of the PMS with the operating system (Microsoft Windows, Apple iOS, Unix -> Linux -> Android), and the roadside system of the PMS with the keyboard and the mouse as input units (ALPR/RFID/Lane Controllers) and screen and printer as output units (Dashboards/Variable message signs (VMSes)). Drivers, adapters, graphics cards, network cards are the infrastructure part of the system. The important point here is that complete PMS vendors have created all crucial software (SW) components themselves, including infrastructure and edge equipment, since the interoperability and standards in the parking industry are not that well-defined as in the consumer computer industry. This means that information flow, configuration and monitoring are delivered with higher quality than the vendors shopping third-party software.

As an example Hi! develops a unique counting system, partly funded by the research council of Norway. We have experts all the way across the value chain; from detection unit level (Laser, Video, loops) to IO controller unit, to Central System, to output units like web and VMS. It is internal SW and configuration skills that improve the overall quality of this sub-system in the PMS, and it is a continuous process.

It is not that Hi! is unable to integrate towards third-party solutions, in fact we have around 30 of them in production, but we want to have control over the core business ourselves. Hi! customers should not have to bother with integration issues or deal with the handling of several providers, like CRM or ERP. Our Service as a Software portal contains all core modules, specially designed for parking/ITS. The same principles go for roadside equipment. Some companies integrate/outsource this part but for us it is essential to have control all the way out to where the events take place, actually often it is our SW that creates the events. We control the process A to Z.

An analogy for understanding the transaction flow life cycle is to look to the oil and gas industry. 1) we explore, i.e. R&D and contracts, 2 we drill, i.e. we make sure we have the right equipment and the optimal physical installation. 3) we move the raw materials, i.e. metadata over VPN 4) we refine and purify the raw materials, i.e. we improve the quality of the transactions/visits with logic inside the central system 5) we distribute, i.e. the agreement of the end-users decides what happens. 6) we sell, i.e. if the end-user has a pay per use agreement he or she will be charged (much like a traditional gas station).

An advantage of having such a defined transaction flow is that we can add a new input device to the system, with low effort and high effect, as the agreements and payment channels already are established.

At the end of the day, it is all about making sure a visit and a payment is complete and traceable. A visit can be performed over multiple physical facilities with certain discount rules that can be partly paid on several payment channels, and a key evaluation point should be how to make the end-user and the support team understand what happened in complicated cases. The most advanced PMSes even handle schedules.

In November 2021 the system has 31 combinations of payment methods, where the secret sauce is how the domain-driven architecture enables edge-case combinations of transactions, visits, agreements, and payment channels to be handled properly.

Combinations of payment methods

It might be tempting to try to sum up this article by defining what a complete PMS is in a few sentences.

A more fruitful approach will be to suggest some characteristics:

• Hierarchy of agreements
  • Ability to handle agreement types on the fly on entry
    • Open barriers
    • Information on app/web
    • Information on VMS
• Architecture that balances edge and cloud
• Well-defined technical interfaces for integrations
• Full control over software (both roadside, communication and central system)
• Splitting of operations monitoring and business monitoring
• Possibility to drill down from overall financial or traffic information to single visits inside a portal
  • From visits drill down to the entry transaction and the exit transaction
• Core modules inside (No third-party vendors)
• Embedded reports inside a portal
• Self-service role-based portal (from facility owner to tenant)
• Off-street (ALPR/RFID)
• Automated end-user actions
• Please add your points by sending us an e-mail