Reflections on revenue control


Reflections on revenue control

I remember the first time I heard the term “revenue control.” It was in November 1976. I had just started my first “real” job, having recently graduated from university. I was learning about parking control equipment — the term “parking control systems” still being a few years off.
My company had sold a new type of device, called a “fee computer” to a customer in Toronto, and the manufacturer’s engineer (sent to train us and supervise our first installation), kept referring to it as a “revenue control device” while he prepared this marvel of 1970s electronics technology for installation . The phrase “revenue control” was extremely important, I was told, by my mentors. It meant that we were differentiating ourselves from our competition. We were to be “revenue control specialists”, not mere parking equipment salesmen. I remember thinking, “Differentiation is good.”
After three days of programming and training, we were finally ready to deliver the fee computer to the jobsite. Our customer was convinced that this fee computer was going to answer all of his revenue control concerns. After all, this was a “revenue control device” specifically designed for its application by a company specialized in this field. It was not a simple cash register
We reviewed the site and fee computer infrastructure:
* An “arming loop” that limited the cashier to performing transactions only if an automobile was present in the exit lane. This was to prevent the cashier from performing a transaction without a car being present, I was told. I remember thinking arming loops are good because they limit the cashier’s theft opportunities strictly to those times when a customer is leaving the carpark.
* A ticket dispenser (actually we called it a “ticket spitter”, being revenue control specialists), which printed the date and time that the ticket was issued.
* A “differential counter” to count up and down as cars entered and exited the carpark. The “DC” as we called it let the manager know when the carpark was full. Counting is good, I remember thinking, as it takes the guesswork out of the parking manager’s job.
* Parking barriers. One “gate” per lane to ensure accurate count inputs to the DC and to force each customer to take a ticket as they entered and to stop and pay the cashier as they exited.
Finally, we were ready to test the revenue control system. The ticket spitter dispensed tickets. The gates went up and down — without hitting any cars, which I recall thinking was a good thing. The DC added and subtracted.
There was only one small problem. The fee computer kept freezing in mid-transaction. Today we refer to this as “locking up,” but in 1976, we called it “freezing.” And it was annoying, not to mention embarrassing, frustrating…
“Not to worry” the fee computer manufacturer said. “We’ll send our best man to get things sorted out.” And so, a “senior engineer” arrived to sort things out.
After three days we took the fee computer back to our shop. The carpark had to open and it made more sense for the experts to work in a controlled environment. We supplied a cash register at no charge to our customer. This way the carpark could open and nobody would be inconvenienced. Besides it was only going to be a few hours (or perhaps a couple of days) before everything got sorted out.
Back at the shop, the fee computer worked perfectly. Not one frozen transaction. We worked late into the night re-installing it on-site. We tested the fee computer, but again it froze. Two hours later the cash register was back in action.
After three more return visits the customer said that he’d had enough. The cash register would be fine. It didn’t freeze up when a car pulled into the lane. It even had a printed tape that could be used to audit the cashiers. All in all things turned out well for everyone concerned — except the fee computer manufacturer.
Looking back I have to say that my first revenue control experience taught me one particularly important lesson, one that I have kept close at hand for almost three decades, and one that I will share with you now:
Don’t blame the fee computer or its software until you’ve eliminated all of the basic potential sources of trouble — like the arming loop interface.

John Lovell is President of Zeag
North America, headquartered in Toronto. He can be reached at

Article contributed by:
A personal journey by John Lovell
Only show results from:

Recent Articles

Send message to

    We use cookies to monitor our website and support our customers. View our Privacy Policy