The Three Main Components of a Self-Service Project

The Three Main Components of a Self-Service Project

  • Type: Article
  • Author: Jim Kruper
  • Date: August 2008
  • Download PDF

Has this ever happened to you?

You walk into a store or a business and see on a display counter or lobby desk a dilapidated PC sitting forlornly, unused and unappreciated, only to realize the poor PC is intended to provide self-service? Or perhaps instead it is a beautifully branded specialty kiosk, but with a screen that is either dead, showing the Windows desktop or — having been hacked — is displaying something entirely inappropriate?

Both are classic self-service failures, and I always wonder what circumstances transpired to cause these outcomes. Deep down inside, I also wonder whether the outcome would have been different had I been involved in the project. I like to think the answer is always a resounding “Yes!,” but sometimes it isn’t that simple.

What is clear is that failed self-service projects are, by definition, very public and highly visible disasters for our industry. Everyone who comes into that store or business sees the failure. The self-service market is growing rapidly and is remarkably well-accepted by the general public, so I don’t believe the occasional project failure is overly threatening to the health of the industry. However, I do believe the industry could be even further along its penetration curve if there were more successful projects.

The three-legged stool

There are many ways that a project can fail. Perhaps the most obvious is a poorly designed application. However, I will address two others: Hardware and kiosk system software.

When describing a successful project to a new deployer, I often use the analogy of a three-legged stool. The three legs are the software application, the hardware and the kiosk system software. Without all three legs, the stool will topple.

The software application leg is almost always present because this leg typically is what drove creation of the project in the first place. Without an application, there is no project. It may be a poorly designed application, but at least it exists.

The hardware leg is the physical manifestation of the project and generally takes the form of standard kiosk-industry components and perhaps a company-branded OEM enclosure. Sometimes, but not very often, a standard PC with perhaps a touchscreen display is appropriate. Due to the capital-intensive nature of kiosk hardware, this leg too often is compromised. This can cause the kiosk to be used less than it theoretically could be, or in the worst case, be totally unuseable.

The kiosk system software is the most likely leg to be missing because it generally is invisible to the user, so deployers either think the software is unnecessary or aren’t aware it exists.

What is kiosk system software?

It is a software layer that locks down the computer and prevents users from going places they shouldn’t. It can perform usage logging, which reports how often the application is being used, and remote monitoring, which checks that the kiosk is always up and running without error. In short, it is what ensures the software application is always available to the user. If the deployer develops the project from the perspective of the user, he may miss the need for system software entirely. Or, a deployer may decide he can develop a partial homegrown solution such as using OS system policies to lock down the computer. Sometimes, the software application is developed to also provide kiosk system software functionality; however, that requires very specialized knowledge and experience, and with many self-service applications being browser-based, it is very difficult to combine the two software legs of the stool.

Project on the rebound

We get many desperate phone calls after a project has been deployed. Generally, either the hardware leg or the kiosk system software leg of the stool is missing. Sometimes, both legs are missing. Hardware vendors know that one of two outcomes will occur when the hardware leg is missing: The deployer eventually will find the money to invest in hardware, or the project will be cancelled as a failure. The former is not ideal, but at least the proper hardware eventually is purchased. The latter is the true tragedy because the opportunity has been lost and how long will it be before that organization tries again?

Because the kiosk system software leg is not as capital intensive as hardware, generally as soon as the light bulb turns on in the deployer’s head, the problem is resolved. Unfortunately, sometimes the light bulb never turns on.

A call to action

What can be done? Education will go a long way. Both hardware and software vendors need to ensure that their clients fully understand the need for all three legs of the stool: Application, hardware and system software. I know that I am guilty of occasionally focusing too much on the software aspect of a project, but it isn’t done purposely. Often a deployer will contact me, but they are talking to me for my software expertise. They don’t necessarily want to talk to me about hardware, and sometimes that is where the discussion ends. As an industry, we need to concentrate on keeping the discussion going.

Want more? Here are some related posts:
Kiosk Software: What is it and why do I need it?
Creating a Successful Self-Service Kiosk Project
Kiosk Software Questions