- 首頁
- /
- 文章
實作從 Unified CM 到 Webex Calling 的遷移
實施階段是將設計和計劃付諸實行。在此階段,您 需要設定和部署 Webex Calling 環境以滿足業務需求。這包括設定雲端呼叫控制、根據需要將 連接到本機系統、啟用 PSTN 存取以及設定使用者、裝置和 撥號計畫。目標是在 部署過程中保持業務連續性和流暢的使用者體驗,同時提供安全、可擴展且可靠的雲端呼叫解決方案 。
網路整備
過渡到 Webex Calling 的第一步是確保本地網路和 Webex 雲端之間 可靠且安全的 網路連線。
由於大多數組織透過一個或多個 防火牆 或 安全設備連接到互聯網,因此驗證 所需的流量是否得到支援至關重要 。
網路和安全管理員必須從以下幾個方面來理解這些流程:
-
方向 (入站 vs 出站)
-
協定 (例如:SIP TLS、SRTP、HTTPS)
-
Webex 服務所使用的 IP 位址範圍
-
必須開啟或允許的連接埠號碼 。
這樣可以確保企業防火牆、NAT 設備和其他網路基礎架構得到正確配置,以適應 Webex Calling 流量,同時維護企業安全策略。
有關所需流程(包括 IP 位址、連接埠和協定)的信息,請參閱 Webex Calling 的連接埠參考資訊。使用這些資訊設定現有部署中的防火牆、代理程式和其他網路基礎設施,以啟用 Webex Calling 網路流。
對於 Webex Calling 等雲端協作服務,建議採用從每個分公司或網站分散式網際網路存取的方式。透過允許流量從本地流出,該模型:
-
減少往返延遲和抖動,提高整體通話質量
-
隨著越來越多的使用者和網站遷移到 Webex Calling,其擴充性非常出色。
-
與 SD-WAN 無縫協作,可將會話動態路由到最近的 Webex 雲端入口點,以實現最佳效能。
- 允許根據用戶的公共 IP 位址追蹤用戶位置,這有助於媒體路徑分析和故障排除。
此外,各機構必須確保每個站點都有足夠的網路頻寬。頻寬的大小應根據預期的同時呼叫數、所選編解碼器(例如 Opus 或 G.711)以及訊號、重傳和成長的開銷來決定。這與 PPDIO 生命週期的準備階段相一致,並為遷移奠定了堅實的基礎。
初始設定
在部署 Webex Calling 的實施階段中,初始設定小節是建立一個結構良好且易於管理的雲端通話環境的基礎。此階段包括關鍵任務,例如建立控制中心組織、取得和分配許可證,以及驗證和認領公司域名,以確保適當的使用者管理和安全。此外,它還包括提供許可證範本以自動分配使用者許可證,配置單一登入 (SSO) 以簡化使用者身份驗證和增強安全性,以及調整服務和用戶端設定以符合組織政策和使用者需求。完成這些初始設定活動可確保 Webex Calling 環境配置得當,以實現可擴展性、安全性和流暢的使用者體驗,為後續的部署和營運階段奠定基礎。
網域驗證
為了使 Control Hub 能夠識別在 Webex 上使用貴公司電子郵件網域註冊的用戶,驗證您的網域至關重要。如果沒有進行網域驗證,用戶將被分配到消費者組織,這將使貴公司的用戶管理變得複雜。網域驗證是必要的步驟,它可以讓您的組織有效地認領和管理這些使用者。
請確保與使用者電子郵件地址關聯的所有網域均已驗證。網域驗證並非排他性的;同一個網域可以在多個 Webex 組織中進行驗證。
有關管理域名的更多信息,請參閱 管理您的域名。
認領(轉換)現有用戶
成功驗證網域後,您可以將使用公司電子郵件網域註冊 Webex 的使用者新增至您的組織。此流程將所有使用者整合到一個組織框架下,從而實現集中管理和簡化管理。透過認領這些用戶,您可以確保公司對用戶帳戶擁有完全控制權,從而能夠有效地分配合適的 Webex 授權、配置服務並提供必要的支援。這種統一的管理方法增強了安全性,簡化了使用者配置,並確保了整個組織對 Webex 服務的一致存取。認領使用者還可以防止他們在外部或消費者組織中被管理,從而維護組織的完整性和對協作資源的控制。
有關認領用戶的更多信息,請參閱 將用戶認領到您的組織(轉換)用戶。
配置並測試目錄同步
為了實現無縫的使用者和群組管理,您可以將企業目錄中的使用者和群組(無論是 Microsoft Entra ID(以前稱為 Azure AD)還是 Microsoft Active Directory (AD))同步到 Webex。此流程可確保使用者身分和群組成員資格在您的環境中保持一致。
對於實施分階段部署的組織而言,在初始推廣階段控制和限制同步範圍至關重要。這樣可以最大限度地降低意外變更的風險,並允許在更廣泛採用之前進行有針對性的測試。
篩選同步使用者最有效的方法是利用目錄群組成員關係:
| 1 |
建立專用同步群組: 在企業目錄(Microsoft Entra ID 或 AD)中,建立一個專門用於 Webex 同步的安全性群組(例如,Webex 同步群組)。 |
| 2 |
將目標用戶加入群組: 僅將您想要同步的使用者(例如試點階段的測試群組)新增至此群組。這樣可以讓你嚴格控制哪些人參與同步過程。 |
| 3 |
配置基於群組的篩選同步協定: 在 Webex Directory Connector 或 Entra ID 設定中設定同步協定時,請將範圍設定為僅包含指定群組的成員使用者。
|
| 4 |
根據需要擴展群組: 隨著部署階段的推進,只需在同步群組中新增其他使用者或群組即可。同步範圍將自動擴大到包括這些用戶,從而實現可控和漸進式的推廣。 範例實施步驟:
參考: |
設定並測試單一登入 (SSO)
單一登入 (SSO) 允許使用者使用其企業憑證進行一次身份驗證,即可無縫存取 Webex,從而增強安全性並簡化使用者存取。Webex 支援與符合 SAML 2.0 標準的身份提供者 (IdP) 進行 SSO 集成,包括 Microsoft Entra ID(以前稱為 Azure AD)、Active Directory (AD) 聯合解決方案以及各種第三方身分提供者。
此時應該實施並測試已設計的 SSO 設定。
參考:
取得、提供和核實許可證
作為 Webex Calling 初始設定的一部分,必須採購、設定和驗證適當的許可證,才能有效地啟用和管理服務。採購流程包括根據使用者角色和工作負載選擇授權類型,例如專業版、標準版和工作區版授權。許可證透過思科的軟體平台或合作夥伴產生和分配。採購和配置完成後,需要在控制中心驗證許可證數量是否正確。此流程可確保組織已啟動正確的許可證,並準備好在 Webex Calling 部署中使用。
作為 Webex Calling 初始許可設定的一部分,配置基於組織的自動許可對於簡化新使用者的許可證分配至關重要。這種設定允許在將使用者新增至組織時自動授予許可證,從而無需手動分配許可證。在組織層級配置自動許可時,您可以選擇要指派的服務並定義範圍,例如僅將授權套用至未來的使用者或也包含現有使用者。
但是,如果您的部署計畫涉及在群組層級使用自動許可,您可以選擇不在組織層級指派 Webex Calling 許可證,以避免衝突或重複的許可證分配。透過群組層級自動許可,許可證是根據群組成員身分分配的。多個使用者群組的使用者將獲得所有適用群組分配的許可證。
必須在目錄同步完成後執行基於群組的許可證分配配置,以便同步群組存在並可用於許可證分配。
具體來說,對於 Webex Calling,自動許可證分配需要額外的配置詳細信息,例如用戶位置和電話號碼分配。使用者的工作電話號碼必須已輸入。 +E.164 格式已設定好,已預先配置,並已指派給 Webex Calling 中的有效位置,以便許可證自動啟動。如果這些條件不滿足,則不會自動為使用者開啟 Webex Calling 服務,可能需要手動介入。
總而言之,如果您想要進行廣泛的、組織範圍內的授權分配,請為新使用者設定基於組織的自動許可。如果您希望進行更精細的控制,或者每個群組有不同的許可需求,請在群組層級配置自動許可,避免在組織層級分配許可證,以防止重疊並確保正確的許可證管理。
Webex 通話服務設定
對 Webex Calling 中的全域服務設定進行全面審查和配置至關重要。
首先存取控制中心,然後導航至 Webex Calling 設定部分。仔細檢查每個可設定選項,包括但不限於內部撥號配置、緊急呼叫參數、呼叫路由策略、語音郵件管理和設備預設設定。
調整這些全局設置,以反映貴組織的政策和設計決策。
此外,還要設定 Webex 應用程式設定以及使用者和應用程式範本。
試辦移民
在實施階段,執行試點遷移是驗證從 Unified CM 過渡到 Webex Calling 的關鍵里程碑。此試點計畫涉及在一個或多個地點為 Webex Calling 平台提供代表性的使用者子集,以確保所選使用者群體反映多樣化的使用案例和組織角色。在使用者遷移的同時,包括語音郵件、自動應答、呼叫佇列和呼叫群組在內的重要協作服務必須過渡到 Webex Calling 的相應功能,以維持業務連續性和服務功能。
試點遷移應利用思科提供的工具和第三方遷移實用程式的組合,這些工具和實用程式計劃用於更廣泛的組織部署,以確保在代表性條件下對流程、自動化工作流程和整合點進行徹底驗證。
本次試點部署的主要目標有兩個:首先,驗證並改善端到端過渡流程,包括使用者配置工作流程、資料遷移程序和終端配置;其次,在實際運作條件下全面驗證遷移服務的功能。
這種分階段的方法使專案團隊能夠在受控環境中識別和糾正任何技術或程序問題,收集使用者對新平台體驗的回饋,評估所選遷移工具的有效性,並在進行更廣泛的組織部署之前建立對遷移方法的信心。
本次試點階段所獲得的見解對於優化後續遷移浪潮、確保整個企業平穩過渡並降低風險至關重要。
採購公共交換電話網
若要為 Webex Calling 取得 PSTN 服務,請先在控制中心選擇 PSTN 連線選項。
如果一個組織計劃維持混合雙呼叫控制( 階段 1 在圖 分階段呼叫轉換:對於混合雲端和雲端部署(無論是暫時的還是永久的),他們需要為本地 PSTN 部署一個或多個本地網關,以允許 Webex Calling 和 Unified CM 端點之間進行通話。
如果最終目標是完全過渡到雲端( 第 2 階段),包括 PSTN,那麼 PSTN 將需要 Cisco Calling Plan 或 Cloud Connect for Webex Calling 選項。
與您選擇的服務提供者合作,訂購和轉移電話號碼,然後在 Control Hub 中配置它們。訂購電話號碼或發起端口訂單僅 required/possible 適用於本地 PSTN 和 Webex 通話的 Cloud Connect。對於 Cisco 通話計劃,一旦建立位置,即可在 Control Hub 內啟動訂購和連接埠轉移,且此流程適用於 Cisco 通話計劃可用的國家/地區。有關 Cisco Calling 套餐的更多信息,請參閱 Cisco 套餐入門。
作為 PSTN 實施的一部分,請確保您的服務提供者已為您的位置啟用入站和出站 PSTN 服務。此外,請執行測試呼叫,以驗證呼叫是否透過您選擇的 PSTN 連線正確路由。
配置位置
在向 Webex Calling 新增使用者和設備之前,必須先配置呼叫位置。每個地點都必須輸入有效的街道地址。在美國和加拿大,該位址經過驗證,並由平台用於發送緊急呼叫的 PIDF-LO 位置資訊。
配置使用本地 PSTN 的位置時,需要相應地設定本地網關。在 Webex Calling 中,必須為每個本機閘道建立一個中繼和一個路由組,然後將路由組指派為該位置的 PSTN 選擇。Cisco 強烈建議始終選擇路由組作為 PSTN 選擇,因為這種方法可以方便地在將來添加額外的中繼,從而支援可擴展性和冗餘性。Cisco 還建議在每個 PSTN 中繼上啟用雙重身分和 P-Charge-Info 支持,因為這簡化了對撥出直撥或轉撥電話的計費方的識別。如果您的 PSTN 供應商使用不同的計費標頭,您可以將本地網關上的 P-Charge-Info 標頭中的資訊複製到所需的計費標頭中。
對於使用 Cloud Connect for Webex Calling 或 Cisco Calling Plan 作為其 PSTN 選項的位置,只需在設定期間為該位置選擇相應的 PSTN 選項即可。如果該位置使用 Cloud Connect for Webex Calling 或本地 PSTN,則需要新增在上一個步驟中訂購的電話號碼。如果您不希望號碼立即包含在呼叫路由中,可以將其新增為非活動號碼;您可以在稍後將這些號碼指派給使用者或功能時啟動它們。
務必為每個地點設定主號碼。主號碼可以分配給使用者或功能,例如自動語音應答系統。若要在該地點啟用語音信箱,請確保設定語音信箱引導號碼,也稱為語音入口網站號碼。
呼叫位置的其他設定包括配置緊急呼叫詳細信息,例如緊急回撥號碼、通知選項和增強的緊急呼叫功能。您還應根據每個地點的需要,檢查並調整錄音設定、語言偏好和設備配置。如果您的組織使用帶有企業重要號碼的縮短的站點間網路撥號,請記住在內部撥號設定中為位置配置唯一的站點代碼。最後,如果對外撥號需要撥出撥號數字,請務必在對外撥號設定中進行設定。在設定出站撥號數字時,思科建議啟用出站撥號數字強制執行,以確保一致性。
與本地呼叫控制系統集成
要與本地呼叫控制集成,需要設定中繼線、路由組、企業撥號計畫以及位置和全域設定。首先設定用於與本機呼叫控制系統互連的中繼線和本機閘道;只有在需要專用中繼線時才需要執行此步驟。如果現有的中繼和路由組足以滿足您的部署需求,則可以將其用於本地互連,而無需額外配置。
一旦中繼線和路由群組建立完畢,就可以開始建立企業撥號計劃,並將對應的路由群組指派給每個撥號計劃作為目標。當整合涉及透過不同中繼線連接的多個本地呼叫控制系統時,將需要多個撥號方案。務必確保這些撥號方案僅包含將呼叫路由到本地目的地所需的模式。
如果您的部署需要支援未知擴充路由,則應在位置層級啟用此功能。此外,當啟用未知分機路由時,您必須在 Control Hub 的呼叫服務設定的 Webex Calling 和場所之間的呼叫路由部分 中指定最大未知分機長度。這確保了在整合環境中實現無縫的呼叫路由和基於分機撥號場景的正確處理。
分批遷移用戶
將使用者從 Unified CM 遷移到 Webex Calling 時,可能無法同時遷移所有使用者。這可能是由多種原因造成的,包括但不限於網站或使用者數量、網站遷移所需時間等。 and/or 同時進行的使用者群組、支援變更視窗的 IT 或網站資源有限、變更視窗持續時間、變更的複雜性等。
分階段遷移使用者時,確定哪些使用者需要在同一 批次中一起遷移至關重要。主要目標是將那些在呼叫服務和功能方面存在依賴關係的使用者一起遷移。您希望確保所有通話功能(例如 - 呼叫佇列)在 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 過渡後使用統一配置管理。
遷移完一組用戶後,測試一部分用戶,以驗證其所有呼叫功能和服務是否正常運作。如果呼叫佇列、呼叫群組等呼叫功能會隨使用者群組一起遷移,則測試這些呼叫服務的功能是否正常。
工作區
在 Webex Calling 中,「工作區」指的是可以分配設備、分機和使用者的共用位置(例如會議室、小型討論空間或共用辦公桌)。與傳統的統一通訊管理 (Unified CM) 電話不同,工作區具有以下特點:
-
以位置為中心:與物理空間相關。
-
設備靈活:可配備一個或多個設備(桌上型電話、白板等)。
在向 Webex Calling 過渡的過程中,一旦確定了工作區,就可以在「設備」下的「控制中心」中新增它們。每個工作區都需要指派設備,如果它們已經在 Unified CM 中,則需要重設或重新配置以用於 Webex。Webex Calling 的語音信箱、呼叫轉移和呼叫代接等功能可以啟用或停用,並且可以根據需要對視訊通話、呼叫駐留和移動性應用策略。透過撥打內部和外部電話、測試視訊、會議和行動功能來測試每個工作區。最後,告知使用者有關工作空間設備和預訂的任何適用流程。
有關 Control Hub 中工作區的更多信息,請參閱 工作區。
供應設備
作為雲端遷移的一部分,目前已註冊到 Unified CM 的電話需要遷移到 Webex Calling。為了盡可能簡化遷移過程,並將失敗的可能性降到最低,思科建議同時遷移實體站點或部門。但是,由於功能依賴性,您可能需要分批遷移使用者。有關更多詳細信息,請參閱 “分批遷移用戶 ”部分。
任何需要從 Unified CM 過渡到 Webex Calling 的支援的電話都需要在 Webex Calling 上設定為使用者或工作區,且實體電話需要重新設定才能在 Webex Calling 中註冊。此外,7800 和 8800 系列電話需要將其韌體從企業韌體升級到多平台電話 (MPP) 韌體。該過程包括在載入 Webex Calling 註冊所需的 MPP 韌體之前載入過渡韌體。此外,還需要相應的遷移許可證。思科在過去幾年中改進了這個流程,讓您更容易將企業韌體電話升級到 MPP 韌體。有關完成韌體升級的步驟的更多信息,請參閱 在企業版和 MPP 韌體之間轉換 Cisco 7800 和 8800 系列 IP 電話。
除了本文中概述的步驟之外,Control Hub 還內建了一個工具 將您的電話遷移到 Webex Calling,您可以使用該工具協助您將 7800 和 8800 電話從企業版韌體遷移到 MPP 韌體。該工具還允許您將電話新增至控制中心,並將其分配給相應的使用者或工作區。有關工具使用的更多信息,請參閱 遷移您的手機。
對於已在 Unified CM 註冊的任何 9800 系列電話,上述韌體遷移要求不適用。這些手機運行 PhoneOS 系統,該系統同時受 Unified CM 和 Webex Calling 支援。要將這些電話遷移到 Webex Calling,您需要將它們新增至 Webex Calling,將它們指派給使用者或工作區,然後將電話恢復原廠設定。PhoneOS 註冊啟動順序 下圖顯示了 PhoneOS 的啟動順序,以及手機新增到 Control Hub 後如何註冊到 Webex Calling,即使手機仍在 Unified CM 上設定。 and/or DHCP 選項(例如 - 150)正在使用中。
Unified CM 支援將 PhoneOS 裝置恢復原廠設置,從而實現 Webex Calling 的零接觸式註冊。Unified CM 管理員可以透過 CUCM 管理頁面遠端將 9800 和 8875 電話恢復出廠設置,這樣就無需實體存取電話即可將電話加入 Webex Calling。此功能自 2025 年 9 月 9 日起在設備包中支援:
-
CUCM v15 - 統一通訊管理器版本 15
-
CUCM v14 - 統一通訊管理器版本 14。
有關 9800 系列註冊流程的更多信息,請參閱 註冊流程。
除了 Cisco IP 電話之外,可能還需要設定其他設備,例如類比電話適配器 (ATA)、無線 (Wifi、DECT) 電話、視訊設備、語音閘道以及第三方設備和 電話。許多此類設備不像 IP 電話那樣有韌體升級途徑,無法從企業韌體過渡到雲端韌體。因此,您需要在控制中心配置這些設備。其中一些功能無法遷移到 Webex Calling,需要用等效的 Webex Calling 模型來替代(例如 ATA)。 191/192) 還有一些需要手動重新配置。 and/or 軟體變更。
- 語音網關 - 若要遷移本機網關,請參閱 遷移本機網關。
有關在 Control Hub 中配置語音網關 VG400、VG410 或 VG420 的更多信息,請參閱 本地網關
-
類比電話適配器 (ATA) - 若要開始使用 Cisco ATA 191 和 192,請參閱 Cisco ATA。
-
Wifi 無線電話 - 若要整合 Webex 無線電話 840 和 860,請參閱 整合 Webex 無線電話。
-
DECT 無線電話 - 若要開始使用您的新 Cisco IP DECT 6800 系列,請參閱 Cisco IP DECT。
若要在 Control Hub 中建置和管理數位 DECT 網絡,請參閱 管理 DECT 網路
有關 Cisco IP DECT 6800 的更多信息,請參閱 部署指南
-
第三方設備和手機 -與 第三方供應 商合作 device/phone 支援 Webex Calling 的要求以及遷移或取代這些要求的過程。
設定功能
Webex Calling 中所需的任何通話功能都需要在過渡之前或期間進行設定。如在「分批遷移使用者」部分所討論的,當使用這些功能的使用者進行遷移時,需要配置和遷移呼叫功能。
有關如何配置 Webex Calling 各項功能的詳細信息,請參閱相應的配置幫助文章。
-
自動服務員 - 要管理自動服務員,請參閱 自動服務員
-
呼叫駐留 - 若要管理呼叫駐留,請參閱 呼叫駐留
-
呼叫代接 - 若要設定呼叫代接群組,請參閱 呼叫代接
-
呼叫隊列 - 若要配置呼叫隊列,請參閱 呼叫隊列
-
狩獵組 - 要管理狩獵組,請參閱 管理狩獵組
-
操作模式 - 若要了解基於操作模式的呼叫路由,請參閱 基於操作模式的呼叫路由
-
分頁組 - 若要設定分頁組,請參閱 設定分頁組
-
錄音 - 若要管理 Webex Calling 的通話錄音,請參閱 管理錄音
-
單號碼存取 - 若要設定單號碼存取(任何辦公地點),請參閱 設定單號碼存取
-
語音郵件群組 - 若要管理 Webex Calling 的共用語音郵件和入站傳真箱,請參閱 管理語音郵件。
驗收測試
驗收測試確保遷移後的環境符合功能要求,按預期運行,並在所有通訊工作流程中提供無縫的使用者體驗。此驗證過程涉及多個方面,涵蓋從用戶配置和號碼分配到高級呼叫功能的運行性能等各個方面。
本節提供範例並重點介紹驗收測試期間需要考慮的關鍵方面;但是,它並非旨在作為詳盡或全面的檢查清單。
用戶配置和號碼分配
驗收測試的一個基礎面向是驗證所有使用者是否已在 Webex Calling 中準確、完整地設定。這需要對來源(統一 CM)目錄和新建立的 Webex Calling 用戶群進行徹底比較,以確保每個使用者帳戶以及相關屬性(例如分機號碼和直接撥入 (DID) 分配)都已正確遷移。配置的完整性不僅對第一天的運作至關重要,而且對後續的管理和支援也至關重要。
號碼分配驗證包括確認每個使用者都分配了正確的分機號碼和外部號碼,並且這些號碼在內部(網內)和外部(PSTN)呼叫流程中都能正確路由。必須檢查是否有重疊、缺少分配或配置錯誤,這些都可能導致呼叫路由錯誤或服務中斷。
PSTN通話流程與來電顯示
一個完善的驗收測試程序必須包含 PSTN 通話流程的端對端驗證。這包括呼入和呼出兩種情況。對於 PSTN 來電,測試團隊應確認通話是否已送達至預期的終端,無論是個人使用者、呼叫佇列、呼叫群組或自動話務員。必須成功撥出 PSTN 電話,尤其要注意正確傳遞和顯示來電顯示訊息。這包括確保按照組織政策和監管要求,向外部接收者顯示正確的來電者姓名和號碼。
測試還應涵蓋故障轉移場景,例如處理無法存取的端點或網路中斷。這有助於確認回退機制和備用路由是否正常運行,從而維持服務的連續性和可靠性。
網內呼叫流程
內部或網內呼叫流程構成了企業通訊的骨幹。該領域的驗收測試驗證了組織內使用者之間的通話是否正確路由,以及呼叫轉移、保持、轉送和會議等功能是否如預期運作。必須確認撥號方案的完整性、分機之間的連接性以及對組織呼叫策略的支援。
使用者呼叫處理和功能驗證
驗收測試的一個重要方面是驗證使用者如何使用 Webex應用程式和支援的 桌上型電話處理通話。此流程的重點是確認日常通話工作流程是否直觀可靠,以及使用者是否能夠無縫存取其角色所需的核心功能。測試應評估使用者撥打和接聽電話、管理保持和恢復功能以及執行盲轉和諮詢轉接的便利程度。此外,還必須確認呼叫轉移、電話會議和其他進階功能(如呼叫保留和恢復或啟用「請勿打擾」功能)是否可用且運作順暢。
應評估使用者體驗的清晰度和回應速度,並考慮使用者如何與通話記錄、語音郵件和整合目錄進行互動。還應特別注意在設備之間轉移通話的功能,以及在應用程式或實體電話上有效使用通話控制功能的功能。最終目標是確保遷移後最終使用者體驗的一致性、高效性,並能充分滿足組織的溝通需求。
呼叫佇列:代理人和主管經驗
呼叫佇列常用於處理大量來電的情況。這裡的驗收測試著重於以下幾個方面。首先,應驗證呼叫是否依照配置的佇列邏輯(例如輪詢、最長空閒或同時振鈴)指派給座席。必須檢查座席桌面上排隊呼叫的顯示方式是否清晰易用,以確保座席能夠有效率地接聽、保持和轉接通話。
對於主管人員來說,應該評估桌面體驗的功能,例如即時監控、呼叫介入以及佇列效能分析或洞察。這包括但不限於驗證提供有關呼叫分配、座席活動和佇列指標的可操作資料的儀表板和報告工具。
搜尋群組:呼叫分配
呼叫群組是將呼叫指派給預定義使用者集的關鍵機制。驗收測試需要確認呼叫是否根據配置的呼叫搜尋演算法路由到群組成員,以及是否依照設計處理溢位、轉送和無應答情況。確保群組成員關係和呼叫路由行為與先前在 Unified CM 中建立的關係一致,對於營運一致性和使用者滿意度至關重要。
自動語音應答:公告和選單操作
自動應答器代表了自動呼叫處理的第一道防線。測試必須涵蓋公告的播放、錄製問候語的準確性以及選單樹的正確操作。選單選擇應能可靠地將來電者路由到相應的部門、個人或外部號碼。測試還應包括無效或逾時場景,以確認呼叫者是否收到清晰的指導或按預期被重定向。
語音信箱操作
最後,語音信箱功能對使用者體驗至關重要。驗收測試應驗證語音信箱是否已正確分配,以及是否可以從組織內部和遠端存取。必須確認具備記錄、檢索和管理訊息的功能,以及通知送達功能。