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.
When you understand the paradigm shifts associated with uniﬁed messaging, you can begin to work on your solution and deployment. To develop your solution, you must understand how to deﬁne and execute the tasks necessary to transition or shift your organization to uniﬁed messaging. Then you must address the technical issues described throughout this book. When developing your solution, it is important to have an excellent understanding of Unity’s capabilities. See the end of this chapter for a brief walkthrough of the different sections in the book, to make sure you understand the importance of each one. Play close attention to the Part II and Part III, “Solutions, Systems Management, and Administration,” so that you can understand how to deploy Unity and also how to manage both it and your subscribers as you move to uniﬁed messaging.
Part II provides you with an in-depth look at how to plan for, design, and implement a Unity solution, regardless of the size of your deployment. Initially, it might seem complicated, but this will be easier when you understand how to identify the tasks associated with deploying Unity under various conﬁgurations.
One of the things you can do to address the seemingly large set of complicated issues is to give yourself an opportunity to openly identify the issues and features that are most important to your end users, regardless of where they are in the organizational structure. Some might frown upon this idea, but you simply cannot expect your end users to easily accept something as different as uniﬁed messaging without involving them in the process. In a nutshell, it is easier for end users to accept the change that any new product brings with it, especially one as capable as Unity, if they can participate in the process.
It is possible to enable end users to participate and still allow them to be productive with their normal duties. Participation does not mean that they should be required to spend every working hour on the project. Aside from being directly involved, end users can participate by attending presentations and demonstrations of the product, by having access to the product in their area so they have a chance to understand what it does and how it does it, or by asking them to ﬁll out surveys or questionnaires on the product’s features and functionality. Other options include creating focus groups or working groups from different departments or divisions that can provide direct input into the product and how it might be used.
Adapting the User Community to Uniﬁed Messaging
So, how do you adapt the user community to uniﬁed messaging? when you involve users in the process, it is easier. You can do a few things to ensure that the end-user community has a chance to adapt to the technology:
Easing in features over time
Being aware of the changes in end-user behavior that might affect the system’s performance (also known as the turnpike effect)
Without a doubt, Unity’s TUI conversation is different than others in the industry—no two conversations are exactly alike. Many of the key presses and conversation statements might be exactly the same or similar, but without including training in your deployment effort, you certainly will have signiﬁcant support overhead. It might not be worth deploying a technology such as uniﬁed messaging if you cannot train your end users on how to be Unity subscribers. Make sure that you provide the necessary training for the end users.
Easing in Features Over Time
It is not necessary to turn on every feature or make every feature available to all end users at the time of deployment. As a matter of fact, you might ﬁnd that doing so overwhelms the end users so much that they will not want to even use the product. Instead, limit the number of features and functionality. For instance, it is not necessary to grant every subscriber TTS access. This can be managed by planning your class of service settings and making sure that some of your class of service groups do not have TTS access available. Another example is the web interface. Although it is functional, it might seem like too much to remember right from the start. Instead, give the subscribers some time to learn how to use the Unity TUI, and then phase in additional features over time. Doing so ensures a more pleasant end-user experience and makes your job easier in the long run. Your help desk will appreciate it as well.
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.