Slack 上的 ConnectWiz

搶先體驗

Slack 上的訊息,背後有一套真正的流程在回答。

來自 Slack 的訊息,會落進和其他管道同一個已分流、有 AI 協助的收件匣——配上 Slack 應得的安全工程,而目前的適用範圍也照實說明:文字對話,搶先體驗中。

入站已驗證、已簽章 同一個收件匣,同一套 AI 範圍是明說的,不是暗示的
Slack——客戶對話
#help:嗨,各位——export API 從今天早上開始一直回 429 🙏
Deniz · 工程部
確認了——是我們這邊速率限制設定錯誤。修正正在部署,預計 20 分鐘。一驗證完成我就回報在這裡。
已橋接進收件匣 簽章已驗證 已分流給工程部
2
串接時用到的密鑰數——bot token 會即時向 Slack 驗證,簽署密鑰負責證明入站事件
300 秒
重放窗口——超過五分鐘的事件會被拒絕,不會被信任
0
機器人迴圈——我們自己的回音和機器人事件,在能乒乓之前就被丟掉
1
收件匣——Slack 對話就在 WhatsApp、電子郵件和其他所有東西旁邊

為什麼選這個管道

Slack 為什麼該在客服堆疊裡

B2B 早就住在那裡

您最大的客戶在 Slack 裡問問題,因為他們就在那裡工作——到那裡接住他們,對他們來說是高規格待遇;有了橋接,對您來說也依然井然有序。

比管道活得更久的歷史紀錄

客戶的 Slack 頻道會被封存、被改名;ConnectWiz 的紀錄不會。在 Slack 裡許下的每一個承諾,都留在客戶的永久歷史上。

內部服務台也可以

有些團隊把 IT、人資和營運頻道橋接進同一條佇列——內部需求一樣有分流、歸屬和歷史紀錄,機制完全相同。

串接與安全

照管道的規格去做,而不是像外掛一樣硬接上去

每一個 Slack 事件在碰到對話之前,都會先經過密碼學驗證和去重——正是這些無聊的保證,讓一座橋值得信任。

抽象 3D 插圖:一塊紫色的井字號方磚和一個對話泡泡,透過一個發光的盾形檢查哨相連

兩把密鑰,兩把都檢查

bot token 在任何東西存下來之前,就先拿去 Slack 的 auth API 驗證;簽署密鑰則負責證明每一個入站事件——Slack 的挑戰握手會自動應答。

入站有密碼學保證

每一個事件都對原始請求主體做 HMAC 驗證——Slack 的 v0 方案,以定時比對——外加 300 秒的重放窗口,所以一個被側錄的請求,事後再射一次也沒有用。

靠過濾避開迴圈

機器人事件和我們自己的回音,在進對話串之前就被丟掉——橋接最經典的故障(兩個機器人永遠互相回覆)在門口就被濾掉。

回覆回到它出發的地方

每一則外送回覆都會貼回訊息來的那個私訊或頻道——位址在聯絡人上保持最新,從來不靠猜。

收件匣

從第一則訊息起,就享有收件匣的全部能力

已分流的對話

Slack 訊息會以對話的形式進來,帶著部門分流、指派、標籤、可以 @ 提及的內部備註和完整歷史紀錄——桌機和客服行動 App 上都有。

先由 Wiz 回覆

AI 客服會用您自己的內容以 52 種語言回覆,轉真人時把整段對話一併帶過去,真人一鍵就能交還——和其他管道共用同一顆大腦。

一筆客戶資料

Slack 身分會併進和電子郵件以及其他所有管道同一筆 CRM 聯絡人——一個人、一份歷史紀錄、一個同意狀態。

雙向翻譯

客服人員可以隨時用自己的語言讀來信,草稿也會先翻成客戶的語言再送出——逐則處理,並為下一位閱讀的人快取起來。

認得營業時間

非上班時間的訊息會得到誠實的預期說明,並排在隔天早上佇列的最前面;首次回覆時間衡量的是真人,不是機器人。

文字,穩定可靠

目前的適用範圍是雙向文字訊息——透過 Slack 官方 API 送出,在對話上留下紀錄,絕不會無聲消失。

技術細節

讓「搶先體驗」能放心跑起來的底層機制

恰好處理一次

每一個事件在處理之前,都會在專屬帳本裡認領一個唯一鍵;Slack 的重試和重複事件會在資料庫層被認出來並丟掉——一則訊息絕不會變成兩則。

和其他一切共用同一套流程

入站走的是元件和 WhatsApp 在用的那個訊息服務——分流、AI 觸發、封鎖和歷史紀錄的行為完全一樣,因為它們本來就是同一套。

失敗會被指名

被拒絕的發送會把訊息標記為失敗,並在對話串上寫明原因——絕不默默消失,也絕不給一個假的勾。

不發明不存在的限制

Slack 沒有公布硬性的文字長度上限,所以我們也不加一個——發明出來的限制,會擋掉今天其實送得出去的訊息;誠實這件事是雙向的。

不加修飾的適用範圍

這裡說的「搶先體驗」是什麼意思——白紙黑字

和您一起開通,而不是替您決定

整合已經做好並通過驗證,但還沒有承載足夠的真實生產流量,不足以無條件標示為「已上線」——所以我們按工作區逐一開通,團隊全程在旁邊。徽章代表的就是這個狀態。

目前只有文字

媒體、按鈕和豐富元素都還在藍圖上,我們刻意不做承諾——一個頁面去推銷還不存在的編輯功能,失去的信任比賺到的多。

樂觀送達

送出會在 API 層級得到確認;這個管道還沒接上逐則的送達回條,對話介面也不會假裝有。

一個手動步驟

Slack 沒有提供註冊事件網址的 API,所以把 Request URL 貼進您的 Slack 應用程式設定,是一次性的手動步驟——我們的指南會明確指出位置。

藍圖與畢業條件

接下來會做什麼,以及徽章什麼時候翻轉

畢業的標準是實測,不是行銷:要有足夠的真實生產流量,把管道端到端驗證一遍。做到之後徽章拿掉,下面這些依序落地。

媒體與檔案

雙向附件是畢業清單上的第一項——沒上線之前不做承諾,而且寫在這裡,不是含糊帶過。

更深的身分對應

客服人員與 Slack 使用者之間更深的對應,以及逐客戶的頻道結構,正在和搶先體驗的團隊一起研究——把您的配置告訴我們。

送達回條

這個管道還沒接上逐則的回條;送出會在 API 層級得到確認,對話介面也不會假裝有。

標準管道

費用

ConnectWiz 這一側

  • Slack: 標準管道,計入方案內含的管道名額,也可以每月 $9 加購開通——搶先體驗期間同價
  • 搶先體驗多給人手:開通和盯著跑都和您一起做,不額外收費
  • 對話會計入方案的一般對話額度,AI 回覆則消耗 AI 額度
查看 ConnectWiz 方案

Slack 這一側

您的 Slack 帳號、認證,以及任何平台端的條款,都是您和 Slack 之間的事——ConnectWiz 不加價,也絕不代理您的帳號關係。

Slack FAQ

直接的回答

更多內容見完整的 FAQ, 也可以直接聯絡我們。

整合已經做好,入站路徑也完成加密驗證,但還沒有承載足夠的真實生產流量,不足以讓我們無條件標示為「已上線」。所以我們按工作區逐一開通,團隊全程在旁邊——聯絡我們,一起把它打開。

雙向文字對話,收件匣該有的能力一樣不少:部門分流、指派、標籤、歷史紀錄,以及 Wiz AI 回覆。媒體和豐富元素還在搶先體驗的藍圖上,沒上線之前我們刻意不做承諾。

條件是真實生產流量:等真實工作區把這個管道跑出足夠的量、整合行為端到端得到驗證,徽章就會拿掉,藍圖上的項目(媒體、更豐富的元素、送達回條)也會逐一落地。標準是實測,不是行銷。

橋接的運作層級是訊息:只要送達已串接工作區的私訊或頻道,就能流進收件匣並被回覆。結構化的逐客戶頻道對應,是我們正在和搶先體驗團隊一起探索的方向——把您的配置告訴我們,我們會誠實評估合不合適。

Slack 是標準管道——每月 $9 加購,或佔用方案內含的一個管道名額——而在搶先體驗期間,由我們的團隊陪您一起開通,價格相同。Slack 本身不為這座橋收費。

您最大的幾個客戶,早就住在 Slack 裡。

申請搶先體驗,我們和您一起把管道開起來——從第一天就把適用範圍說清楚。