Първата стъпка в преминаването към Webex Calling е да се осигури надеждна и сигурна интернет връзка между локалната мрежа и облака Webex.

Тъй като повечето организации се свързват с интернет чрез една или повече защитни стени или устройства за сигурност, от съществено значение е да се потвърди дали необходимите потоци от трафик се поддържат.

Администраторите на мрежи и сигурност трябва да разбират тези потоци от гледна точка на:

• Посока (входяща срещу изходяща)

• Протоколи (Пример - SIP TLS, SRTP, HTTPS)

• Диапазони на IP адре си, използвани от услугите на Webex

• Номера на порт ове, които трябва да бъдат отворени или разрешени.

Това гарантира, че корпоративните защитни стени, NAT устройствата и друга мрежова инфраструктура са правилно конфигурирани, за да отговарят на Webex Calling трафика, като същевременно поддържат корпоративните политики за сигурност.

За информация относно необходимите потоци, включително IP адрес, портове и протоколи, вижте Ре ферентна информация за порт за Webex Calling. Използвайте тази информация, за да конфигурирате защитната стена, прокси сървърите и друга мрежова инфраструктура в съществуващото внедряване, за да активи Webex Calling рате мрежовите потоци.

Децентрализираният интернет пробив от всеки клон или сайт е препоръчителният подход за услуги за сътрудничество в облак катоWebex Calling. Позволявайки на трафика да излезе локално, този модел:

• Намалява закъснението и трептенето на двупосочно пътуване, подобрявайки цялостното качество

• Мащабира се ефективно, тъй като повече потребители и сайтове преминават към Webex Calling

• Работи безпроблемно със SD-WAN, който може динамично да насочва сесиите до най-близката входна точка в облака Webex за оптимална производителност

• Позволява проследяване на местоположението на потребителя въз основа на техния публичен IP адрес, което помага при анализ на медийния път и отстраняване на неизправности.

Освен това организациите трябва да осигурят адекватна интернет честотна лента на всеки сайт. Честотната лента трябва да бъде оразмерена въз основа на очаквания брой едновременни повиквания, избрания кодек (например Opus или G.711), плюс разходи за сигнализация, препредаване и растеж. Това е в съответствие с фазата на подготовка на жизнения цикъл на PPDIO и установява солидна основа за миграция.

Първоначалният подраздел за настройка в рамките на фазата на внедряване на внедряването Webex Calling е основен за създаването на добре структурирана и управляема среда за обаждания в облак. Този етап обхваща важни задачи като създаване на организацията на Control Hub, набавяне и възлагане на лицензи и проверка и претендиране на домейни на вашата компания, за да се гарантира правилното управление и сигурност на потребителите. Освен това той включва предоставяне на лицензни шаблони за автоматизиране на задаването на потребителски лицензи, конфигуриране на еднократно влизане (SSO) за рационализиране на удостоверяването на потребителите и подобряване на сигурността, както и коригиране на настройките на услугите и клиента в съответствие с организационните политики и потребителските нужди. Завършването на тези първоначални дейности за настройка гарантира, че Webex Calling средата е правилно конфигурирана за мащабируемост, сигурност и безпроблемно потребителско изживяване, поставяйки етапа за последващи фази на внедряване и експлоатация.

По време на фазата на изпълнение изпълнението на пилотна миграция представлява критичен етап в ут върждаването на прехода от Unified CM къмWebex Calling. Този пилот включва предоставяне на представителна подгрупа от потребители на едно или повече места в Webex Calling платформата, като се гарантира, че избраната популация отразява различни случаи на използване и организационни роли . Успоредно с миграцията на потребителите, основните услуги за сътрудничество, включително гласова поща, автоматично обслужване, опашки за обаждания и групи за лов, трябва да бъдат прехвърлени към техните Webex Calling еквиваленти, за да се поддържа непрекъснатостта на бизнеса и функционалността на услугите.

Пилотната миграция следва да използва същата комбинация от инструменти, предоставени от Cisco, и помощни програми за миграция на трети страни, които са планирани за по-широкото организационно внедряване, като гарантира, че процесите, работните процеси за автоматизация и точките за интеграция са задълбочено валидирани при представителни условия.

Основните цели на това пилотно внедряване са две: първо, валидиране и усъвърш енстване на процесите на преход от край до край, включително работни потоци за предоставяне на потребители, процедури за мигриране на данни и конфигурации на крайните точки; и второ, цялостно провер яване на функционалността на мигрираните услуги при реални оперативни условия.

Този поетапен подход позволява на екипа на проекта да идентифицира и коригира всички технически или процедурни проблеми в контролирана среда, да събере обратна връзка от потребителите за новата платформа, да оцени ефективността на избраните инструменти за миграция и да установи доверие в методологията за миграция, преди да продължи с по-широко организационно внедряване.

Прозренията, получени по време на тази пилотна фаза, са от решаващо значение за оптимизирането на последващите миграционни вълни и осигуряването на плавен преход, намал ен от риска за цялото предприятие.

За да набавите PSTN услугиWebex Calling, първо изберете опция за PSTN свързаност в контролния център.

Ако дадена организация планира да поддържа хибриден контрол на двойните повиквания (фаза 1 на фигура Phased Calling Transition: Hybrid and Cloud) временно или за неопределено време, тя ще трябва да внедри един или повече локални шлюзове за локални PSTN, за да позволят обаждания между и крайните точки. Webex Calling Unified CM

Ако пълният преход (фаза 2) към облака е крайната цел, включително PSTN, тогава за PSTN ще е необходим или план за повикване на Cisco, или Webex Calling опция Cloud Connect for.

Работете с избрания от вас доставчик, за да поръчате и портирате телефонни номера, преди да ги конфигурирате в Control Hub. Поръчването на телефонни номера или инициирането на поръчки за портове е изискване/възможно само за локални PSTN и Cloud Connect. Webex Calling За плановете за обаждания на Cisco поръчването и портирането се инициират от контролния център веднага след създаването на местоположението и в страни, където е наличен план за обаждания на Cisco. За повече информация относно плановете за обаждания на Cisco виж те Първи стъпки с план овете на Cisco.

Като част от внедряването на PSTN, уверете се, че вашият доставчик е активирал както входящи, така и изходящи PSTN услуги за вашето местоположение. Освен това изпълнявайте тестови повиквания, за да проверите дали повикванията се насочват правилно през избраната от вас PSTN връзка.

Преди да добавите потребители и устройства към тяхWebex Calling, трябва да предоставите местоположения за повикване. За всяко място трябва да се въведе валиден адрес на улица. В САЩ и Канада този адрес е валидиран и използван от платформата за изпращане на информация за местоположението на PIDF-LO за спешни повиквания.

Когато конфигурирате местоположения, които използват локален PSTN, трябва да настроите съответно локалните шлюзове. В програмата Webex Calling трябва да се създадат багажник и група маршрути за всеки локален шлюз и след това групата маршрути се присвоява като избор на PSTN за местоположението. Cisco силно препоръчва винаги да избирате група маршрути като избор на PSTN, тъй като този подход ви позволява лесно да добавяте допълнителни стволове в бъдеще, като поддържате както мащабируемост, така и излишък. Cisco препоръчва също така да се активира поддръжка с двойна идентичност и P-Charge-Info на всеки PSTN багажник, тъй като това опростява идентифицирането на платежната страна за изходящи директни или пренасочени повиквания. Ако вашият доставчик на PSTN използва различно заглавие за фактуриране, можете да копирате информацията от заглав ката P-Charge-Info на локалния шлюз в необходимия заглавък за фактуриране.

За местоположения, които използват Cloud Connect for Webex Calling или Cisco Calling Plan като опция за PSTN, просто изберете съответния избор на PSTN за местоположението по време на настройката. Ако местоположението използва или Cloud Connect for Webex Calling или локален PSTN, ще трябва да добавите телефонните номера, които са били поръчани в предишната стъпка. Номерата могат да бъдат добавени като неактивни, ако не искате да бъдат включени веднага в маршрутизирането на повиквания; можете да активирате тези номера по-късно, когато бъдат присвоени на потребители или функции.

Важно е винаги да задавате основния номер за всяко място. Основният номер може да бъде присвоен или на потребител, или на функция, като например автоматично обслужване. За да активирате гласовата поща на местоположението, не забравяйте да зададете пилотния номер на гласовата поща, известен още като номер на гласовия портал.

Допълнителните настройки за местоположенията за обаждания включват конфигуриране на подробности за спешни повиквания, като номера за аварийно обаждане, опции за уведомяване и подобрени функции за спешни повиквания. Също така трябва да прегледате и коригирате настройките за запис, езиковите предпочитания и конфигурациите на устройството според изискванията за всяко местоположение. Ако организацията ви използва съкратено набиране в мрежата между сайтове със значителни корпоративни числа, не забравяйте да конфигурирате уникален код на сайта за местоположението в настройките за вътрешно набиране. И накрая, ако външното набиране изисква из ходяща цифра за набиране, не забравяйте да го зададете в настройките за външно набиране. Когато е конфигурирана изходяща цифра за набиране, Cisco препоръчва да се активира прилагането на изходящата цифра за набиране, за да се гарантира последователност.

За да се интегрирате с локалния контрол на повикванията, е необходимо да конфигурирате стволове, групи маршрути, корпоративни планове за набиране, както и настройки за местоположение, така и глобални настройки. Започнете с настройването на стволовете и локалните шлюзове, предназначени за взаимно свързване с локалната система за контрол на повикванията; тази стъпка е необходима само ако са необходими специални стволове. Ако съществуващите стволове и групи маршрути са достатъчни за вашето внедряване, те могат да бъдат използвани повторно за локалното взаимно свързване без допълнителна конфигурация.

След като стволовете и групите маршрути са създадени, продължете да създавате плановете за набиране на предприятието и задайте подходящата група маршрути като дестинация за всеки план за набиране. Когато интеграцията включва множество локал ни системи за контрол на повикванията, свързани чрез различни стволове, ще са необходими множество планове за набиране. Важно е да се гарантира, че тези планове за набиране съдържат само моделите, необходими за маршрутизиране на повиквания към локални дестинации.

Ако разгръщането ви изисква поддръжка за неизвестно маршрутизиране на разширения, тази функция трябва да бъде активирана на ниво местоположение. Освен това, когато е активирано маршрутизиране на неизвестно разширение, трябва да посочите максималната неизвестна дължина на разширението в секцията Маршру тизиране на повиквания между Webex Calling и помещ ения в настройките на услугите за повикване в Control Hub. Това осигурява безпроблемно маршрутизиране на повиквания и правилно управление на сценарии за набиране, базирани на разширения, във вашата интегрирана среда.

Когато мигрирате потребители от Unified CM къмWebex Calling, може да не успеете да преместите всички потребители едновременно. Това може да се дължи на множество причини, включително, но не само, броя на сайтовете или потребителите, колко време отнема преходът на даден сайт и/или група потребители едновременно, ограничен ИТ или ресурс на сайта за поддръжка на прозореца за промяна, продължителност на прозореца за промяна, сложност на промяната и т.н.

Когато мигрирате потребители на етапи, е от решаващо значение да определите кои потребители трябва да мигрират заедно в една и съща парти да. Основната цел е да се мигрират потребители заедно, които имат зависимости помежду си за техните услуги и функции за повикване. Искате да се уверите, че всичките им функции за повикване (Пример - Опашки за повиквания) са напълно функционални, Webex Calling както преди включването на преходаUnified CM.

Дори ако прилагате взаимодействие между Unified CM и Webex Calling с локални шлюзове, не можете да разделяте споделени услуги или функции в тази връзка. Затова трябва да идентифицирате зависимостите между потребителите, като разгледате функции като:

• Наблюдение на други потребители, използващи BLF

• В същия лов пилот, опашка за обаждания и т.н.

• Споделени линии

• Използване на вземане на обаждания

• Използване на едни и същи номера за паркиране на повиквания

• Домофон

• Изпълнител/администратор.

Пример за това би бил потребител, който е част от група за Unified CM лов, към която се прехвърляWebex Calling. Този потребител ще премин Webex Calling е към групата Hunt и с всички останали членове на Hunt Group. Следователно след прехода Hunt Group и нейните членове могат успешно да отговарят на обаждания на новата платформа.

Това става по-предизвикателно, когато потребителите са свързани с различни групи потребители за различни услуги и функции за обаждания. Това ще изисква преминаване на повече от една група потребители и една услуга за обаждане Webex Calling едновременно.

Използвайте изхода от инструмента за миграция на контролния център или инструмента на трета страна, който сте използвали във фазата на подготовка, за да определите кои потребители и функции трябва да бъдат групирани заедно. Този изход трябваше да бъде използван за разработването на вашия план за миграция и ще ви даде представа за това как ще групирате потребители и функции, които трябва да се прехвърлят заедно.

Ключовите стъпки при прехвърляне на партида потребители са:

• Идентифициране на потребители за мигриране заедно

• Проверете дали всички потребители са в контролния център

• Проверете всички TN за потребителите, които съществуват в контролния център

• Проверете правилния формат на телефонния номер в директорията

• Уверете се, че шаблонът за лицензиране и настройки за потребител ските групи са настроени правилно

• Проверка или конфигуриране на всички услуги и функции за повикване за групата потребители (преди или по време на прехода според случая)

• В корпоративната директория добавете потребители към група потребители с активирани повик вания

• Инструменти за ливъридж - Инструменти за мигриране на потребители и функции на контролния център и/или инструменти на трети страни

• Деактивиране/изтриване на номера на директория на потребителя/устройството и функции/услуги за повикване след прехода. Unified CM

След мигрирането на група потребители тествайте подмножество от потребителите, за да потвърдите, че вси чките им функции за повикване и услуги работят правилно. Ако функ циите за повикване като опашка за повиквания, групи за лов и т.н. се прехвърлят с групата потребители, тогава тествайте тези услуги за повикване за правилна функционалност.

В Webex Calling работното пространство се отнася до споделено местоположение (като конферентна зала, място за сгъване или горещо бюро), на което могат да бъдат зададени устройства, разширения и потребители. За разлика от традиционните телефони Unifed CM, работните пространства са:

• Ориентиран към местоположението: обвързан с физически пространства.

• Гъвкаво устройство: може да има едно или повече устройства (настолни телефони, табла и др.).

След като работните пространства бъдат идентифицирани като част от прехода къмWebex Calling, те могат да бъдат добавени в Control Hub под Устройства. Всяко работно пространство се нуждае от задаване на устройство и ако вече са включениUnified CM, те трябва да бъдат нулирани или препредоставени за Webex. Webex Callingфункции като гласова поща, пренасочване на повиквания и получаване на повиквания могат да бъдат активирани или деактивирани, а политиките могат да се прилагат за видео разговори, паркиране на повиквания и мобилност, ако е необходимо. Тествайте всяко работно пространство, като извършвате вътрешни и външни повиквания, тествайте видео, конферентни връзки и функции за мобилност . И накрая, уведомете потребителите за всички приложими процеси за устройства и резервации на работното пространство.

За повече информация относно работните пространства в Центъра за управление вижте Работни пространства.

Телефоните, които са регистрирани в момента, Unified CM ще трябва да бъдат мигрирани Webex Calling като част от прехода към облака. За да направите миграцията възможно най-проста с минимален шанс за неуспех, Cisco препоръчва едновременно мигриране на физически сайтове или отдели. Въпреки това, може да се наложи да мигрирате потребители на партиди поради зависимости от функции. Вижте раздела М игриране на потребители на партиди за повече подробности.

Всички Webex Calling поддържани телефони, от които трябва да преминете, Unified CM ще трябва да бъдат конфигурирани Webex Calling като потребител или работно пространство и физическият телефон ще трябва да бъде преконфигуриран, за да се регистрира. Webex Calling В допълнение, телефоните от серията 7800 и 8800 се нуждаят от надстроен фърмуер от корпоративен фърмуер до фърмуер за мултиплатформен телефон (MPP). Този процес включва зареждане на преходен фърмуер преди зареждане на MPP фърмуера, необходим за Webex Calling регистрация. Той също така изисква подходящ лиценз за миграция. Cisco подобри този процес през последните няколко години, за да ви улесни да надстроите вашите телефони с фърмуер на Enterprise до MPP фърмуер. За повече информация относно стъпките за завършване на надстройката на фърмуера вижте Конвер тиране на IP телефони от серията Cisco 7800 и 8800 между Enterprise и MP P фърмуера.

В допълнение към стъпките, описани в тази статия, Control Hub има вграден инструмент, Мигриране на телефона къмWebex Calling, който можете да използвате, за да помогнете за мигрирането на вашите 7800 и 8800 телефони от Enterprise към MPP фърмуера. Този инструмент също ви позволява да добавите телефоните към Control Hub и да ги присвоявате на подходящите потребители или работни пространства. За повече информация относно използването на инструмента вижте Миг риране на телефона.

За всички телефони от серия 9800, регистрирани с горното изискване за миграция Unified CM на фърмуера, не се прилага. Тези телефони работят с PhoneOS, който се поддържа от двете Unified CM иWebex Calling. За да прехвърлите тези телефони към Webex Calling вас, ще трябва да ги добавите къмWebex Calling, да ги присвоите на потребител или работно пространство и след това да нулирате фабричните настройки на телефоните. Последователността за зареждане на PhoneOS за регистрация по-долу показва последователността на зареждане на PhoneOS и как телефонът ще се регистрира, след Webex Calling като бъде добавен към Control Hub, дори ако телефонът все още е включен Unified CM и/или се използват DHCP опции (Пример - 150).

Unified CMподдържа фабрично нулиране на устройства на PhoneOS, за да позволи внедряването на Zero-Touch. Webex Calling Unified CMадминистраторите могат дистанционно да нулират фабричните настройки на телефоните 9800 и 8875 чрез страниците за администриране на CUCM, което елиминира необходимостта от физически достъп до телефоните, за да бъдат включени телефоните. Webex Calling Тази функция се поддържа с пакетите устройства от 9 септември 2025 г.:

• CUCM v15 - Уни фициран мениджър на комуникации версия 15

• CUCM v14 - Уни фициран мениджър на комуникации версия 14.

За повече информация относно процеса на регистрация за серията 9800 вижте Процеса на регистрация .

^{В допълнение към IP телефоните на Cisco може да се изисква предоставяне на други устройства като аналогови телефонни адаптери (ATA), безжични (Wifi, DECT) телефони, видео устройства, гласови шлюзове и устройства и телефони на трети страни.} Много от тези устройства нямат път за надграждане на ф ърмуера като IP телефоните, за да ги прехвърлят от корпоративен фърмуер към облачен фърмуер. Следователно ще предоставите всяко от тези устройства в Control Hub. Някои от тях не могат да бъдат прехвърлени Webex Calling и еквивалентният Webex Calling модел ще трябва да го замени (напр. ATA 191/192) и други ще изискват ръчно пре конфигуриране и/или промени в софтуера.

• Гласови шлюзове - За да мигрирате локалния шлюз, вижте Мигриране на локален шлюз.

  За повече информация за конфигуриране на гласовия шлюз VG400, VG410 или VG420 в контролния център вижте Локален шлюз

• Аналогов телефонен адаптер (ATA) - За да започнете с вашите Cisco ATA 191 и 192, вижте Cisco ATA.

• Wifi безжичен телефон - За да интегрирате безжичен телефон Webex 840 и 860, вижте Интегриране на безжичен телефон Webe x.

• Без@@ жични телефони DECT - За да започнете с новата си серия Cisco IP DECT 6800, вижте Cisco IP DECT.

  За да изградите и управлявате цифрова DECT мрежа в Control Hub вижте Управление на DE CT мрежа

  За повече информация относно Cisco IP DECT 6800 вижте Ръководство за внедряване

• Устрой ^ства и телефони на трети страни - Работете с доставчици на ^трети страни по изискванията за устройство/телефон и процеса на мигрирането или замяната им за поддръжка. Webex Calling

Всички функции за извикване, които са необходими, Webex Calling трябва да бъдат предоставени преди или по време на прехода. Както беше обсъдено по време на секцията „Мигриране на потребители в партиди“, функциите за повикване трябва да бъдат конфигурирани и прехвърлени, когато потребителите, които ги използват, бъдат прехвърлени.

За подробности как да конфигурирате всяка от Webex Calling функциите вижте съответните помощни статии за конфигуриране.

• Автоматични служители - За да управлявате автостюардесите, вижте Автоматични служители

• Парк за обаждания - За да управлявате парка за обаждания, виж те Call park

• Вземане на повикване - За да конфигурирате групата за получаване на повикване, виж те Пол учаване

• Опашки за повиквания - За да конфигурирате опашката за повиквания, виж те О пашка

• Групи за лов - За да управлявате ловни групи, вижте Управление на група за лов

• Режими на работа - За маршрутизиране на повиквания въз основа на режими на работа вижте Маршрутизиране на повиквания въз основа на оперативни режими

• Групи за пейджинг - За да конфигурирате група за пейджинг, вижте Конфигу риране на пейджинг група

• Записи - За да управлявате записа на повикванияWebex Calling, вижте Управление на записи

• Достъп до единичен номер - За да конфигурирате обхват на единичен номер (офис навсякъде), вижте Кон фигуриране на единичен

• Група гласова поща - За да управлявате споделена гласова поща и входяща факсова кутия вижте Управление на гласов Webex Calling ата поща.

Тестването за приемане гарантира, че мигрираната среда отговаря на функционалните изисквания, работи според очакванията и осигурява безпроблемно потребителско изживяване във всички комуникационни работни потоци. Този процес на валидиране е многостранен и обхваща всичко - от предоставянето на потребителя и задаването на но мера до оперативната ефективност на разширените функции за пови кване.

Този раздел предоставя примери и подчертава ключови аспекти, които трябва да се вземат предвид по време на тестването за приемане; той обаче не е предназначен да служи като изчерпателен или изчерпателен контролен списък.

Предоставяне на потребителя и присвояване на номера

Основен аспект на тестването за приемане включва проверка дали всички потребители са предоставени точно и изцяло вътре. Webex Calling Това изисква задълбочено сравнение между директорията source (Unified CM) и новосъздадената Webex Calling потребителска база, за да се гарантира, че всеки потребителски акаунт, заедно със свързаните атрибути като номера на разширения и задачите за директно набиране (DID) е мигриран правилно. Пълнотата на осигуряването е от решаващо значение не само за оперативността на първия ден, но и за текущата администрация и поддръжка.

Валидирането на присвояване на номера включва потвърждаване, че на всеки потребител е присвоено правилното разширение и външен номер и че тези номера се насочват правилно както във вътрешните (вътрешни), така и във външни (PSTN) потоци от повиквания. От съществено значение е да проверите за припокривания, липсващи задачи или неправилни конфигурации, които биха могли да доведат до грешки при маршрутизиране на повиквания или прекъсвания на услугата.

PSTN Потоци от повиквания и представяне на идентификатора на обаждащия се

Една стабилна процедура за изпитване на приемане трябва да включва валидиране от край до край на потоците от повиквания PSTN. Това включва както входящи, така и изходящи сценарии за повиквания. За входящи PSTN обаждания екипът за тестване трябва да потвърди, че обажданията се доставят до предвидените крайни точки, независимо дали това са индивидуални потребители, опашки за повиквания, групи за лов или автоматични служители. Изходя щите PSTN обаждания трябва да се извършват успешно, като особено внимание се отделя на правилното предоставяне и представяне на информацията за идентификационния номер на повикващия. Това включва гарантиране, че правилното име и номер на повикващия се показват на външни получатели в съответствие с организационните политики и регулаторните изисквания.

Тестването следва също така да разглежда сценарии за прекъсване на прекъсване, като например обработката на недостъпни крайни точки или прекъсвания в мрежата. Това помага да се потвърди, че резервните механизми и алтернативното маршрутизиране функционират правилно, поддържайки непрекъснатостта и надеждността на услугата.

Потоци от повиквания в мрежата

Вътрешните или мрежовите потоци от повиквания формират гръбнака на корпоративната комуникация. Тестването за приемане в тази област проверява дали обажданията между потребителите в организацията са насочени правилно, като функции като прехвърляне на повиквания, задържане, пренасочване и конферентна връзка работят по предназначение. Целостта на плановете за набиране, свързан остта от разширение към разширение и поддръжката на организационните политики за обаждания трябва да бъдат потвърдени.

Управление на потребителски повиквания и проверка на функциите

Важен аспект на тестването за приемане включва проверка на начина, по който потребителите се справят с обажданията, използвайки приложението Webex и поддържаните настолни телефони. Този процес се фокусира върху потвърждаването, че ежедневните работни потоци за обаждания са интуитивни и надеждни и че потребителите имат безпроблемен достъп до основните функции, необходими за техните роли. Тестването следва да оцени лекотата, с която потребителите могат да осъ ществяват и получават обаждания, да управляват функциите за задържане и възобновяване и да извършват както слепи, така и консултативни трансфери. Също така е важно да се провери дали пренасочването на повиквания, конферентна връзка и други разширени възможности, като паркиране и извличане на повиквания или активиране не смущават, са лесно достъпни и работят безпроблемно.

Опитът трябва да бъде оценен за яснота и отзивчивост, като се има предвид как потребителите взаимодействат с историята на обажданията, гласовата поща и интегрираните директории. Трябва да се обърне допълнително внимание на възможността за преместване на активни повиквания между устройства и ефективно използване на контролите по време на повикване в рамките на приложението или на физически телефони. Крайната цел е да се гарантира, че изживяването на крайния потребител е последователно, ефективно и напълно подкрепя комуникационните нужди на организацията след миграцията.

Опашки за обаждания: Опит на агент и ръководител

Опашките за обаждания често се използват за обработка на сценарии за входящи пови квания с голям обем. Тестването за приемане тук се фокусира върху няколко измерения. Първо, трябва да се провери дали обажданията се разпределят на агентите според конфигурираната логика на опашката, като кръгъл робин, най-дълъг празен ход или едновременен пръстен. Представянето на обаждания на опашки на настолните компютри на агенти трябва да бъде проучено за яснота и лекота на използване, като се гарантира, че агентите могат ефективно да приемат, задържат и прехвърлят обаждания.

За надзорниците изживяването на работния плот трябва да бъде оценено за функции като мониторинг в реално време, прехвърляне на повиквания и анализ или информация за ефектив ността на опашката. Това включва, но не се ограничава до валидиране на табла за управление и инструменти за отчитане, които предоставят приложими данни за разпространението на повиквания, активността на агента и показателите за опашки.

Групи за лов: Разпространение на обаждания

Групите за лов са ключов механизъм за разпространение на повиквания към предварително определени набори от потребители. Тестването за приемане трябва да потвърди, че обажданията се насочват към членове на групата въз основа на конфигурирания алгоритъм за лов и че сценариите за препълване, пренасочване и без отговор се обработват според дизайна. Гарантирането, че поведението на членството в групата и маршрутизирането на повик вания съответстват на установените преди това, Unified CM е от съществено значение за оперативната последователност и удовлетвореността на потребителите

Автоматични служители: Съобщения и операции в менюто

Автоматичните служители представляват първа линия на автоматизираното управление на повиквания. Тестването трябва да обхваща възпроизвеждането на съобщения, точността на записаните поздрави и правилната работа на дърветата от менюта. Из борът на менюта трябва надеждно да насочва повикващите към съответните отдели, физически лица или външни номера. Тестването трябва също така да включва невалидни сценарии или сценари и за изтичане на времето, за да се потвърди, че повикващите получават ясни насоки или са пренасочени по предназначение.

Операция с гласова поща

И накрая, функционалността на гласовата поща е от решаващо значение за потребителското изживяване. Тестовете за приемане трябва да проверят дали кутиите за гласова поща са правилно зададени и достъпни, както от организацията, така и от разстояние. Възможността за записване, извличане и управление на съобщения трябва да бъде потвърдена, заедно с доставката на уведомления.

За да наблюдавате средата след миграцията, да валидирате производителността и да правите корекции, за да осигурите оперативна стабилност и ефективност, вижте фазата на оптимизи ране.