Category Archives: Off Topic

Off Topic

Idea for Retail POS Developers

Alright, before we get started here, I know what some of you are thinking… “POS, who are you calling a POS!?”

If you aren’t in the acronym business, and aren’t familiar with the retail world, a POS system in retail is a Point Of Sale system. (Not the more common use of the acronym: Piece Of S#!+)

In retail, the POS system is used for all purchases, returns, price checks, etc. Now on to my point.

When I was looking for my N10, I ran into the issue that, even within the same retailer, there often wasn’t an accurate depiction of stock on the item. I went to one Walmart, and they told me another store had 1 on stock. Luckily, I got there and there was actually 2 there. (I ended up with both eventually… see the story about the N10 replacement for details.)

This got me thinking… I worked in retail for a couple years, and we often had similar issues. Usually it was the other way around though. An item would show available, and it wasn’t there. 90% of the time this meant that there had been a return and the item was “in stock” because it had been returned, but it wasn’t able to be put back on the shelf (Much like my N10) or it just hadn’t been restocked yet, and an employee would have to retrieve it from the Customer Service desk (which is a lot less of an issue, at least it’s available for purchase.)

So, here’s a simple solution: (POS programmers, I hope you’re listening!)
When returning an item, make an option for “restock”. I was thinking on my way in to work… what’s the best way to do this? You could make it a checkbox, but the Customer Service representative (CS rep) will likely ignore that box 90% of the time. As a former CS rep, I know that a lot of what you do is habit, so you will eventually get in the habit of seeing the box, knowing that 90% of items will be restocked, and clicking it. So how do you FORCE the CS rep to interact with it properly? I came up with a few ways:

  • Make that box default to on
    • Unfortunately, that makes it still optional. The user is NOT FORCED to interact with it at all. Although 90% of the time it will be correct even if ignored, habit still kicks in.
  • Make it 2 radio buttons, one for “yes”, one for “no”
    • If no choice is made, cannot move forward, FORCING a click
    • again, habit kicks in. 90% of returns will be restocked, so the clerks will most likely click the “yes” box by habit.
  • Make it a Y/N input
    • This will FORCE the user to put something in the box. If the box is empty, you cannot continue.
I have noticed, in my personal life, that clicking seems to be an easier habit to form than typing. Therefore, the Y/N box seems to be the best implementation in my opinion. You have to type something in the box (unlike the checkbox) and you have to think about what key to press, not just instinctively click a mouse button (unlike the radio button.)
I’ll make this even easier for you, developers, and write some sudo code for you:
If (restock)
{
    add item back into inventory

    //the actual code will likely be something like this:
    //getItem(SKU).addInventory(1);

    //where SKU is obtained by scanning the UPC code or manually entering the SKU number

}
else
{
    mark for RMA

    //something like:
    //getItem(SKU).addRMAFlag(1);
    //or
    //getItem(SKU).setRMAFlag(true);

    //in the back end, this will set a boolean flag for RMA, or add a count of RMAs to that item

}
Now, human error still occurs, and habit is still a possibility. Luckily, there is already a part of that system to take something out of inventory if it has been returned or is otherwise damaged (or whatever) and needs to be returned to the manufacturer. Keep that system around, in case it’s needed, and add a flag for your backroom employees for the RMA procedure. If an item was marked for RMA and is actually able to be restocked…. simple, clear the RMA flag. 
The else statement for “mark for RMA” shouldn’t actually DO the RMA procedure, just mark the item that an RMA needs to be done. Clearing that flag needs to be available anyway. After the RMA is processed, you’ll need to clear the flag. So if an RMA is not actually necessary, you can clear the flag the same way.
This all seems so simple to me, but I have not worked with a POS system to date that had this kind of functionality. I have been out of retail for roughly 10 years, so someone MAY have come up with this already but, as far as I can tell from a customer point of view, this seems to still be an issue.
Go ahead POS developers… steal my idea. Use it. PLEASE. I would LOVE it if you gave me credit somewhere for the idea but, since I’ve made this public, I guess that part is optional. But I am not about to go write my own POS system, so feel free to add this to yours.