Managing Perception Issues When Combining Voice Mail with E-mail - Administration
Unified messaging breaks down the barriers between various forms of communication, such as voice, mail, email, and fax machines. Read on to learn more about the concept and the ways in which this technology has evolved.
Another interesting paradigm to understand is how Unity and uniﬁed messaging affect organizations’ typical perceptions of the differences between legacy voice mail and e-mail. It is often surprising to note that some companies expect and account for e-mail–based service interruptions on a regular basis. It might be scary to think that regular unscheduled e-mail outages are expected, but they are in some organizations.
In contrast, legacy voice messaging is perceived to always be available and isn’t necessarily mission-critical. This seems to be a contradiction, but it might be the result of conditioning: A legacy e-mail system is typically liable to suffer service interruptions, and a legacy voice-messaging system never seems to have them.
One the one hand, for Unity to provide reliable voice messaging for subscribers and outside callers, it must always be available, even though it is not considered mission-critical. On the other hand, when Unity is installed in a messaging environment that is considered mission-critical yet unreliable, just knowing that Unity’s service (normal operations) can be disturbed by an occasionally unavailable e-mail server can be enough to prompt the given company to uninstall the system before it even has a chance to provide uniﬁed messaging services to subscribers and before the company can realize its beneﬁts.
If this is the case, what is the answer? How can Unity be deployed as a uniﬁed messaging solution if the messaging system that it connects to is occasionally unavailable? The answer is twofold. First, the perception must be changed. Reliability for any corporate messaging system (voice or e-mail) is essential to a successful and highly productive organization. So, if there is a concern about whether an electronic-messaging system can support uniﬁed messaging because the electronic-messaging system is unreliable, you must address those unreliability issues ﬁrst. You must achieve the goal of reliability before you introduce Unity and uniﬁed messaging. Second, if achieving reliability in your messaging environment requires a redesign, include uniﬁed messaging requirements from the start. If it requires just a correction of server hardware or OS, or the resolution of messaging application issues, make sure that Unity can operate reliably in this environment. Part II discusses in detail ways to assess and evaluate whether Unity can achieve normal operations with your messaging environment. Naturally, the emphasis on reliability with Unity includes two points:
Ensuring adherence to deployment and design requirements found throughout this book—especially in the deployment section in Part II
* Focusing on a sustainable Unity solution, one where the loss of access to Unity’s dependencies are minimized and Unity servers are placed in failover conﬁgurations
The messaging environment can and should be readied for Unity and should be maintained at that same high state of readiness, even after the product is deployed. In this case, a high state of readiness implies Unity’s capability to maintain normal operations in an ongoing, persistent fashion. When the messaging infrastructure is readied, the next step is to understand Unity’s relationship with and dependencies on this messaging infrastructure. In addition, it is important to understand how service interruptions, planned or unplanned, can affect Unity’s capability to provide acceptable voice-messaging services in the same way as a legacy voice-messaging system that never goes down, as well as to voice-enable e-mail playback over the telephone. Ensuring this ongoing state of readiness is the primary way to prevent or minimize the chances of misperceptions of the product’s reliability.
Back to organizational alignment to support uniﬁed messaging: Another very important argument for organizational alignment (aside from the need for centralized technical expertise) is that, without it, you are guaranteed to experience service interruptions with Unity. Of course, this creates undue perception problems about Unity’s capability to provide reliable services to end users. It is easy enough to ignore Unity’s messaging requirements for subscribers when it is trying to service their voice-messaging requests. Without properly aligning your messaging services, you are guaranteed to face serviceability issues between Unity and the messaging system that it is trying to service. This is another paradigm shift and is a prime justiﬁcation for establishing a centralized messaging team that has both voice and e-mail expertise. One might say that this is the same paradigm shift, but so many technical and organizational issues are driven by these perceptions of uniﬁed messaging—and, in most cases, misperceptions—that they must be identiﬁed individually instead of being considered one in the same paradigm shift. So, because these paradigms are all interrelated, they must all be known, understood, and planned for if uniﬁed messaging is to be successful.
As an example, if your IS or IT organization is not aligned as previously discussed, it may not have all the information that it needs to work efﬁciently. If the e-mail team takes the messaging system out of service without telling the voice-messaging team to prepare for the same outage, you end up with a scheduled e-mail outage and an unscheduled voice-messaging outage. Both outages will affect the same end users, but in different ways. The users will know that the e-mail system will be unavailable during a certain period of time, but they will still expect to retrieve and leave voice messages and will be disappointed when they cannot. So, without the organizational alignment, the end-user community suffers, propagating the perception that uniﬁed messaging is not suitable for its needs.
Another perception issue regarding uniﬁed messaging products in general is the expectation that features and functionality found in some legacy voice-messaging systems will transfer to uniﬁed messaging without any change in the behavior of those features or alteration of their functionality. This might or might not be the case. To address this concern and overcome the perception that this traditional functionality is lost, you absolutely must identify the functionality that is most critical for migrating to uniﬁed messaging. You do this by performing a usage analysis of your existing legacy voice-messaging systems and surveying your end users. In fact, end-user involvement is at the heart of a usage analysis: This analysis cannot be considered valid without end-user input and active participation in the migration to uniﬁed messaging. This usage analysis yields a considerable amount of data on everything you need to do to prepare for your migration. This includes what features of your legacy voice-messaging systems are most important to your end users, as well as a gap analysis between the legacy system and Unity. For more information on performing an end-user usage analysis, see Part II, especially Chapter 8, “Deployment Methodology;” Chapter 9, “Planning;” and Chapter 11, “Designing a Unity Solution.”
An example of legacy voice-messaging functionality that is “lost” when moving to UM is deleting voice messages automatically that are reserved for a short period of time. Some of the most popular legacy voice-messaging systems offer a feature that enables users to store messages for a certain number of days before they are deleted. Subscribers depend upon this feature and use the system with an eye toward the eventual deletion of their stored messages. They know that the messages will be deleted and do not have to worry about maintaining their messages; thus, they do not have to worry about managing the size of the mailbox. This can be considered a nice convenience, but it is sorely lacking in uniﬁed messaging. For example, Unity uses a messaging system, such as Exchange or Domino, as its off-box store; it does not have the type of control necessary to delete old messages that have been left in a subscriber’s e-mail box after a matter of days. Could it have that type of control programmatically through code? Absolutely.
Often an organization puts out an RFP stating that the UM system must delete voice messages after 12 or 14 or 16 days. At the same time, however, the organization does not want a product such as Unity to have that type of automated control over the messaging environment. So, it is possible to automate the management of voice messages in Exchange, for instance, but it is certainly considered too risky to enable Unity or any other uniﬁed messaging product to do this safely and without error. Most e-mail administrators are reluctant to enable any application to sit on top of their e-mail system and manage speciﬁc activities in this way, especially activities that include deleting messages periodically. So, even though it is desirable to have Unity delete messages after a certain number of days—and it would be useful to adhere to it—in the end, it is not practical for Unity have this type of capability within a messaging system, even if it is programmatically possible. Doing so gives Unity the liability for managing its subscribers’ voice messages stored in the e-mail system.
Ease of installation and use are often differentiators between a legacy VM system and a UM system such as Unity. This major difference is the result of two primary reasons. First, most companies do not install their own legacy voice-mail systems. They typically have the maker of the product or one of their service’s partners do the installation. With Unity, you must install it or have a Cisco partner install it. The second difference is that, during the installation operations, uncertainty arises concerning how the product actually should be installed. Unity has the same familiar, seemingly easy-to-use installation interfaces as other software-based products that use Microsoft technologies and APIs. However, you cannot just sit down and install it without having some knowledge of what the product is doing (or, in some cases, signiﬁcant knowledge and access rights to the corporate directory and mail store). Thus, learning about what Unity does or is supposed to do is a key step in the installation process—and it is too often ignored. Do you want to stay out of trouble when installing Unity? Make sure that you know what it is supposed to do. Also do a few dry runs (in a lab) before you actually install it into your environment, regardless of the size of your environment.
This chapter is from Cisco Unity Deployment and Solutions Guide by Todd Stone (Addison-Wesley, 2004, ISBN: 1587051184). Check it out at your favorite bookstore today. Buy this book now.