Current PARC system obsolete and generally unreliable.
Service and support inconsistent.
Software updates, version control, and general upkeep.
PCI compliance and liability concerns.
Improve and increase parking products and options to patrons.
Concerns about “future-proofing.”
Costs.
For most parking operations folks considering a new PARC system, the issues and concerns listed above are similar to their situation, so what’s the big deal? The difference in this case was how a solution was crafted, how it would be implemented, how it would be supported, and how it would be paid for.
The process incorporated several distinct steps in which experts met to address their associated tasks in great detail:
Step 1: The crafting of the solution required an in-depth analysis with regard to current operational practices, as well as the operational intentions expressed by ASU for the future. This process included discussions with all relevant constituent departments. Examinations of current and anticipated traffic patterns, current equipment and control island layout, and associated electrical and communication plants were crucial.
During this phase, site visits included facilities, IT, construction and members of the ASU projects team. Meetings with the ASU staff to determine support and service concerns established clear and concise expectations and the different roles that each entity would assume for both initial and extended warranty practices.
Step 2: Meetings with university IT and finance staff provided clarity with regard to their PCI, software support, and general credit card processing and payment concerns. This was exceptionally important to determine responsibility for both current and anticipated compliance needs, as well as confirmation of a plan to address the upcoming EMV requirements.
Included in these meetings were senior parking department staff members.
This was important because one of their primary objectives in considering a new system was the overall reduction of cash processing through the deployment of other payment options as a means to better accommodate a variety of customers, as well as maximize utilization of their facilities.
Operational desires notwithstanding, it had been determined that if at all possible, ASU would not transmit, collect, store or process any credit card transaction in any of their parking facilities. This aspect of the evaluation process was paramount: Unless ASU was removed from the credit card processing ecosystem, the project could not continue.
Step 3: A solution was crafted that should address the operational concerns, implementation concerns, credit card processing concerns, and service and support concerns. However, a component of the solution included the removal of all credit card processing traffic from the ASU network.
To address this, several LTE network segments were incorporated within the solution. This addressed two major concerns: the potential high cost for the installation of a new campus network, and the desire to isolate credit card processing from any existing plant. To confirm the viability of this plan, a consulting team was brought in to evaluate cellular coverage and determine any potential uptime exposure using an LTE network. Their findings confirmed that wireless network topology in those locations was indeed viable.
In providing a separate LTE network owned and managed by someone else, the ASU concerns regarding the transmission of credit card payments within its environment had been addressed. However, the inclusion of the isolated network did not address the processing concerns expressed by ASU. In short, the university wanted to accept credit cards as a form of payment, but did not want any level of merchant responsibility.
Step 4: Several discussions took place in which the overall credit card processing flow was examined. The intention was to isolate ASU from any of the transactional process. It became apparent during this process that the only way to adequately disassociate ASU from the process was to have the vendor become the merchant of record for the credit card transactions associated with the parking operation.
T2 already was an approved Level 1 Service Provider, so it was relatively easy to create a specific merchant account to which all the credit card processing from ASU point-of-sale devices would be routed. In this processing configuration, T2 and not ASU would assume most of the PCI technical compliancy responsibility.
Step 5: The next concern that needed to be addressed was the matter of the head-end environment, life cycle support of that environment, system software implementation, service and support. The current PARC system was obsolete, and supporting the product in-house was challenging. Moving forward, the intention was to off-load as much of the burden as possible from the ASU in-house staff. The result of this analysis was to implement the new PARCS using a hosted environment.
Step 6: It was imperative that regardless of the breadth of the solution, local service and support were required, not just for the initial warranty period, but for an extended period beyond. This would include specific response criteria, technically capable staffing, and appropriate local parts inventory. This was of utmost concern to the ASU parking operations staff.
Up to this point, the overriding goal of the process was to craft a technical solution that addressed the operational needs of ASU. Included in that solution were the components of an isolated network, the off-loading of credit card processing, having the system reside within a hosted environment, and the need to provide effective front-line service.
What had not yet been addressed was the cost for this solution. While ASU did have a limited budget set aside for this project, it became clear once the breadth of the project was clearly defined, that the initial budget was not adequate. All of the other technical, operational, credit card processing, and service issues were addressed.
How to proceed from here?
Utility Model
A very important consideration in the evaluation of the PARC solution was the aspect of service and support (as indicated in Step 6 above). This would need to continue long after the initial warranty. Taking this into account and considering the intent to have the vendor process the credit card transactions, having the system reside in a hosted environment, it was apparent that we would be far more ”embedded” in the actual solution. At that point, why not consider “owning” the solution and simply charging ASU for the use of the solution?
In crafting a long-term plan, we first had to identify an agreed-upon term: in this case, 10 years. We then thoroughly examined the anticipated lifecycle of the system components to make sure the costing included anticipated hardware upkeep. With ASU, we then collaboratively determined servicing needs, uptime requirements, credit card operation fees and remote support.
The result of these efforts was a pricing model that significantly reduced initial cost, allowing Arizona State to realize the entire designed solution within its anticipated initial budget. The pricing model then included “utility fees” that would be absorbed into annual budgeting considerations. Most important, through the use of the Utility Model, T2 retains ownership and therefore responsibility for operational sanctity through the duration of the term.
The model does require a significant level of commitment by both business partners as well as a clear understanding of current and future operational intentions.
The supplier must have the proven technical endurance to ensure ongoing commitment to address evolving business practices with the implementation of new and emerging technologies. The client must have the commitment of senior management to enter into and sustain a long-term business partnership.
If these are in place, the model will work – providing a stable and reliable product for the client to effectively practice its parking management craft, as well as a long-term, profitable business model for the supplier.
Contact Tom Wunk, Vice President of PARCS Solutions at T2 Systems, at twunk@T2systems.com.