I imagine the story is a typical one across non-profits. A custom-built Access database resides on an internal server. One dedicated staff member enters information and pulls lists. The lists even have nicknames, like the “A” list.
As long as that staff member is maintaining it, and as long as the queries are working as they should, things are fine.
But then searches stop working. Or that person leaves. Or various copies of the “A” list start to float among staff, and it becomes unclear which is the current list.
My coworkers and I were in this situation two years ago, and I’m sure it is not atypical. The organization’s contact database was becoming harder and harder to query, and the person who created the original database wasn’t available to make the necessary fixes. We had a choice:
- Hire a freelancer to decipher the complex database.
- Utilize the IT firm that managed the network.
- Move the database to a new system, possibly cloud-based.
Cloud computing was certainly on our radar, and we were already there in some respect. Our surveying was in the cloud (Survey Monkey), and we had some document storage in the cloud (Dropbox, Google Docs). These were one-offs, though, not systems.
We decided to try a cloud-based (Software as a Service) system on a trial basis.
We Don’t Own It?
Software as a service is a model where information is stored not on premise (as the Access database was) but rather externally by the vendor and synchronized. Adobe received a lot of press (and grief from customers) when it moved to a cloud-based subscription model: instead of owning a piece of software, the customer pays monthly for the service. Hosting the data and maintaining the application is covered in the cost.
Which brings up the first change in process: cost.
Email list management systems have a few pricing models: one is paying by volume of emails; another is assessed by the size of the database. Since we didn’t contact those in our database more than a few times a quarter, we decided that the model of paying for the number of contacts in the database would best serve our needs. Clearly this is going to vary by organization, and it’s certainly a big change from owning something outright, which means having periods of time where there are no maintenance costs on it at all. However, the costs associated with a cloud solution are predictable and controllable—a fixed monthly fee with opt-in opportunities for additional functionality.
Another shift, and one that is always part of the cloud computing discussion, is security. There will always, always, always be those who ask:
Is Our Data Secure?
It’s a valid question. No one wants to have to notify constituents of a data breech. In this case, neither financial nor other sensitive information was being stored. Also, the ability to download the data easily in order to have it stored locally on our own server as a backup eased concerns.
Moving to a cloud-based system forces the question of data accessibility—while you’ll be able to access the data across multiple devices, will the data always be accessible when you need it? Will the vendor perform maintenance and consequently lock users out of the system in the meantime? It’s definitely possible (although not likely) that system maintenance could affect workflow; we actually had more downtime from internal server issues than from information on the cloud not being accessible.
Customization: Will It Look the Way We Want It?
When the switch to the new list management system was made, there were tradeoffs on customization. There were some tweaks we could make via the cascading style sheet (CSS) on our website and on the vendor’s; however, it still didn’t quite look “seamless.” It was a trade-off, for sure. Our move to the cloud happened two years ago. This issue of customization, in my opinion, is becoming less and less important, as the prevalence of third party vendors makes it less crucial as it once was to provide an experience that appears to be all on one site (eg. EventBrite).
By moving to the cloud, we gained efficiency in list management and the ability for the end users to maintain their own information and contact preferences. It opened up new possibilities by way of segmentation, allowing constituents to pick which lists they wanted to be a member of (instead of being assigned by a staff member or getting every mailing, as before).
Segmentation is no longer the realm of B2B marketing strategy. According to this recent article, almost 80 percent of nonprofit marketers/fundraisers employ it now, as well. While segmenting and targeting can be done with a server-based system, it is much easier to allow users to self-select into lists, self-manage content and contact preferences, and leave storage and maintenance to a third party cloud-based solution.
Additional benefits from the move included the following:
- Access to analytics previously unavailable (open rate, bounce rate, reason for non-delivery).
- Increased efficiency (less time to update the database).
- Ability to have multiple contributors vs. one person making updates.
- Platform independence (desktop, mobile).
Moving to a more efficient system let us grow our list in areas that we simply couldn’t do in our previous set-up. By using targeted “calls to action” on certain pages of the site catering to different audiences, we could respond better and be more relevant to recipients.
Bottom line: while there was a monthly cost involved with moving to a cloud-based system, it saved time overall and proved to be more reliable than the failing database.