You took the progressive approach and switched to a cloud-based POS. You are excited about the reduced costs over a traditional POS platform and thrilled that most of the technology support is being handled by IT professionals in a datacenter rather than by your folks in the retail location. Your operations partners are applauding you for delivering more features for less cost. Things go well for a few months. Then your retail processes change slightly, thereby requiring a POS change.
The cloud POS provider regretfully informs you that the change is too specific to your needs and will not benefit its other customers, so the company has declined your request. Indignant over such a blatant disregard of your needs, you pull out your checkbook, explain the change is important and say it needs to be implemented quickly. But, once again, the cloud POS provider says it's sorry and does not intend to build that functionality into its code base.
The same operations partners who were singing your praises for such a great move just a few short months ago are now calling for your head, because they are unable to operate their business the way they want to.
You do your best to explain how you are sharing the same system with dozens or hundreds of other customers, but they could really care less. They say that if they had known this was a possibility, they would have never chosen this vendor. You try to explain that the problem is inherent to the business model and not necessarily the particular vendor. They mumble something about needing a shovel and a pair of boots as they storm out of the room.
Now what do you do? You've already moved a significant number of locations to this provider. A complete about-face looks like a horrible decision. Although the entire senior leadership embraced the decision at the end of the RFP cycle a few months ago, you are now standing alone when it comes to taking responsibility for this fiasco.
In almost every scenario where I have looked at a less expensive POS approach, there is almost always a functionality trade-off over its more expensive counterparts. Explaining that certain functional requirements drive costs is much easier when you are in the RFP stage and looking at what the market has to offer. But when you have already selected a vendor and the requirements change, that is a whole different ballgame.Managing new requirements with POS vendors is not a new problem for retailers. I have attended many sessions where I put in my "votes" about which features and functionality I want added to the system. The success of getting my needs to the top of the list largely depends on how many drinks I bought at the bar the night before. (Maybe I should have started a POS Super PAC?) Even if my requirements make the top of "the list," that doesn't mean they are going to get done in a timely manner.
I've also been in situations where a business need has arisen to change the POS or back office and I have pulled out my checkbook and said, "I want to buy some priority, how fast can you get it done?" only to be told nicely that it will be six to nine months before something is generally available.
But with many cloud-based POS approaches, the problem is made worse, because all customers share the exact same code. A change for one means a change for all. Most traditional POS providers have dozens, if not hundreds, of versions of their code out in the marketplace. They branch out the code to address bugs or customer-specific needs, only to bring it back to the main code base in major releases. It's a pain-in-the-butt way to manage code, but it is a reality that the big POS companies must deal with.
Although I do believe there are advantages to cloud-based POS, it is important that you understand what flexibilities you will have once you go live. Here are some of the questions you should ask your potential cloud provider:
- What is your change management process? When are changes implemented, and how am I notified? Do I have any say in the matter for certain changes? Who can request changes?
- What is your release schedule? Who determines (and by what process) what changes are made to the system?
- What is your roadmap for the product? How can I formally affect changes to that product roadmap
- What is allowed for data access from your system? What is the process for requesting and implementing data access?
- What are the costs for making changes to the system?
Although it's really not going to do you any good (they will skewer you anyway), you need to present the answers to these questions to your business partners, with a frank dialogue about how this approach will work once you go live. They will likely skim over it as they look at the mouth-watering numbers and still look for your head later. But at least you will be able to sleep better knowing that you tried.
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.