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.
In this article we’re going to plan an example payment kiosk workflow which can be easily adapted to fit your specific requirements. If you’re designing your first payment kiosk, this is a good starting point.
A kiosk workflow is simply an outline of the screens your customers will encounter while using your kiosk. This is a quick and easy way to get your ideas “down on paper”.
By the end of this article you’re going to end up with an easy to understand payment kiosk workflow which you can share with your designers to create user stories and wireframes.
Steps for creating a kiosk workflow…
List the all the kiosk features
Separate features into MVP Kiosk features (initial release) and Rev 2 features (subsequent releases).
You’re probably reading this article because you’ve decided to create a website which needs to accept cash payments, but also needs to dispense change in whole bills. Maybe your website is running on a self-service kiosk or unattended payment solution.
Does your system have too much downtime and you don’t even know it? Are your customers running away to your competitors without your knowledge?
The answer may be YES if your system experiences regular downtime and worst of all you may not even be aware of the extent of the damage until your reputation has been irreparably tarnished.
The term ‘downtime’ derives from when a system, combination of systems, or any application or service is unable to perform a desired operation. Downtime can be expected and scheduled, such as planned maintenance, or it can be an unintended interruption of service such as a server overload or device failure.
This article is intended to help broaden your thinking about the costs and types of system downtime.
You’re probably reading this article because you’ve decided to create a website which needs to accept cash payments. Maybe your website is running on a self-service kiosk or tablet and is attached to an MEI bill acceptor.
You’re probably reading this article because you’ve decided to put your website on a self-service kiosk or tablet. Rather than requiring your customers to enter all of their payment information, it makes more sense to have them swipe their credit card and process the transaction like a POS.
This also results in lower fees from the credit card processor, which is always a big plus.
This example also processes the payment via Authorize.Net, which you can optionally substitute for your own payment gateway. Please contact us if you want help substituting a different payment gateway.
I’m guessing you’re reading this article because you’ve decided to place your Ecommerce website on a self-service kiosk and want to save time with data entry when processing payments.
Now that you’ve decided to dispense cash from your kiosk with a bill recycler I want to make you aware of the pitfalls to avoid. Dispensing cash can be invaluable for making change to your customers like a human cashier, but also introduces several new challenges which we’ll address in this article.
Most people familiar with bill acceptors think of a bill recycler as simply an add-on component which dispenses cash, but this is far from the case.
Dispensing bills greatly increases the complexity of the device and the logic required by your kiosk application in order to gracefully complete a cash transaction.