Unhappy With Your POS System? Take A Peek At Your Last POS RFP. Don't You Feel Bad Now?

Todd Michaud runs Power Thinking Media, which helps retailers and restaurants tackle the convergence of social, mobile and retail technologies. He spent nine years delivering technology solutions to more than 10,000 retail locations as VP of IT for Focus and Director of Retail Technology for Dunkin' Brands.

As retailers—over the years—have asked for POS improvements, vendors have responded by baking changes into the core products. The problem is that the results are now over-burdened with so many options they are a nightmare to use, tragically difficult to support and wallet-emptying to purchase. As a result, I don't know of a single retailer or restaurant company that is currently happy with its POS system. It may be the cost, the support, the features or the complexity of the system, but every retailer I have talked to—for as long as I can remember—wishes that it had something different. What a crazy reality that is.

The problem stems from retailers not knowing what they really want or need, so they ask for everything they can think of. Just for giggles, go pull out the last POS RFP you put together and see what percentage of requirements that were in the RFP are actually in use today. I bet you'd be surprised, especially if it was a long time ago.

Why does it always seem the features that help vendors win the RFP process are the ones that help it get kicked out months or years later? Companies tend to buy based on "bang for their buck," when in reality they should do the opposite: Look for systems with the least amount of things that aren't high priority, because they shouldn't have to pay for what they don't want or need.

(Related Stories: The Sign Of POS Hardware End Times: IBM Sells All Of Its Point Of Sales To Toshiba and With IBM's POS Sale, History Really Does Make A Difference)

No POS salesperson wants to tell a customer that his or her offering doesn't meet a specific requirement. The answer, historically, is always "Yes" or "It can do that if you sign on the line."

"We have 1,000 different reports out-of-the-box" should not be on the marketing slick. It should be hidden with the other dirty secrets like, "Even though we tout this feature, it doesn't really work."

For every item on your RFP that the vendor doesn't provide today, ask yourself if your business really needs functionality that hundreds or even thousands of other companies haven't asked for or that the vendor has decided it is not worth its capital investment to build. Take a long hard look at that requirement and really determine if it is a must-have or a want-to-have. Want-to-haves are the number-one killer of POS implementations.

If your requirement is about a functionality that you hope to have in the future but doesn't exist today, try to gauge the likelihood that the project will actually happen in the next three to five years. Try to take a real, honest assessment of what you actually need for three to five years. How much will your core business really change?I think it is time that POS vendors take a simpler, 37signals approach to software development: Keep it simple. 37signals, which builds project/collaboration software, revels in the fact that it often tells customers no on their enhancement requests. Basecamp, which competes with Microsoft Project, is sold on the fact that it is simple and easy to use. But if Basecamp added all the functionality its customers have asked for over the years, it would no longer be simple and easy to use anymore. So most of the time, Basecamp doesn't do it.

There are three main components to any POS replacement project:

  • New functionality not available with the existing vendor or system.
  • Better, faster or cheaper options than the existing vendor or system.
  • Future functionality will not be available in the existing system.

When it comes to rolling out new functionality, rolling out a new inventory and labor management tool is a recipe for disaster. Rolling out new inventory and labor management processes, supported with a new tool, is the way to go. Although the differences may seem subtle, they are profound. You should never lead a business process change with a technology deployment. Focus on how you are changing the process and how the new tool can help. I've seen millions of dollars wasted and careers trashed trying to go the other way.

If the new POS is not part of a business process change, then it should be better, faster or cheaper than the existing system (or, if you are super lucky, all of the above). If you can't win at the basics (what you do today), you are not going to win at the advanced (what you want to do tomorrow).

When it comes to future projects, you need to make sure you have the ability to grow with your POS solution but not purchase one only for its future capabilities, because many of them will never materialize as business projects.

POS companies, if you are reading this, you should be focusing on how to "modularize" your software. I have worked with a POS solution that had "thousands of configuration variables." That's stupid. Instead, how about you let me buy and implement just the features I want and avoid the headaches of everything I don't.

And I'm not talking about a POS module versus back-office versus loyalty versus loss prevention; I'm talking about features within POS.

If POS companies want their retailers to be successful, identify the retailers' top 5 key performance indicators (KPI) and help them build a solution that focuses on just those items and removes all the other noise. Like I've said before: Make it simpler.

I'm going to speculate that the pressures on hardware being driven by the Android and Apple tablets, coupled with the overly complex and bloated software market, in conjunction with an industry going through consolidation, is why IBM chose to get out of this space. It needed to either invest or divest, and I think that IBM decided to let the market go through this "transformation" on Toshiba's dime.

What do you think? If you disagree (or even, heaven forbid, agree), please comment below or send me a private message. Or check out the Twitter discussion on @todd_michaud.