Evan Schuman's StorefrontBacktalk

In an effort to help the retail technology providers gain traction down this path, I have developed the following guidelines for vendors that are looking to provide “Simple and Cheap” options:

• If a piece of functionality does not deliver at least one percent of quantifiable sales increase or one percent of quantifiable cost decrease, it should be eliminated.
• If the instructions for a piece of functionality take up more than a single page in a 12-point font, it should be eliminated.
• If any process on the system requires more than 5 buttons to be pressed, it should be eliminated.
• If a specific piece of technology has an annual return/repair rate of 15 percent or greater, it should be eliminated.
• If it costs more than 10 percent of the initial purchase price to provide support for a technology on an annual basis (all-in), it should be eliminated.
• If a piece of technology consistently generates more than 5 percent of all help desk calls, it should be eliminated.
• If the customer has more than 100 locations, any centralized service should not be priced on a per-store basis (a personal pet peeve of mine). For example, if there is a central database collecting data from each system and the customer has more than 100 stores, they should not pay $X per store. Instead, they should pay a flat rate for the system.
• If a single person cannot easily manage the menu on more than 5,000 terminals from a central location, it should be eliminated.

If you are a technology provider trying to implement these guidelines, the most important thing to remember is this: If you are unable to meet one or more of these guidelines because of specific customer requirements, you have an obligation to inform the customer about which requirement(s) is causing you to miss the mark.

It is very important that retailers be able to make a business decision to keep or drop a requirement that over-complicates their system. On too many occasions I have had to explain to my business partners that the reason a system is so complex (or expensive) is the result of one requirement that eventually was dropped or deemed no longer important. It may have been critical at the time of design or purchase, but that requirement isn’t important now. And yet the complexity (and costs) remain.

If the provider does a good job disclosing requirements up front, it forces the business to consider how important each requirement is–and if it is worth adding complexity and cost. I have implemented questions into our vendor selection process that now cull out these types of issues, and I feel that it is dramatically improving our requirements and our ability to get something “Simple and Cheap.”

What do you think? Love it or hate it, I’d love to gain some additional perspectives. Leave a comment, or E-mail me at Todd.Michaud@FranchiseIT.org.