Automated Kiosks

Project at a Glance 

My assignment was to design and build an automated kiosk for rental cars. This included hardware, software, API, and user interface. The project budget was $50,000 and it took me a year to complete. Tools used included Mzero, TSD, TeamViewer, Google Docs, Flexmap, JSON, GoToMeeting, StackEdit, and whiteboards. Skills used included project management, team management, user flows, code editing, hardware design, team reports, SOWs, API, CSS, XML, and XSL.

Project Summary 

After my success designing the business model for Zootly, the principals at Edge created a new position for me as Head of Research and Development. One of my many assignments was to build an automated rental kiosk for one of our companies, a car rental service. The goal was to have a user perform all the tasks that they normally would at a rental counter. This was deemed the most efficient way for a small to midsize vehicle rental company to compete with the advent of car-sharing models. 

The goal was to locate these kiosks around the city so as to more strategically deploy the large rental fleet without having to pay for brick-and-mortar offices in economically prohibitive neighborhoods throughout New York. 

You can click on each content title to skip to that section. 

Research

I studied kiosks that I admired, particularly those at airport terminals such as Jet Blue, as well as the history of ATMs in all of their various iterations. I also began surveying the landscape of hardware manufacturers across the country that were capable of integrating the necessary components and began taking meetings with four of them.

Simultaneously, I started learning the in-office tasks of the agents who were responsible for actually renting vehicles to customers. I wanted to understand the entire process, including edge cases, until I could do the work myself and fully metabolize every action the machine would need to perform. This included understanding all the legal ins and outs of the rental contracts, damage collision waivers, and documents that would need to be provided to a driver under New York state law. After a period of intensive research, I felt ready to begin designing the process. 

Design

Of the many considerations that went into the planning of this project, from how payments would be processed to the temperature the machines would operate at, were three main categories: Hardware, Software, and Interface. The hardware was the physical machine components, the computer that would be accepting input and ultimately printing out a rental contract. The software involved the way in which the machine would send and receive encrypted data via the Internet to our fleet management system. The interface refers to the website that would be mounted on the machine that would connect the physical components to the backend software and allow the user to enter information.

Before submitting the first SOW, I engaged in a long design phase which typically involved spending entire days alone in room full of whiteboards, drawing all of the necessary exchanges for all of the components and imagining, over and over, any exceptions that might occur during the user experience. 

The photos of these diagrams were taken for my own memory, rather than to be shared, hence the bad resolution. But it's neat to see me figuring out how to create a flow without any training whatsoever, just scribbling away in my office. I see that I was drawing hardware operations in black pen, fleet management operations in blue pen, and platform UI in red pen. Actually, the finished product wasn't too far off from these sketches, but with anything this complex, the devil is in the details, and I can see I couple tiny flaws in these sketches that would cause me major headaches later on. 

Hardware

The fleet management software was designed by TSD. Their company received and sent XML messages from our website, which updated us as to payments, reservations, and the status of all vehicles in the fleet. Much of what we were designing as regards sending and receiving data from remote kiosk had never been attempted by TSD. 

Ultimately, we went with a company called Meridian for the hardware build. The guts of the kiosk were just a computer running Windows with an ELO touchscreen, which was heavy duty enough to last a long time. The computer was connected to the Internet via physical landline. Plugged into the computer via USB ports were five devices; a Honeywell N5600 digital scanner, an MSR213E encrypted credit card swipe, a Signature Gem LCD signature pad by Topaz, a Zebra KR203 thermal printer, and a DPLS switch for the handset phone users could pick up to call for help.
The biggest trick was configuring all of the hardware so that it would fit within the body of the kiosk. Also, when we received the first prototypes, the manufacturer had made the window for the drivers license scanner too small so it cut off the laser and prevented it from getting the entirety of the PDF419. I had to get one of the guys in the repair shop to cut it bigger with a metal saw.

The computer itself received all of the input through a platform mounted on it called MZero, which was programmed by the manufacturer. 

Software

The fleet management software was designed by TSD. Their company received and sent XML messages from our website which updated us as to payments, reservations, and the status of all vehicles in the fleet. Much of what we were designing as regards sending and receiving data from remote kiosk had never been attempted by TSD. 

Interface

The web based platform that would be mounted on the kiosk’s browser was the most complex aspect because it was a bridge between the hardware and the software. The interface had to accept user input from the MZero platform and physical components, send that data to TSD, receive approval or denial XML from TSD and then relay that to both the user and the physical machine. 

Challenges

The challenges presented by this project are too many to fully enumerate here. Due to its sheer complexity, I can honestly say that this was the most frustrating project I’ve ever worked on and it was a very humbling (and enlightening) experience.

I was working on my own without a big enough budget or a team, other than the contracted engineers and programmers who worked for large, off-site companies. Designing a proprietary technology solution of this scale should have been attempted by a large in-house team but that would have come at exorbitant costs. Our relatively little project didn’t have much leverage with our partners.

I should have also realized early on that our website was not equipped to be a successful middleman between the physical machines and the fleet software. Furthermore, there were many obstacles that I didn’t foresee, like the complexity of getting the SIP codes for our office’s phone networks to integrate with the kiosks phones, or realizing that TSD didn’t have API written that could decrypt credit card data and then send a response. Not one of the partners involved had ever attempted something of this scale. 

Results

But it worked! After a year of work, the kiosk could finally run the entirety of the integrated component flow. A customer could walk up to the kiosk, type in their reservation number, scan their valid drivers license (we could tell if it was fake or expired), swipe their credit card, sign the contract signature pad and receive the printed out (and legally binding) rental contract. If they had a question, they could pick up the phone, which automatically rang our customer service. Our fleet management software on the back end received payment and marked the vehicle unit number as unavailable. I even went so far as to design the entire operations plan for a parking lot crew to check the vehicles back in and drop off more units if needed.

But as I finally finished the project and prepared to move to Seattle, the principals switched track, wanting to change the fleet management software for the company which would call for a complete overhaul of the machine’s interface. I still count the kiosks as the most successful failure of which I’ve ever been a part.

Still, it wasn’t a wasted year. I learned how to read and write API, XML, and HTML. I know how to reset a DPLS switch and what an SIP code does. I know exactly what is coded on the back of your drivers license and how credit card information is encrypted. I know how to manage an off-site team, how to deal with programmers and engineers who are more specialized with me, and how to write an ironclad SOW that is almost hilariously specific.

I also now know that if my back is against the wall, I can pull off an impossible project. 

Back to Top