ServiceNow Otto：企業不是缺聊天框，是缺一條能負責的行動路線

企業 AI 入口已經不稀奇。每個平台都能放一個聊天框，讓員工問政策、找文件、整理會議，甚至觸發一兩個任務。真正讓人卡住的不是「AI 會不會回答」，而是回答之後，工作要怎麼往前走。

一位客服主管問「這個客戶的合約能不能例外處理」，AI 給出答案還不夠。它要知道資料從哪裡來，是否要開 case，誰能批准，哪個系統要更新，最後是否留下紀錄。否則聊天框只是把問題說得更順，沒有讓公司變得更會做事。

這就是 ServiceNow Otto 值得寫的地方。ServiceNow 在 Knowledge 2026 把 Otto 描述成一個整合 conversational AI、autonomous workflows 和 enterprise search 的企業 AI experience。表面上它也是一個入口；但放在 ServiceNow 的大敘事裡，它其實是把提問接到 system of action。

企業 AI 最難的是回答之後

企業部署 AI 最常見的幻覺，是以為員工有了統一問答入口，生產力就會自然上升。但真正的工作不是問出答案，而是把答案變成流程中的下一步：建立 case、查權限、更新客戶資料、處理請款例外、升級資安事件、通知主管批准。

Otto 的訊號是，ServiceNow 不想只競爭「誰的 AI 入口比較聰明」，而是競爭「哪個入口能安全地把工作送進企業流程」。它同時談 AI Control Tower、Action Fabric、Autonomous Workforce、MCP Server，原因就在這裡：如果 agent 可以來自 Claude、Copilot、Google Cloud 或企業自建系統，ServiceNow 想做的是那個讓 agent 真的動手、又留下治理軌跡的層。

這也讓 Otto 和一般企業搜尋工具拉開距離。搜尋工具幫你找到資料；工作流平台要負責讓資料變成可追蹤的行動。對使用者來說，差別不是介面長得多漂亮，而是提出問題後，事情到底有沒有進入公司承認的流程。

Demo 好不好看，不如問五個問題

評估 Otto 這類平台，不該只看助理回答得多自然。更重要的是五個問題。

第一，答案來自哪裡：是否連到公司資料、文件、權限與即時流程狀態？第二，工作送去哪裡：是只生成建議，還是能建立、更新、關閉工作流？第三，誰批准：高風險動作是否需要人類 judgment？第四，誰負責：AI specialist 或 agent 是否有明確角色、部門與 owner？第五，如何稽核：錯誤、幻覺、越權、成本和價值是否能被追蹤？

這五題比「支援多少模型」更接近採購現場。模型可以換，聊天介面也會相似；真正難換的是企業流程、資料權限與稽核責任。

ServiceNow 想當 AI 動作的閘口

ServiceNow 的說法當然有供應商包裝。它引用的效率數字與客戶案例，需要被視為公司提供的案例，不是普遍 ROI 定律。Otto 也還需要看實際可用性、價格、整合深度和客戶上線成本。

但方向很清楚：企業 AI 的前台會越來越像聊天，後台卻會越來越像工作流平台。誰能把「問」接到「做」，再把「做」接到「可治理」，誰就有機會成為企業 AI 的日常入口。

Otto 的重點不是多一個 AI 助理，而是提醒企業：員工不缺另一個可以聊天的地方；他們缺的是一條公司願意承認、主管知道誰負責、IT 查得到紀錄的行動路線。聊天只是門面，受控行動才是價值。