Five9 收購 Level AI 開闢超越自身聯絡中心平台的途徑
Five9 於 11 月 5 日簽署協議收購 Level AI,讓公司毋須先更換客戶的聯絡中心平台,也能銷售 AI。Five9 收購 Level AI 擴大其產品組合,亦改變公司可參與競爭的範圍。其擬定的切入點將是購買應用程式,而非遷移平台。
對希望改善客戶服務工具、同時保留既有基礎設施的企業而言,這項分別相當重要。Five9 表示,Level AI 應用程式將繼續作為獨立產品,供使用其他平台的客戶採用。這讓企業可在現有環境中導入 AI,或選購更全面的聯絡中心系統。
競爭對手 NiCE 早前收購 Cognigy,為這種結合既有分銷能力與收購 AI 應用程式的做法提供了有用參考。不過,Five9 的即時機會在於,在客戶考慮轉換平台前便接觸他們。尚未解決的問題是,公司能否在推廣自身軟件的同時,有說服力地支援這些客戶。
Five9 收購 Level AI 實際改變了甚麼
Five9 正在收購一個更廣泛的企業客戶切入點,同時取得額外的 AI 能力。
公司的收購協議將收購目標列為 Ujwal,即以 Level AI 名義營運的公司。根據擬議交易,Level AI 將成為全資附屬公司。交易完成仍須符合交割條件。
這項分別將已獲確認的事件,與部分將收購描述為已完成的新聞標題區分開來。已確認的行動是簽署協議。收購協議確立預期的所有權變更,但不代表客戶已經擁有整合後的產品。
Five9 的獨立 AI 策略描述了可獨立提供、亦可在其 Genius CX Platform 內提供的應用程式。兩家公司自 2022 年起一直合作。現有合作關係為此次收購奠下基礎,但並未確定未來的產品路線圖。
Level AI 的產品組合包括座席協助、對話分析、指導及品質管理;品質管理會按既定標準評估服務互動。這些能力不僅限於自動化對話,也涵蓋客戶結束交談後,主管及營運團隊所進行的工作。
策略上的改變關乎接觸渠道。使用另一套聯絡中心系統的潛在客戶,在考慮這些應用程式前未必需要啟動遷移項目。這減少了首次採購所附帶的決策數量。
對買家而言,這項分別影響誰需要批准項目。應用程式評估可聚焦於明確的營運問題。更換聯絡中心平台則會引入一場更廣泛的討論,涉及基礎設施、工作流程、培訓及服務延續性。
這並不代表部署應用程式毫不費力,而是改變了首次決策的範圍。Five9 有機會先由營運團隊的問題入手,而毋須要求企業重新考慮整個通訊環境。
此次收購亦令責任更接近 Five9。市場平台合作關係讓公司可協調運作,同時保留各自的優先事項。擁有所有權則可讓工程及銷售工作更一致,但亦須承擔處理重疊產品與客戶承諾的責任。
因此,客戶需要區分現有整合與未來整合承諾。已可連接 Five9 的應用程式,並不代表已有統一的管理體驗,亦無法說明未來版本將如何與其他平台運作。
相關改變在商業及組織層面與技術層面同樣重要。Five9 希望建立另一條進入客戶帳戶的路徑。這條路徑能否保持吸引力,取決於隨後的產品及支援選擇。
企業買家可選擇不遷移平台
將 AI 採購與平台更換分開,讓買家有更大空間界定希望解決的問題。
設想一間服務機構希望了解客戶為何反覆聯絡支援團隊。其當前問題涉及對話分析及後續跟進。更換分派來電的系統,未必能直接解決該問題。
獨立應用程式可帶來範圍較窄的評估。機構可檢視軟件能否識別重複出現的問題、提供有用證據,以及協助員工回應。在評估期間,現有聯絡中心可繼續作為營運環境。
這是假設性的採購情境,並非已報道的 Level AI 客戶成果。其相關性來自收購案擬定的分銷模式。Five9 明確瞄準希望採用應用程式、而毋須先導入其聯絡中心平台的企業。
這種模式促使賣方說明每一層的價值。平台供應商必須展示更深度整合為何能改善成果;應用程式供應商則必須說明,為何獨立產品值得增加另一套部署及支援關係。
買家應歡迎這項分別,但不應假設獨立部署自然等於更簡單。資訊仍需在系統之間流動。當出現問題時,安全團隊仍須了解存取權限、保留安排及責任歸屬。
應用程式亦必須融入員工的日常工作。若座席需要到其他地方搜尋,準確的建議便會失去價值。有用的對話摘要需要明確的去向及負責人。
營運主管亦面對相關負擔。他們需要決定哪些發現值得採取行動,哪些只是一般波動。若只增加分析而不改變該決策流程,便有可能產生另一條無人閱讀的建議佇列。
更廣泛的知識問題並不陌生。團隊需要一個可搜尋的知識庫,將證據與決策連結起來。客戶服務還須顧及權限、客戶紀錄,以及錯誤建議可能帶來的後果。
收購公告是在既有增長故事之下發布。Five9 的季度業績顯示,第三季收入增長 13%,訂閱收入增長 16%。其指引未計入待完成的 Level AI 收購所帶來的貢獻。
這些披露提供的是基線,而非收購效益的證明。現有增長屬於交易完成前的業務。未來報告需區分收購所得的業務活動,與核心營運的變化。
對企業買家而言,這種區分很重要,因為財務動能無法回答部署問題。供應商即使正在增長,仍可能需要進行困難的整合工作。一次成功收購亦可能令客戶仍在等待特定功能。
實際機會在於選擇。買家可先評估應用程式是否解決明確問題,再考慮較大型的平台決策。Five9 必須在整個銷售流程中令這項選擇具備可信性。
跨平台銷售帶來不同的競爭負擔
Five9 擬定的應用程式策略,要求公司服務其無法控制的環境。
這與只為自身客戶改善軟件相比,帶來不同責任。外部平台具有不同介面、發布時間表、管理規則及支援邊界。要令這些連接保持實用,需要持續投入。
NiCE 提供了一個相關的業界比較。其收購 Cognigy已於 2025 年 9 月 8 日完成。該組合將成熟的客戶體驗供應商,與對話式及代理式 AI 結合;後者是指設計用來執行任務的系統。
這個比較並不代表交易將產生相似結果,而是展示了將應用程式專長帶進更大型分銷機構的一條收購路徑。產品相容性及客戶採用仍是不同問題。
Genesys 透過其編排生態系統提供另一項參考。2026 年 9 月,該公司宣布與 AWS、Salesforce、ServiceNow 及 Sierra 等公司合作。編排是指協調客戶旅程中的系統與行動。
這些例子將 Five9 放在活躍的競爭領域之中,但並未證明產品質素的排名。買家仍需比較與其業務相關的具體功能及營運條件。
Five9 的獨特問題,是應用程式獨立性與平台所有權之間的關係。獨立客戶希望在現有環境中獲得可靠服務,而 Five9 同時有興趣提升自身平台的吸引力。
這些利益可以並存。更好的應用程式可在毋須即時遷移的情況下創造收入及建立客戶關係。對希望採用的客戶而言,更深入的原生整合仍可是一個選項。
當優先事項出現分歧時,張力便會浮現。工程團隊必須決定新功能優先在哪裡推出;銷售團隊則須決定獨立部署是成功成果,還是尚未完成的平台銷售。
客戶將透過日常產品細節感受到這些決定。連接器維護、支援回應速度、文件及功能可用性,將比關於開放性的宏觀說法更重要。長期一致性將建立可信度。
因此,使用其他平台的買家應詢問產品承諾如何適用於其環境。關鍵在於所需能力能否獲得可靠支援。單憑所有權無法回答這個問題。
原生客戶則有不同顧慮。他們希望收購能改善體驗,而非引入另一個重疊的應用程式。更廣泛的產品目錄,只有在用戶清楚每項產品負責哪些工作時才會創造價值。
因此,Five9 在其擬定模式的兩方面都面對責任。它需要足夠整合以改善平台產品,同時亦需要足夠獨立性,令獨立業務值得考慮。
Five9 收購 Level AI 令這種平衡成為公司競爭定位的一部分。其覆蓋範圍將部分取決於客戶是否信任其跨越平台界線的能力。
對話智能必須導向可追責的行動
只有在有人能運用發現改善服務時,分析更多對話才會創造價值。
對話智能意味著從客戶互動中提取結構化資訊。下一個重要步驟,是決定這些資訊會帶來甚麼改變。反覆出現的投訴,可能需要培訓、修訂政策、修復產品,或進一步調查。
這些回應屬於不同團隊的職責範圍。主管可以處理客服人員應對困難來電的方式。然而,同一位主管未必有權修正引發重複投訴、令人困惑的帳單政策。
因此,當資訊在系統中流轉時,應用程式需要保留相關脈絡。一項發現應持續連結至原始互動,以及用於分類的準則。否則,員工便只能盲目相信結論,或重新進行分析。
Five9 將 Gusto、Chime、Empyrean 和 VistaPrint 列為 Level AI 的現有客戶。該公司亦表示,Level AI 每年處理逾十億宗客戶互動。這些公司披露顯示產品已投入使用,但並不能證明所有客戶均取得同等成果。
這個區別很重要,因為互動量只是活動指標。它無法顯示客戶問題是否獲得正確解決,亦不會揭示員工在根據建議採取行動前進行了多少審核。
企業評估應區分偵測、建議和執行。偵測反覆出現的問題,涉及尋找相關證據;建議回應則需要套用政策,而執行則牽涉權限與後果。
系統可以在其中一個階段表現良好,卻在另一個階段遇到困難。準確分類並不保證退款決定恰當。一份有用的回覆草稿,也不代表系統應在未經審核下自行發送。
只要職責保持清晰,這便為協調一致的產品帶來機會。人類員工可以審核敏感決定,而軟件則處理界定明確的分析工作。價值取決於這種分工的質素。
具體評估可追蹤一項反覆出現的送貨投訴,從原始對話一直到最終的營運回應。審核人員可檢視系統是否保留了相關細節,以及是否將發現恰當地轉交處理。這仍然是一個評估例子,而非聲稱已部署後取得的成果。
同一方法亦有助揭露薄弱的自動化。能產生流暢摘要的系統,可能遺漏客戶其實已聯絡過支援團隊這一事實。分析工具可能正確歸類投訴,卻無法識別應由誰回應。
這些失敗很重要,因為它們只是轉移工作,而非消除工作。員工其後仍須核實摘要、重建遺失的脈絡,並修正轉交安排。可見輸出可能有所改善,但整體流程仍然令人沮喪。
當應用程式協助團隊完成這整條工作鏈時,Five9 的收購理據便更具說服力。單靠更長的功能清單,無法證明這項好處。買方需要看到證據,顯示分析如何導向恰當且可追溯的回應。
這亦是平台整合可證明其價值的地方。共享脈絡及清晰交接可減少重複工作。整合應展示這些好處,而不應依賴「共同擁有權自然會帶來好處」這個假設。
整合計劃及模型聲稱仍需審視
既有合作關係可減少陌生感,但無法解決共同擁有權所帶來的決策問題。
Five9 與 Level AI 已熟悉彼此的產品。這有助解釋交易的邏輯,但並未消除有關產品重疊、管理、客戶支援或未來開發優先次序的疑問。
Dom Nicastro 的產品整合報道突出了能力重疊的問題。報道亦引述管理層的看法,指 Level AI 可加快產品路線圖進度。這仍是管理層的預期,而非已完成整合的成果。
持懷疑態度並不需要假設這宗收購必然令人失望,而是要將意圖與交付成果的證據分開看待。收購可以增強工程能力,同時仍需時間才能帶來連貫的客戶體驗。
現有客戶需要清楚了解持續性安排。他們需要知道現行工作流程會否繼續受支援,以及日後變更將如何溝通。即使底層技術仍然有用,模糊的過渡安排亦可能延遲採用。
產品重疊尤其值得關注。若應用程式執行相似工作,買方需要理解預定方向。否則,他們可能正在評估一套在部署過程中角色會改變的軟件。
模型效能聲稱帶來另一項不確定性。Five9 將 Level AI Latitude 描述為專為客戶對話而設的專有模型系列。該公司表示,其成本及延遲均低於前沿模型。
延遲是指系統作出回應前的等待時間。前沿模型是定位於能力前列的通用系統。兩個標籤都沒有提供足夠細節,讓買方判斷特定客戶服務工作負載的適用性。
有意義的比較需要在相符條件下進行。評估人員需要檢視相同工作、等同的質素要求,以及完整工作流程。若員工需要更頻繁地修正結果,更快的回應價值有限。
準確性亦需要與工作相關的定義。一份摘要可能保留了主要投訴,卻漏掉重要的同意限制。一項建議可能聽起來合理,卻套用了錯誤政策。
這些是評估風險,並非 Level AI 已被記錄的失敗。公開的收購材料並未為每個擬議使用案例提供獨立的比較結果。讀者應將相關效能說法視為公司聲稱。
資料管治亦需要同樣嚴謹的態度。有關客戶控制權的說法,應引向有關儲存、存取、刪除及次要用途的具體答案。買方需要針對自身部署取得這些答案,而不是停留在抽象的產品類別層面。
支援外部平台會增加另一層審核。每項連接都會在供應商與客戶系統之間建立邊界。當遺失脈絡或資料流中斷影響建議時,清晰的責任歸屬至關重要。
最有力的證據,會結合產品文件及客戶對實際運作的說明。有用的說明應解釋工作負載、限制、人為審核及量度結果。籠統的效率聲稱幫助較小。
這些問題並不否定收購的策略邏輯。它們界定了把更廣泛產品組合轉化為可靠企業軟件所需完成的工作。
三個訊號將顯示策略是否奏效
下一步發展應依次確認交易完成、產品承諾及客戶採用情況。
第一個訊號是正式完成交易的公告。Five9 預期於 2026 年第四季完成交易。協議亦規定,在特定情況下可於 2027 年 2 月 5 日終止。
較後的日期屬合約條款,而非承諾的完成日期。在確認完成交易前,讀者應區分擬議的擁有權結構與現行營運安排。任何重大延誤亦會影響整合時間表。
第二個訊號是具體的產品路線圖。買方需要具名功能、支援環境及可用性承諾。這些細節將顯示 Five9 如何平衡其原生平台與獨立應用程式。
可信的路線圖應令產品之間的關係更易理解。它應說明客戶現時可部署甚麼,以及甚麼事項仍有待進一步工程工作。清晰的支援承諾將加強市場對擬議分銷模式的信心。
模糊的套裝安排會削弱這種信心。外部平台是否會獲持續開發的不確定性亦然。核心問題在於,買方能否在現有環境中作出可靠的採購決定。
第三個訊號是來自 Five9 現有平台客戶以外的採用證據。新的客戶案例應說明企業為何選擇獨立應用程式,以及部署後的結果。這些案例將直接測試該策略更廣泛的觸達能力。
財務報告可提供背景,前提是定義保持清晰。已收購業務的收入與既有產品的變動,應在披露時可作區分。整體 AI 增長本身無法證明哪一條客戶接觸路徑正在成功。
營運證據亦應獲同等重視。買方需要知道員工是否使用這些應用程式、發現是否促成行動,以及服務成果是否改善。合約公告可證明需求,但持續使用則提供另一類證據。
這些訊號亦應一併評估。交易完成確認擁有權,路線圖澄清意圖,而採用情況則測試商業主張。沒有任何一項能獨立證明整個策略有效。
對企業團隊而言,眼前的回應是在擴大評估前,先界定希望改善的工作流程。問清楚證據源自何處、誰會審核建議,以及軟件可採取哪些行動。在應用程式的價值變得清晰前,應將既有平台的決策分開處理。Five9 收購 Level AI 值得關注,因為它提供更廣泛的採購途徑。隨着承諾轉化為獲支援的產品及有文件記錄的客戶成果,其價值將更容易判斷。留意交易完成公告、審視路線圖,並尋找同時說明限制與成果的部署案例。這項擬議應用程式,能否在你打算保留的環境中解決你的服務問題?



