Першим кроком у переході до 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, та сторонніх утиліт міграції, які плануються для ширшого організаційного розгортання, гарантуючи, що процеси, робочі процеси автоматизації та точки інтеграції ретельно перевіряються за репрезентатив них умов.

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

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

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

Щоб придбати послуги PSTNWebex Calling, спочатку виберіть параметр підключення PSTN у Центрі керування.

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

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

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

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

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

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

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

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

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

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

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

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

• У тому ж полюванні пілот, черга викликів і т.д.

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

• Використання підбору дзвінків

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

• Домофон

• Керівник/Адміністратор.

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

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

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

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

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

• Перевірте, що всі користувачі перебувають у Центрі керування

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

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

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

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

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

• Інструменти використання - Інструменти міграції користувачів і функцій Control Hub та/або сторонні інструменти

• Вимкнути/Видалити номер каталогу користувача/пристрою та функції виклику ввімкнути/служби після переходу. 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. Для отримання додаткової інформації про кроки для завершення оновлення мікропрограми див. розділ Пере творення IP-телефонів Cisco серії 7800 та 8800 між корпоративними та MP P мікропрограмами.

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

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

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-телефони, для переходу їх від корпоративної прошивки до хмарної прошивки. Тому ви забезпечите кожен із цих пристроїв у Контрольному центрі. Деякі з них неможливо перевести, Webex Calling і еквівалентну Webex Calling модель потрібно буде замінити її (напр. ATA 191/192) та інші потребують ручної переналаштування та/або зміни програмного забезпечення.

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

  Докладніші відомості щодо налаштування голосового шлюзу VG400, VG410 або VG420 у Центрі керування див. розділ Локальний шлюз

• Аналоговий телефонний адаптер (ATA) - Для початку роботи з Cisco ATA 191 і 192 див. Cisco ATA.

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

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

  Щоб створити та керувати цифровою мережею DECT у Control Hub, див. розділ Керування мереже ю DEC T

  Для отримання додаткової інформації про Cisco IP DECT 6800 див. Посібник із розгортання

• Прист ^ро ї та телефони треть ої сторони - Працюйте ^з постачальниками тре тьої сторони щодо вимог до пристроїв/телефону та процесу їх міграції або заміни на підтримку. Webex Calling

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

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

• Автосервіси - Щоб керувати автосервісами, див. розділ Автосервіси

• Парк викликів - Щоб керувати парком викликів, див. Парк викликів

• Прийом дзвінків. Щоб налаштувати групу прийому дзвінків, див. розділ Прийо м дзві нків

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

• Групи полювання - Щоб керувати групами полювання, див. розділ Керування групою полювання

• Режим роботи - Для маршрутизації викликів на основі режимів роботи див. Маршру тизація викликів на основі операційних режимів

• Групи сторінок. Щоб налаштувати групу підкачки, див. розділ Налаштування групи підказок

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

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

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

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

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

Забезпечення користувача та присвоєння номера

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

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

Потоки дзвінків PSTN та презентація ідентифікатора абонента

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

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

Потоки дзвінків в мережі

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

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

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

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

Черги дзвінків: досвід агента та керівника

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

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

Групи полювання: Розподіл дзвінків

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

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

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

Операція голосової пошти

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

Для моніторингу середовища після міграції, перевірки продуктивності та внесення коригувань для забезпечення стабільності та ефективності роботи див. Фаза оптимізації.