Першим кроком у переході на Webex Calling є забезпечення надійного та безпечного підключення до Інтернету між локальною мережею та хмарою Webex.

Оскільки більшість організацій підключаються до Інтернету через один або декілька брандмауерів або пристроїв безпеки, важливо перевірити, чи підтримуються необхідні потоки трафіку.

Мережеві та безпекові адміністратори повинні розуміти ці потоки з точки зору:

• Напрямок (вхідний чи вихідний)

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

• Діапазони IP-адрес, що використовуються сервісами Webex

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

Це гарантує, що корпоративні брандмауери, пристрої NAT та інша мережева інфраструктура належним чином налаштовані для обробки трафіку Webex Calling, зберігаючи при цьому політики безпеки підприємства.

Щоб отримати інформацію про необхідні потоки, включаючи IP-адресу, порти та протоколи, див. Довідкова інформація про порти для викликів Webex. Використайте цю інформацію для налаштування брандмауера, проксі-серверів та іншої мережевої інфраструктури в існуючому розгортанні, щоб увімкнути мережеві потоки 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 на рисунку Поетапний перехід викликів): Гібридний та хмарний) тимчасово або на невизначений термін, їм потрібно буде розгорнути один або кілька локальних шлюзів для локальної PSTN, щоб дозволити дзвінки між кінцевими точками Webex Calling та Unified CM.

Якщо кінцевою метою є повний перехід ( фаза 2) до хмари, включаючи PSTN, то для PSTN знадобиться або тарифний план Cisco Calling Plan, або опція Cloud Connect for Webex Calling.

Зверніться до обраного вами постачальника послуг, щоб замовити та перенести номери телефонів, перш ніж налаштовувати їх у Control Hub. Замовлення номерів телефонів або ініціювання замовлень на перенесення даних можливе лише required/possible для локальної PSTN та Cloud Connect для Webex Calling. Для тарифних планів Cisco Calling Plan замовлення та перенесення ініціюється з Control Hub одразу після створення розташування, а також у країнах, де доступний тарифний план Cisco Calling Plan. Щоб отримати додаткові відомості про плани Cisco Calling, див. Початок роботи з планами 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 для Webex Calling або Cisco Calling Plan як варіант PSTN, просто виберіть відповідний варіант PSTN для локації під час налаштування. Якщо розташування використовує Cloud Connect для Webex Calling або локальну PSTN, вам потрібно буде додати номери телефонів, замовлені на попередньому кроці. Номери можна додати як неактивні, якщо ви не хочете одразу включати їх до маршрутизації викликів; ви можете активувати ці номери пізніше, коли їх буде призначено користувачам або функціям.

Важливо завжди встановлювати головний номер для кожного місця розташування. Основний номер можна призначити або користувачеві, або функції, наприклад, автосекретарю. Щоб увімкнути голосову пошту в цьому місці, обов’язково встановіть пілотний номер голосової пошти, також відомий як номер голосового порталу.

Додаткові налаштування для виклику місць розташування включають налаштування деталей екстрених викликів, таких як номер екстреного зворотного виклику, параметри сповіщень та розширені функції екстрених викликів. Також слід переглянути та налаштувати параметри запису, мовні налаштування та конфігурації пристроїв відповідно до потреб кожного місця розташування. Якщо ваша організація використовує скорочений міжсайтовий внутрішньомережевий набір номерів із корпоративними значущими номерами, не забудьте налаштувати унікальний код сайту для розташування у внутрішніх налаштуваннях набору. Зрештою, якщо для зовнішнього набору потрібна цифра вихідного набору, обов’язково встановіть її в налаштуваннях зовнішнього набору. Якщо налаштовано вихідний набір цифри, Cisco рекомендує ввімкнути примусове використання вихідного набору цифри для забезпечення узгодженості.

Для інтеграції з локальним керуванням викликами необхідно налаштувати транкінги, групи маршрутів, корпоративні абонентські плани, а також налаштування розташування та глобальні налаштування. Почніть з налаштування транкових ліній та локальних шлюзів, призначених для взаємоз’єднання з локальною системою керування викликами; цей крок потрібен лише за необхідності виділених транкових ліній. Якщо існуючих транків та груп маршрутів достатньо для вашого розгортання, їх можна повторно використовувати для локального з'єднання без додаткового налаштування.

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

Якщо для вашого розгортання потрібна підтримка маршрутизації невідомих розширень, цю функцію слід увімкнути на рівні розташування. Крім того, коли активовано маршрутизацію невідомих внутрішніх номерів, необхідно вказати максимальну довжину невідомого внутрішнього номера в розділі Маршрутизація викликів між Webex Calling та приміщеннями налаштувань служб викликів у Центрі керування. Це забезпечує безперебійну маршрутизацію викликів та належну обробку сценаріїв набору номерів на основі додаткових номерів у вашому інтегрованому середовищі.

Під час перенесення користувачів з Unified CM до Webex Calling можливо, що ви не зможете перемістити всіх користувачів одночасно. Це може бути пов’язано з кількома причинами, зокрема, але не обмежуючись кількістю сайтів або користувачів, часом, необхідним для перенесення сайту and/or група користувачів одночасно, обмежені ІТ-ресурси або ресурси сайту для підтримки вікна змін, тривалість вікна змін, складність змін тощо.

Під час поетапної міграції користувачів критично важливо визначити, яких користувачів потрібно мігрувати разом в одному пакеті. Основна мета — разом перенести користувачів, які мають залежності один від одного щодо своїх послуг та функцій викликів. Ви хочете переконатися, що всі їхні функції викликів (наприклад, черги викликів) повністю функціональні у Webex Calling, як і до переходу на Unified CM.

Навіть якщо ви реалізуєте взаємодію викликів між Unified CM та Webex Calling з локальними шлюзами, ви не зможете розділити спільні служби або функції між цим з’єднанням. Тому вам потрібно визначити залежності між користувачами, розглядаючи такі функції, як:

• Моніторинг інших користувачів за допомогою BLF

• У тому ж пілотному проекті пошуку, черзі викликів тощо

• Спільні лінії

• Використання функції перехоплення дзвінків

• Використання тих самих номерів паркування викликів

• Домофон

• Executive/Admin.

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

Це стає складнішим, коли користувачі підключені до різних груп користувачів для різних послуг та функцій викликів. Це вимагатиме одночасного переведення кількох груп користувачів та однієї служби викликів на Webex Calling.

Використайте результати інструменту Control Hub Migration Insights або стороннього інструменту, який ви використовували на етапі підготовки, щоб визначити, яких користувачів та функції слід згрупувати разом. Цей результат слід було використати для розробки плану міграції, і він дасть вам уявлення про те, як групувати користувачів та функції, які потрібно перенести разом.

Ключові кроки під час переходу групи користувачів:

• Визначення користувачів для спільної міграції

• Перевірте, чи всі користувачі є в Центрі керування

• Перевірте, чи всі TN-імена для користувачів існують у Центрі керування

• Перевірте правильність формату номера телефону в довіднику

• Переконайтеся, що шаблони ліцензування та налаштувань для груп користувачів налаштовано правильно.

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

• У корпоративному довіднику додайте користувачів до групи користувачів з увімкненою функцією виклику

• Використовуйте інструменти – інструменти для міграції користувачів та функцій Центру керування and/or інструменти сторонніх розробників

• Disable/Delete user/device номер телефону та виклик features/services на Unified CM після переходу.

Після міграції групи користувачів перевірте підмножину користувачів, щоб перевірити, чи всі їхні функції та служби викликів працюють належним чином. Якщо функції викликів, такі як черга викликів, групи пошуку тощо, переносяться разом із групою користувачів, тоді перевірте ці служби викликів на належне функціонування.

У Webex Calling робоча область – це спільне розташування (наприклад, конференц-зал, місце для нарад або робочий стіл), якому можна призначити пристрої, розширення та користувачів. На відміну від традиційних телефонів Unifed CM, робочі простори:

• Орієнтований на місцезнаходження: прив'язаний до фізичних просторів.

• Гнучкий для пристрою: може мати один або декілька пристроїв (стаціонарні телефони, дошки тощо).

Після того, як робочі простори будуть визначені в рамках переходу до Webex Calling, їх можна буде додати в Центрі керування в розділі Пристрої. Кожному робочому простору потрібно призначити пристрій, і якщо вони вже знаходяться в Unified CM, їх потрібно скинути або повторно налаштувати для Webex. Такі функції Webex Calling, як голосова пошта, переадресація викликів та перехоплення викликів, можна вмикати або вимикати, а також за потреби можна застосовувати політики для відеодзвінків, паркування викликів та мобільності. Перевірте кожне робоче місце, здійснюючи внутрішні та зовнішні дзвінки, тестуючи відео- та конференц-зв'язок, а також функції мобільності. Насамкінець, повідомте користувачів про будь-які застосовні процеси для пристроїв робочого простору та бронювань.

Щоб отримати додаткові відомості про робочі області в Центрі керування, див. Робочі області.

Телефони, які наразі зареєстровані в Unified CM, потрібно буде перенести на Webex Calling у рамках переходу до хмари. Щоб максимально спростити міграцію та мінімізувати ризик невдачі, Cisco рекомендує одночасно переносити фізичні сайти або відділи. Однак, можливо, вам доведеться переносити користувачів пакетами через залежності функцій. Див. розділ Пакетна міграція користувачів для отримання додаткової інформації.

Будь-які телефони з підтримкою Webex Calling, на які потрібно перейти з Unified CM, потрібно буде налаштувати у Webex Calling як користувача або робочу область, а фізичний телефон потрібно буде переналаштувати для реєстрації у Webex Calling. Крім того, для телефонів серій 7800 та 8800 потрібно оновити прошивку з Enterprise до Multiplatform Phone (MPP). Цей процес включає завантаження перехідної прошивки перед завантаженням прошивки MPP, необхідної для реєстрації Webex Calling. Також потрібна відповідна міграційна ліцензія. Протягом останніх кількох років Cisco вдосконалила цей процес, щоб спростити оновлення прошивки ваших телефонів Enterprise до прошивки MPP. Щоб отримати додаткові відомості про кроки для завершення оновлення прошивки, див. Перетворення прошивки Enterprise на MPP для IP-телефонів Cisco серій 7800 та 8800.

Окрім кроків, описаних у цій статті, Control Hub має вбудований інструмент «Перенесення телефону до Webex Calling» , який можна використовувати для перенесення прошивки телефонів 7800 та 8800 з Enterprise на MPP. Цей інструмент також дозволяє додавати телефони до Центру керування та призначати їх відповідним користувачам або робочим просторам. Щоб отримати додаткові відомості про використання інструменту, див. Перенесення телефону.

Для будь-яких телефонів серії 9800, зареєстрованих в Unified CM, вищезазначена вимога щодо міграції прошивки не застосовується. Ці телефони працюють під управлінням PhoneOS, яка підтримується як Unified CM, так і Webex Calling. Щоб перевести ці телефони на Webex Calling, вам потрібно буде додати їх до Webex Calling, призначити їх користувачеві або робочому простору, а потім скинути налаштування телефонів до заводських. Послідовність завантаження PhoneOS для реєстрації на малюнку нижче показано послідовність завантаження PhoneOS та те, як телефон зареєструється в Webex Calling після додавання до Control Hub, навіть якщо телефон все ще налаштовано на Unified CM and/or Використовуються параметри DHCP (приклад - 150).

Unified CM підтримує скидання налаштувань пристроїв PhoneOS до заводських, що дозволяє безконтактну інтеграцію в Webex Calling. Адміністратори Unified CM можуть віддалено скидати телефони 9800 та 8875 до заводських налаштувань через сторінки адміністрування CUCM, що усуває необхідність фізичного доступу до телефонів для їхньої реєстрації в Webex Calling. Ця функція підтримується пакетами пристроїв з 9 вересня 2025 року:

• CUCM версії 15 - Unified Communications Manager версії 15

• CUCM версії 14 - Unified Communications Manager версії 14.

Щоб отримати докладнішу інформацію про процес реєстрації серії 9800, див. Процес реєстрації.

Окрім IP-телефонів Cisco, може знадобитися налаштування інших пристроїв, таких як аналогові телефонні адаптери (ATA), бездротові телефони (Wi-Fi, DECT), відеопристрої, голосові шлюзи та пристрої й телефони сторонніх^{виробників}. Багато з цих пристроїв не мають шляху оновлення прошивки, як IP-телефони, щоб перейти з корпоративної прошивки на хмарну. Таким чином, ви налаштуєте кожен із цих пристроїв у Центрі керування. Деякі з них неможливо перенести на Webex Calling, і їх потрібно буде замінити еквівалентною моделлю Webex Calling (наприклад, ATA 191/192) а інші потребуватимуть ручного переналаштування and/or зміни програмного забезпечення.

• Голосові шлюзи – Щоб перенести свій локальний шлюз, див. Перенесення локального шлюзу.

  Щоб отримати додаткові відомості про налаштування голосового шлюзу VG400, VG410 або VG420 у Control Hub, див. Локальний шлюз

• Аналоговий телефонний адаптер (ATA) – Щоб розпочати роботу з Cisco ATA 191 та 192, див. Cisco ATA.

• Бездротовий телефон Wi-Fi – Щоб інтегрувати бездротові телефони Webex 840 та 860, див. Інтеграція бездротового телефону Webex.

• Бездротові телефони DECT – Щоб розпочати роботу з новою серією Cisco IP DECT 6800, див. Cisco IP DECT.

  Щоб побудувати та керувати цифровою мережею DECT у Control Hub, див. Керування мережею DECT

  Щоб отримати додаткові відомості про Cisco IP DECT 6800, див. Посібник з розгортання

• сторонні пристрої та телефони - Працюйте зі сторонніми^{постачальниками [] сторонніх} постачальників на device/phone вимоги та процес їх перенесення або заміни для підтримки Webex Calling.

Будь-які функції викликів, необхідні в Webex Calling, необхідно налаштувати до або під час переходу. Як обговорювалося в розділі «Перенесення користувачів пакетами», функції викликів необхідно налаштувати та перенести під час перенесення користувачів, які їх використовують.

Докладнішу інформацію про налаштування кожної з функцій Webex Calling див. у відповідних статтях довідки з налаштування.

• Автосекретарі – Щоб керувати автосекретарями, див. Автосекретарі

• Паркування викликів – Інструкції щодо керування паркуванням викликів див. у розділі Паркування викликів

• Перехоплення виклику – Щоб налаштувати групу перехоплення виклику, див. Перехоплення виклику

• Черги викликів – Щоб налаштувати чергу викликів, див. Черга викликів

• Групи пошуку – Щоб керувати групами пошуку, див. Керування групою пошуку

• Режими роботи – Щоб дізнатися про маршрутизацію викликів на основі режимів роботи, див. Маршрутизація викликів на основі режимів роботи

• Групи пейджингу – Щоб налаштувати групу пейджингу, див . Налаштування групи пейджингу

• Записи – Щоб керувати записом викликів для Webex Calling, див. Керування записами

• Охоплення одним номером – Щоб налаштувати охоплення одним номером (офіс будь-де), див. Налаштування одного номера

• Група голосової пошти – інструкції щодо керування спільною голосовою поштою та скринькою вхідних факсів для Webex Calling див. у розділі Керування голосовою поштою.

Приймальні випробування гарантують, що перенесене середовище відповідає функціональним вимогам, працює належним чином та забезпечує безперебійний користувацький досвід у всіх комунікаційних робочих процесах. Цей процес перевірки є багатогранним і охоплює все: від налаштування користувачів та призначення номерів до операційної продуктивності розширених функцій викликів.

У цьому розділі наведено приклади та висвітлено ключові аспекти, які слід враховувати під час приймальних випробувань; однак він не призначений для використання як вичерпний або всебічний контрольний список.

Налаштування користувачів та призначення номерів

Фундаментальний аспект приймального тестування включає перевірку того, що всі користувачі точно та повністю налаштовані в Webex Calling. Це вимагає ретельного порівняння між вихідним каталогом (Unified CM) та новоствореною базою користувачів Webex Calling, щоб переконатися, що кожен обліковий запис користувача разом із пов’язаними атрибутами, такими як номери додаткових номерів та призначення прямого вхідного набору (DID), було правильно перенесено. Повнота забезпечення є критично важливою не лише для працездатності з першого дня, але й для подальшого адміністрування та підтримки.

Перевірка призначення номера включає підтвердження того, що кожному користувачеві призначено правильний додатковий та зовнішній номер, а також що ці номери правильно маршрутизуються як у внутрішніх (всередині мережі), так і в зовнішніх (PSTN) потоках викликів. Важливо перевірити наявність будь-яких дублювань, відсутніх призначень або неправильних конфігурацій, які можуть призвести до помилок маршрутизації викликів або переривань обслуговування.

Потоки викликів PSTN та відображення ідентифікації абонента

Надійна процедура приймального тестування повинна охоплювати наскрізну перевірку потоків викликів PSTN. Це включає як вхідні, так і вихідні дзвінки. Для вхідних викликів PSTN команда тестування повинна підтвердити, що виклики доставлені до призначених кінцевих точок, незалежно від того, чи це окремі користувачі, черги викликів, групи пошуку чи автосекретарі. Вихідні дзвінки через PSTN мають бути здійснені успішно, приділяючи особливу увагу правильній доставці та представленню інформації про ідентифікатор абонента. Це передбачає забезпечення того, щоб зовнішнім одержувачам відображалися правильні ім'я та номер абонента відповідно до політик організації та нормативних вимог.

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

Потоки викликів у мережі

Внутрішні, або мережеві, потоки викликів формують основу корпоративної комунікації. Приймальні випробування в цій області перевіряють, чи правильно маршрутизуються дзвінки між користувачами в організації, а такі функції, як переадресація дзвінків, утримання, переадресація та конференц-зв'язок, працюють належним чином. Необхідно підтвердити цілісність планів набору номера, з'єднання між внутрішніми номерами та підтримку політик викликів організації.

Обробка викликів користувачів та перевірка функцій

Важливим аспектом приймального тестування є перевірка того, як користувачі обробляють виклики за допомогою програми Webex та підтримуваних стаціонарних телефонів. Цей процес зосереджений на підтвердженні того, що щоденні робочі процеси викликів є інтуїтивно зрозумілими та надійними, а користувачі мають безперешкодний доступ до основних функцій, необхідних для їхніх ролей. Тестування має оцінити легкість, з якою користувачі можуть здійснювати та приймати дзвінки, керувати функціями утримання та відновлення, а також виконувати як сліпі, так і консультативні переадресації. Також важливо перевірити, чи переадресація викликів, конференц-зв'язок та інші розширені функції, такі як паркування та отримання викликів або активація режиму "Не турбувати", легкодоступні та працюють безперебійно.

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

Черги викликів: Досвід роботи агентом та керівником

Черги викликів часто використовуються для обробки сценаріїв великої кількості вхідних викликів. Приймальні випробування тут зосереджені на кількох вимірах. Спочатку слід перевірити, чи розподіляються виклики між агентами відповідно до налаштованої логіки черги, такої як циклічний режим, найдовший час простою або одночасний дзвінок. Відображення викликів у черзі на робочих столах агентів має бути перевірено на предмет чіткості та зручності використання, щоб агенти могли ефективно приймати, утримувати та переадресовувати виклики.

Керівникам слід оцінити можливості роботи з комп’ютером на предмет таких функцій, як моніторинг у режимі реального часу, переривання викликів та аналітика або дані про продуктивність черги. Це включає, але не обмежується, перевіркою інформаційних панелей та інструментів звітності, які надають корисні дані про розподіл викликів, активність агентів та показники черги.

Мисливські групи: Розподіл дзвінків

Групи пошуку є ключовим механізмом розподілу викликів між заздалегідь визначеними наборами користувачів. Приймальні випробування повинні підтвердити, що виклики маршрутизуються до членів групи на основі налаштованого алгоритму пошуку, а сценарії переповнення, переадресації та відсутності відповіді обробляються відповідно до проекту. Забезпечення відповідності членства в групах та поведінки маршрутизації викликів тим, що було раніше встановлено в Unified CM, є важливим для операційної узгодженості та задоволення користувачів.

Автосекретарі: Оголошення та операції з меню

Автосекретарі представляють собою передову лінію автоматизованої обробки викликів. Тестування повинно охоплювати відтворення оголошень, точність записаних привітань та правильність роботи дерев меню. Вибір пунктів меню повинен надійно перенаправляти абонентів до відповідних відділів, осіб або зовнішніх номерів. Тестування також повинно включати сценарії недійсності або тайм-ауту, щоб підтвердити, що абоненти отримують чіткі вказівки або перенаправляються належним чином.

Робота голосової пошти

Зрештою, функціональність голосової пошти є критично важливою для взаємодії з користувачем. Приймальні тести повинні перевірити, чи правильно призначені та доступні скриньки голосової пошти як зсередини організації, так і віддалено. Можливість записувати, отримувати та керувати повідомленнями має бути підтверджена разом із доставкою сповіщень.