Recently, I have had a spate of calendar issues from various sources and of various types. Some calendar entries are given the wrong time zone, others show up on one device but not another, and some have no email capability embedded. All of these issues occur when various calendar services are used by those sending me events (e.g., Google Calendar, Outlook 365, or local services such as ownCloud and others). When you consider the SaaS you use for calendars, contacts, and the like, do you think about potential problems and how to avoid them? Try as I might, the solution to the calendar issue does not seem forthcoming. I live off my calendar; I am sure others do as well. So, how can we fix this issue? Is there a service out there that is always correct?

The answer to that question is “No.” There is no service out there that is 100% technically correct. Why? Because the major factor influencing calendars and contacts is the people who enter the events and information, and humans make mistakes. The technology exists to handle all of the above calendar issues and more, yet the primary issue is one of people and process more than anything else. Happily, there are other SaaS solutions in which the people and process must be clearly defined. Let us take my calendar problem as an example—how can we solve each of these issues?

  • Calendar Sync from tablets and smartphones to cloud services only works if you can reach the network. The technical solution is to always have a network connection using any number of networking functions: VPNs, LTE, 4G, Ethernet, Wi-Fi, etc. However, there is no way to sync when the network is not available, such as when you are on a plane or the device is out of battery. People need to be educated on how to properly use these networks, to constantly look at battery life, etc. Yet, even if extended batteries or MiFis are in use, there still is a good chance that the connection to the network may not always be available. Therefore, it is important to put processes in place to handle such an eventuality.
  • Calendar Sync only works if the calendar application is running, but there are a number of times when it is not. When we return from traveling, we may just plug in the device to charge it but never open up the application to perform the sync. Once more, this requires a people and process solution. We need to train ourselves to do the right thing. Perhaps there could be a technological solution—such as that as soon as we detect power we could start the sync process—but in general, if the device is off, the network is not available, so we are back to people and process.
  • Calendar entries are given the wrong time zone. There are multiple ways to create calendar events, but the one that messes me up the most are those that do not have a time zone specified. When this happens, the time zone of the client is used instead of that of the SaaS or event creator. This means that an event that was supposed to reflect the eastern time zone ends up with my central time zone, which is –1 hour different, yet shows up +1 hour in the future. Our clients should never use “no timezone,” so neither should our SaaS apps. However, they do, and it is up to the people to ensure that this does not happen. Once more, we are at a people and process solution to ensure that the time zone of an event is correct.
  • CalDAV servers have email issues. The most prevalent calendar server is one that uses CalDAV. Any server you use must be able to send email; however, is that really the servers’ responsibility, or the clients’? Once more, confusion abounds, and we return to people and process. If your client and server combination does not support sending email appropriately (as for anything based on SabreDAV as of this writing), it is once more a people and process issue to ensure that the appropriate parties are notified that you have accepted an event or sent an event.

Some of these issues I hope to see fixed in code (technical response), but what it boils down to is that many SaaS solutions (calendars are just an example) need people and process to keep them properly in sync and available to the users. This translates into educating the people and developing a process to ensure the SaaS is doing what you want. The process component works around any technical limitations within the SaaS that may exist. The education component ensures the people have the skills they need to be successful.
Technology can only go so far. Eventually, we have to depend on people and specifically the processes they will follow. What SaaS have you encountered that needs people to be educated about it and surrounding usage and security concerns and needs to have a process developed to work around its issues for your organization?

One reply on “When SaaS Goes Awry”

  1. Love this post because it’s true. The technology only goes so far. At some point, you need the human factor to be considered. At some point, IT has to step up and run itself as a business. Those companies that fail to do this will see more slipups and snafus going on with the cloud-based services they provide on premises and from the public cloud. There’s a great CIO.com/VMware/EMC e-book that looks at the extent of the different priorities and perceptions between business executives and IT leadership.
    It’s pretty clear that not only must IT become more efficient producers, business people become more intelligent consumers so issues and mistakes happen less frequently.
    –KB

Comments are closed.