On-Street Revenue Control The Best Ways to Keep From Being Fired By Brandy Stanley
I hope I don’t screw up my first shot at being a published profes-
sional. Actually, that’s what I think a lot of the time when I’m trying to figure out how to structure revenue control proce- dures for on-street parking. Remember that article a while back
about a meter technician on the East Coast who got caught with about $275,000 in coins from the old-style sin- gle-space meters? I thought, “I’m glad that wasn’t my operation!”
ing entire meter system: $0. My job: Safe! Next, do your best to make sure the
meters you are using know how much money they contain and force a down- load or other report, receipt, etc., when- ever the vaults are removed. That way, someone other than the collector knows a meter has been collected and how much money should be in it. If your meters can’t support that,
don’t sigh and say, “Oh, well, I’ll just have to hope.” (Remember e-locks? They work on old meters, too.) Rotate crews through
Meters: 2, Thief: 0. Expense of rekeying entire meter system: $0. My job: Safe!
Then I got called to the mayor’s
office. I was informed that pay-and-dis- play meters were bad and the old single- pace meters were good because look what happened with the meter technician and all that money stolen. Huh? So how do you avoid being fired,
jailed or forced to resign because of on- street revenue disappearance? Think about investing in electronic
locks or e-locks. The keys to these locks must be programmed for a certain meter, day and time frame to allow access to the meters. Designated individuals (not the ones actually collecting the meters, mind you) are in charge of the programming, downloading and uploading of the keys after use. There are a reporting trail, accountability, segregation of duties – what’s not to like? It also can allow you to combine meter technicians and meter col- lectors into one job description. While e-locks may be a bit pricey,
they can easily pay for themselves. We ordered them for our P-and-D meters. Then someone broke into the van and stole the keys (the meter techs had forgot- ten to take them out of the van that night). The offender promptly went to several meters and attempted to get into the coin vaults. Because the e-locks hadn’t been programmed, he finally gave up and took a cinderblock after a few of them. He gave up on that, too. Meters: 2, Thief: 0. Expense of rekey-
20
collection routes so you don’t have one crew on the same route all the time. You’ll be able to track revenues over time and see if any differ- ences follow specific employ- ees or patterns. Spot-check occupancy by conducting car counts in small
areas; do a surprise collection and see if the revenues pass the “sanity check” based on the occupancy. Reconcile your meter system reports
to bank deposits and credit card state- ments on a daily basis. We forgot to do this for our garage and found that the credit card transactions were being buffered in a lane device. Imagine what happened when we
fixed the problem and about 50 people got charged for four months of daily parking all at once. Oops. Then imagine how things would go if it were a 5,000- space meter operation processing 1.5 mil- lion transactions a year. You think 50 people was challenging? That’s not “oops”; that’s where firing, jail and resignation kick in.
Checklist:
Invest in e-locks. Have meters that provide reports. Rotate collection crews. Spot-check occupancy in small areas. Do a spot-check collection. Have real-time credit card processing. Reconcile bank deposits every day. Investigate discrepancies; call manufacturer to fix counters. Don’t always believe the bank’s counters. – Brandy Stanley
Parking Today
www.parkingtoday.com
Brandy Stanley was head of parking in Manchester, New Hampshire until this past winter when for some strange reason she elected to take a similar position in Las Vegas, NV.
How about batch vs. real-time credit
card processing? Real-time processing is usually more expensive in communica- tions costs, but it makes the above men- tioned reconciliation possible. We tried batch first, and it was
impossible to reconcile. The meter system we used kept the rejected transactions in a queue and resent them to the processor every day. Inevitably, some of those trans- actions would be processed, resulting in an actual deposit that did not match the revenue generated on the date being rec- onciled. We might have reconciled it if we wanted to comb through 500,000 transac- tions, but we took the easy way out and switched to real-time processing.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56