Floral POS/Shop Management Systems – Cloud vs On-Premise

FloristWare is an AIFD Industry Partner and participated in the 2015 Annual Symposium. It’s always a great event, and this year was even more fun than usual because several of our clients were being inducted and it was a pleasure to be able to congratulate them.

The Partner’s Expo, the four-hour trade fair component of the symposium, is always an outstanding opportunity to meet and talk with both existing and prospective clients. Florists have great ideas about what they want to see in the POS systems they use to run their flower shops and this is always a terrific learning opportunity for us.

This year there was one theme that kept coming up in conversations with prospective clients, and that was the “cloud”. Specifically questions about whether FloristWare was a cloud-based POS system.

The cloud concept has been around for years, and florists have been asking about it for the last few. When it started coming up florists almost always said they wanted a cloud-based system. Now that has changed. Now florists are far more likely to start off with “you’re not cloud based, are you?”. Suddenly they don’t want anything to do with the cloud.

How and why did things change so quickly? They tried cloud-based systems, and were tremendously disappointed.

What Are The Limitations of Cloud-Based POS Systems For Florists?

The reality is that most cloud-based systems have severe limitations. Any database application, and a floral POS system is a database application under the hood, involves moving a lot of data back and forth between the client (the machine the florist uses to run their POS) and the server (the machine where the data is stored).

In a cloud solution the server is in a datacenter, almost always hundreds if not thousands of miles away from the flower shop. It will always be slower, orders of magnitude slower, to move data back and forth over the WAN (wide area network, in this case the internet connection that connects the flower shop to the cloud server) than it is over the LAN (the local area network inside the flower store). Cloud-based POS systems for florists will always be slower than locally hosted (on premise) floral POS systems.

This is exacerbated by the fact that software developers and florists generally have very different situations. The people that make POS systems for florists tend to have very good equipment and very fast internet connections. They are often physically close to the data centers where their servers are hosted (it really does make a difference) and in many cases they have their development servers on the premise (because, whatever they tell their clients, they know on-premise is faster, something they value when working on the system themselves).

Add in the fact that developers usually work on small files that are largely empty of real world data (this is always faster, it’s the difference between filing paperwork into a cabinet with ten folders vs. one that has 100,00 plus folders) and you realize something – the people that make POS software for florists are generally developing it in almost ideal conditions.

Contrast that with the typical florist. Most of them are using older equipment with slower connections a long way from data centers. Cloud performance will always be bad for them. To get good performance they need an on-premise POS system that runs fast.

Availability is another issue. In the real world internet connections go down. If you are a florist using an on-premise system it’s an inconvenience – you might lose some functionality until the internet connection is restored, but you are still up and running.

If you are using a cloud based floral POS system and you lose the connection you are effectively shut down. You can’t do anything, and users of cloud-based flower shop POS solutions have experienced this too many times.

If the cloud server goes down it’s even worse. Much worse. Now every single client is offline. Panicking, every single one of those clients tries to contact POS support. The cloud provider, who is hopefully busy trying to resolve the problem, can’t even begin to handle that kind of call volume. All those cloud users are left in the dark, wondering why they can’t reach anyone that can help them.

Degraded performance during peak periods is also a serious issue. Reluctant to increase their costs by adding server capacity cloud providers try and stick with the bare minimum, which means they are really pushing the limit at peak periods like Valentine's Day and Mother's Day.

Under these heavy holiday loads performance starts to degrade. The POS system runs slower and slower, frustrating both the florist and the client. Eventually the florist starts encountering the dreaded timeout error. They lose everything right in the middle of the order and have to start over, much to the chagrin of the customer.

There are other real problems with most cloud-based POS systems. One of the biggest complaints is printing. Cloud-based POS systems generally do not automate printing. This means that after each and every sale the florist has to manually print the receipt (Choose Print, make the selections in the dialog box, click Print again), then the repeat that process for the worksheet, and then again for the enclosure card.

This simply does not work for any serious florist, especially during peak periods like Mother's Day and Valentine's Day. At FloristWare we have always considered printing automation to be absolutely essential. It was a key part of our initial release over ten years ago and we have continued to refine it ever since.

One of the biggest problems with cloud-based POS systems for florists is that they were never really POS systems at all. They started out as flower shop websites, and then the vendors had a thought. They realized that if they could get the florist to enter the order for the customer on their website they could, kinda, sorta, sell it as a POS.

It was a bold claim, and such systems lacked almost all of the features that were standard on real POS systems that were designed and built for retail floral. It worked for a while because of cachet that came with the term “cloud”, but florists are giving up. They have realized that these cloud-based systems will never be adequate for a real florist. The benefits (like being able to easily access the system from outside the store) do not begin to make up for the drawbacks (like the system running slowly in the store where they really need optimal performance, the lack of automated printing.

Now we’re seeing that florists don’t want to hear about the cloud. They’ve tried the cloud and been burned, and they realize that they need an on-premise solution. We’re happy to provide it – a true on-premise POS system for retail florists that does not rely on a connection to the cloud.

A Better Use Of The Cloud

There are great things about the cloud though, and FloristWare continues to use the cloud when it makes sense.

Backups are the single best examples. The problem with local backups is that they are too vulnerable when they are only stored on machines in the store. Why? Because in this situation so many of the things that might imperil the database also imperil all of the backups. For example – if backups are only stored locally in the store then a hardware failure (virus, dead hard disk, etc.), fire, flood, theft, etc. means that all of the backups would be lost alongside the data that was backed up. It’s like having all the eggs in one basket.

But this is where the cloud shines. Saving backups to the cloud, to a secure server in a secure data center, we have true protection. No matter what happens to the hardware in the store, we can restore all of the data from the cloud to new hardware in minutes. And, because the backups take place after hours, they don’t inconvenience the client. FloristWare users can back up to our cloud servers free of charge, or they can back up to a remote destination of their choosing. As always FloristWare is about helping the florist be in control.

The cloud is great when it’s strengths are used in ways that truly help the client. When it’s used because it’s cheaper or easier for the software developer the client suffers.