لطفا منتظر باشید ...
Improving the User Experience During Migration
This section describes the following two strategies that can be used to improve the user experience during the migration from the Octel voice-mail system to the Unity system in the Sydney location:Export the spoken names of the Sydney users from the Octel system to Unity.Pre-enroll users before bringing the Unity system live into the network.
Export Spoken Names from Octel to Unity
It is possible to transfer the spoken names of the users as used in the Octel system before the migration to Unity. This will improve the experience for the Sydney users when they move to Unity, because each Sydney user's spoken name will already be present when they first connect to their new Unity mailbox, and they will get a spoken name confirmation when addressing messages to other users within the company.For this spoken name confirmation to happen, you need to obtain from the Octel system a list of all the users' mailboxes that are in use. You can get this report from the Octel system administrators. This is a standard monthly report, referred to as the called utilization report, that gives an overview of the active mailboxes for the past period.This report can be obtained or transformed via import/export in Microsoft Excel to a comma-delimited format (CSV). That file can be used as input for a Cisco tool called Cisco Unity Mailbox Import ToolMBUpload.exe. This tool is part of the Cisco Unity Tools Depot and can be accessed from the Unity server by double-clicking the Unity Tools Depot icon on the desktop.This tool allows bulk editing of the Octel node directories on the Cisco Unity Bridge. All the entries created this way are permanent entries on the Unity Bridge and are not subject to name aging, which is inherently present in Avaya's OctelNet protocol. More detailed information can be found on Cisco.com related to this tool:
http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_tech_note09186a008011c805.shtml
You can get the complete list of tools available for Cisco Unity from http://www.ciscounitytools.com/.The Unity Bridge will create all Unity Bridge subscribers by this upload. Because there is no spoken name associated with these Bridge subscribers, the Unity Bridge will launch an administration call to the Octel nodes to retrieve the spoken names and then store them. These spoken names will be populated to the Unity servers accordingly via the Bridgehead server in AD and cached in SQL.It is important to verify that the DTMF-Id is consistent with the designed dial plan for your voice-mail networking and that it matches the expected digit string as it will be known and used by the Sydney users. Changing the DTMF-Ids afterward is a time-consuming activity for all the imported subscribers.To avoid this manual change of DTMF-Ids it is possible to use the Cisco Unity ExternalUserImport utility to create all Bridge subscribers on the Unity Bridgehead server with the corresponding DTMF-id that will be used to address messages by the Sydney users of the Unity system. After the Bridge has retrieved the spoken names, it will send the spoken name to Unity and the spoken name will be linked with the corresponding user. This prevents the administrator from having to manually change all subscribers.
Pre-Enrollment Procedures
It is a good practice to familiarize the Sydney users with their new voice-mail system before the actual cutover date. This has a lot of advantages. For the users, it guarantees a smooth transition to the new system without interruption of their normal work rhythm. For the IT personnel, it helps to avoid support calls and, consequently, escalations on the first day of production. Dealing with user problems during the pre-enrollment, whether real problems or just user-manipulation errors and knowledge gaps, is much easier than dealing with them when the system is in full production and used as a daily business tool.It is also recommended that you give users some sort of training. If classroom training is not practical, you could provide an interactive web tutorial, for example, that allows users to try out the different functionalities. On the first day of production, you can have class-based training for users, at which time they can ask questions. This also benefits people who did not take part in the pre-enrollment. The idea behind this web-based training before the go-live date is obviously that the power users in Sydney recognize that keeping their voice mail going is important and will make the effort to pre-enroll to guarantee a smooth transition. Users who do not recognize the necessity of pre-enrollment are normally those who do not rely on voice mail for their day-to-day job. A special treatment with additional training to explain in more detail the features for power users will be established for VP-level employees and their associated admins working from the Sydney office during the pre-enrollment period.Pre-enrollment also allows the Sydney users to customize their mailbox with their PDLs, personal greeting, and so on. so that when the IT department switches them over on a Friday evening, for example, their greeting is personalized immediately and external (or internal) callers who are forwarded to voice mail won't get a general system greeting telling them that "Extension 1234 is not available." Instead, callers will hear a personalized greeting, or at least the former Octel-retrieved spoken name if the person did not perform pre-enrollment activities.When a partial migration is neededsuppose the Sydney office is migrating in different steps over the course of a few weekendsusers who are migrating to Unity are changed from Bridge subscribers to full Unity subscribers (and thus get an Exchange mailbox assigned) sometime during one weekend (and before their calls are redirected to Unity, obviously). In the case of XYZ, where all Sydney employees are transferred over to Unity all at once, all Bridge subscribers are changed to full Unity subscribers during the cutover weekend.
