Customers don’t always behave as we would expect when using our kiosks. In the context of software, this is referred to as the “happy path” where everything goes according to plan. 

As kiosk software developers we also must plan for what we’ll refer to as the “sad path.” This is when the customer deviates from the expected behavior.

In this article we’re going to be covering the case where the customer walks away from our kiosk in the middle of their transaction.

Obviously, we don’t want the next customer to continue where the previous customer left off. The new customer needs a fresh start and it would be confusing if they walked up and the kiosk is in the middle of a transaction.

Let’s start by first talking about why customers might abandon their kiosk transaction.

Why do customers abandon their transaction?

The list of reasons could potentially be endless, let’s just cover a few common ones…

• They didn’t find what they were looking for
• They didn’t have enough money to complete the transaction
• The kiosk was too confusing, or the customer gets frustrated
• They got distracted
• The “customer” was just a small child playing with the screen

I could keep going, but you get the point. As developers we need to be prepared for the inevitable case where the customer will abandon their transaction, because life happens.

Can’t we just start over?

The most obvious solution would be to start a timer when the kiosk is idle and if the timer expires we just restart the kiosk workflow by redirecting the customer to the kiosk attract screen. Any time the customer interacts with the kiosk, the kiosk idle timer would get reset.

It would also be a good idea to prompt the user with a dialog asking if they’re still there before restarting the workflow. Something like, “Are you still there? Your order will be cancelled in 30 seconds.”

To put this in layman's terms, if the kiosk is idle for too long, we’ll simply start over. Pretty easy to understand right?

Restarting the kiosk workflow will work fine in most scenarios, but it might not work in every scenario. For example, what if the customer is inserting cash and they’re digging around in their wallet for another bill?

Restarting the kiosk workflow could cause them to “lose their money”, which will result in some pretty pissed off customers. In the next section we’re going to cover what to do when we can’t just start over.

What to do when we can’t just start over

We’ve covered the scenario where we can just restart the kiosk workflow using an idle timeout. Now let’s talk about what to do when starting over is problematic.

Imagine the scenario where our kiosk accepts cash but has no ability to dispense change. Once the customer inserts their cash, there’s no spitting it back out, so we have to move forward.

Now you might ask, “why not just install a cash dispenser?” Well for one, it would raise the cost of our kiosk and for the sake of this example let’s just pretend dispensing cash in not an option.

For our example, let’s assume the customer is paying their cell phone bill at our kiosk and they owe $100. They approach the kiosk, search for their bill and start inserting cash. But when they’ve inserted $80, they realize they don’t have enough cash to complete their transaction.

What should we do in the case where they’ve inserted some of their money, but don’t have enough cash to complete their transaction? Remember, dispensing the cash they’ve already inserted is out of the question because our kiosk doesn’t have a cash dispenser.

In this case, the answer is to give the customer a partial credit.

Giving partial credit

Going back to our cell phone kiosk example, the answer would be to apply the $80 to the customer’s account as a partial credit.

Should we just apply the partial credit and start over using our idle timeout? Eventually yes, but since the customer is inserting cash, we should give them some extra time and fair warning in the form of a popup dialog.

Another consideration is what if the next customer approaches the kiosk before the idle timeout has completed. We wouldn’t want the next customer to be able to go back and search for their own bill and apply the $80 credit.

Therefore, it’s imperative that once cash is inserted, the customer cannot navigate backwards and search for another bill. By locking the credit to the original bill, we ensure that even if the customer walks away, the next customer cannot “steal” their credit.

The worst they can do is either complete the transaction or wait for the idle timer to expire. Either way, the original customer gets the credit.

Final thoughts on the happy path

The temptation as developers is to focus on the happy path and assume that our customers will use the kiosk just as we would. But you can see from this example that’s a pipe dream.

Anytime we’re designing a new feature it’s important to think through what could go wrong (the sad path) and how we might mitigate that.

Keep in mind there’s always a point where self-service is not the answer and you just have to get a person involved. We can maximize the effectiveness of self-service by planning for the worst and thinking ahead.