在飛書裡運行服務台：香港與新加坡雙語 24×7 服務台運營指南

把服務台搬到員工本來就在用的聊天工具裡，聽起來是一步穩賺不賠的棋——直到你發現每一條消息都變成了沒有分類、沒有負責人、也沒有計時的裸request。 24×7 雙語服務台完全可以架在飛書或 Lark 裡運行，前提是每一條消息在到達的那一刻，就被自動、雙向地轉換成一張工單。這篇文章講的是當聊天窗口本身成為受理入口之後，運營模式會發生哪些變化，以及"一線解決率"這個數字在什麼條件下才站得住腳。

當整個公司都已經活在飛書或 Lark 裡，會發生什麼？

設想一家總部在內地的消費品牌，香港辦公室負責區域銷售與合規，規模更小的新加坡辦公室負責東南亞分銷。公司每個部門早就在飛書或 Lark 裡運轉——財務有自己的羣，物流有自己的羣，兩年前有人建了一個"IT求助"羣，此後從未被結構化管理過。這是一個用來說明問題的複合場景，不指代任何具名客戶。

這家公司當然也有工單系統。問題是香港和新加坡的員工幾乎不會主動打開它。飛書本來就整天開著，為了報修一台手提電腦再單獨切換到另一個系統登入，是沒人願意做的額外一步——除非電腦已經徹底罷工。於是IT請求就以這家公司處理所有其他事情的方式抵達：一條發在羣裡的消息，@上一次回覆過的那位工程師。

這不是在講某個供應商不給力，也不是在講某個IT團隊偷懶。這是一件必然會發生的事：當員工真正使用的受理渠道，和IT團隊真正用來考核自己的系統，是兩套完全不同的東西時，請求會在兩者的縫隙裡丟失、工作量會變得不可見、服務質量的爭論也會由此而起。

聊天窗口成為受理入口之後，具體改變了什麼？

把受理入口搬進聊天軟件，不是"同一套服務台換了個門面"這麼簡單。三件事會同時發生變化，每一件都會反過來影響服務台該怎麼運營。

請求量會上升，因為原本用來過濾請求的那點"門檻"消失了。 一個工單門戶天然帶著登入、表單、分類字段這類小摩擦，正是這點摩擦讓不少真正無關緊要的小麻煩從未變成一張工單。發一條聊天消息幾乎零成本。服務台一旦搬進聊天軟件，問題數量通常會明顯上升，如果人員配置和處理流程仍按門戶時代的量來設計，很快就會跟不上。

分診的時間點被提前了，落到了第一個碰巧看到消息的人身上。 在工單門戶裡，每一張新工單都會先經過分派員的眼睛才被安排下去。在一個羣聊裡，第一個注意到消息的人往往就是回覆的人——無論他是不是正確的負責人，無論一小時前羣裡另一個人是不是已經報過同樣的問題，也無論這件事本該被升級而不是被直接回答。

請求到達時，缺少了表單原本會強制要求提供的上下文。 一張工單表單會在你提交之前，先要你填上設備、地點、截圖和問題類別。一條聊天消息可能只是"我的電腦又不對勁了"——夾在一段完全不相關話題的第四條回覆裡。表單本該收集到的所有信息，事後都要靠再來一輪追問才能補齊，而這恰恰是聊天式受理原本想要避免的來回拉扯。

以上這些都不意味著把受理入口搬進聊天軟件是個錯誤方向。它意味著聊天界面下面需要一套機制，去補上一個工單門戶曾經自動替你做到、而一個未經改造的普通羣聊完全做不到的事。

想在聊天裡運營一個真正的服務台，哪些規則不能讓步？

四條規則決定了一個聊天頻道能不能真的支撐起一個服務台，而不只是掛了個IT頭銜的羣聊。少了任何一條，服務台都會悄悄退化回一個普通羣。

每一條消息都在發出的瞬間，自動變成且只變成一張工單。 不是"工程師覺得值得記錄就建一張工單"，而是每一條進來的請求——一個問題、一句抱怨、昨天那個問題的重複——在被任何人讀到之前，就已經拿到了工單編號。正是這一條規則，防止了請求被悄悄吸收進一段對話，然後隨著話題翻篇而徹底被遺忘。

一套經得起真實用戶考驗的分類體系，而不是在內部討論會上看起來很完整的那一版。 用戶不會準確地給自己的問題分類，也不應該被要求這麼做。用真實的請求模式反推出一份簡短的分類清單——硬件、帳號權限、應用軟件、網絡、入職/離職交接、"其他"——交給第一步的人工或自動分診來打標籤，而不是讓提問的人自己在一份看不懂的菜單裡挑選。

SLA計時從消息發出那一刻開始，而不是從工單被"認領"或"分配"給某個人那一刻開始。 這是最容易被悄悄做錯的一條。如果計時器只在工單被"接受"之後才啓動，那麼一條消息在忙碌羣聊裡未讀的每一分鐘，都不會被計入任何統計——結果就是,月度SLA報表可以做得很漂亮,與此同時飛書羣裡堆著好幾個小時無人回應的消息。計時必須從消息落地的那一刻開始,沒有例外。

每條工單都要留下一份在對話翻篇之後依然存在的書面記錄。 聊天本身是易逝的——三週前那條關於打印機的對話,如今已經被兩千條新消息埋在下面。每一張工單都需要有自己獨立、可追溯的記錄:問題是什麼、做了什麼處理、誰處理的、什麼時候關閉的。正是這份記錄,讓六個月後的月度報表、審計,或者一句"這個問題我們是不是早就修過了",都有據可查。

聊天原生受理、工單門戶優先、混合模式:三者到底該怎麼比?

• 聊天原生受理(消息自動變成工單): 完全貼合員工本來的工作方式,請求量能被完整捕捉,不會因為"懶得登入門戶"而丟失。它的風險在於,如果沒有自動轉換這一層,聊天會退化成一團誰都沒法拿來做報表的混亂記錄——真正起作用的是背後的機制,而不是渠道本身。
• 工單門戶優先(員工必須打開另一個系統才能報修): 能給IT一個乾淨、結構化的隊列,分類和優先級在一開始就被收集好,但相當一部分真實請求根本到不了這裡,因為對大多數員工來說,除非"電腦徹底開不了機",否則單獨登入一個系統的這點摩擦,足以讓人選擇不報。
• 混合模式(聊天用於上報,門戶用於追蹤,兩邊自動同步): 這才是真正適配一家飛書原生公司的模式——員工按自己習慣的方式上報,IT依然拿到一份結構化、可彙報的隊列,兩邊不需要任何人手動重複錄入就能保持一致。它的搭建成本比另外兩種純模式都高,也是三者之中唯一能在請求量增長之後依然撐得住的一種。

不靠三支獨立團隊,怎麼做到三語言的分流?

場景裡這家公司日常用三種書面語言溝通:總部用簡體中文,香港用繁體中文和英文,新加坡用英文。一個只能用其中一種語言回覆的服務台,要麼逼著每個提問者自己翻譯問題,要麼把所有請求都壓到唯一一個雙語瓶頸上處理——而這個瓶頸很快會悄悄變成整個服務台裡最慢的那一環。

務實的答案不是按語言拆成三支獨立服務台——那正好會重新製造出這家公司想靠統一到一個聊天平台來擺脫的碎片化。答案是一支真正的一線團隊,團隊內部對繁體中文、簡體中文和英文都具備接近母語水平的能力,並且排班能覆蓋所有需要的時段,再配上一條固定規則:用請求進來時使用的語言回覆,而不是當班工程師那個小時碰巧更順手的語言。博訊的24×7多語言服務台正是圍繞這個要求搭建的——普通話、粵語和英語支援排在同一套排班之內,而不是靠一位雙語工程師獨自撐起三個時區。

分類體系本身也必須做到與語言無關。無論"帳號權限"這條請求是總部用簡體中文發來的,還是新加坡用英文發來的,歸檔方式都應該一樣,這樣管理者查看月度分類統計時,看到的是同一張真實的全景圖,而不是三份需要人工對帳才能拼起來的碎片。如果你已經走到需要實際核實供應商多語言能力承諾的階段,而不只是在設計階段,可以參考我們核實真實多語言IT服務能力的清單,這篇文章講的正是簽約前該問哪些問題,這裡不再重複。

一個現實的一線解決率,到底應該長什麼樣?

90%以上的一線解決率是一位真實客戶在諮詢中提出的具體目標,值得認真對待——但它是用來反過來設計服務台的目標,而不是隨便配上一個聊天工具就自帶的勳章。三個問題決定了它到底能不能實現,還是隻是幻燈片上的一個數字。

"一線"到底怎麼算,和工單實際關閉的方式是不是一致? 如果一位工程師查了資料、在同一個聊天線程裡帶用戶走完修復流程、並且從未轉派給別人就關閉了工單,這就是真正的一線解決。如果一張工單掛了兩天,期間三個人在另一個私聊裡悄悄商量了半天才有人回覆,把這算作一線解決就只是一個統計口徑的選擇,而不是運營事實。度量方式必須追蹤工單記錄上實際發生的事,而不是關閉備註裡怎麼寫。

分類體系和知識庫,是不是真的匹配你實際收到的請求結構? 密碼重置、共享盤權限、打印隊列、已知的應用報錯——這些是可重複、有文檔可查的問題,一線團隊能很快處理掉。一個全新的硬件故障,或者供應商側的服務中斷,永遠不會是一線解決,一個不考慮這種請求結構的目標,要麼會因為錯誤的原因未達標,要麼會靠悄悄把難題重新歸類來"達標"。

一線團隊的人員配置,是按實際請求結構來的,還是請求量一高就被臨時抽調去支援別的事? 90%以上的目標,前提是一線排班裡有足夠多、掌握正確語言、在請求真正到達的時段在崗的受訓人員。如果同樣那兩位雙語工程師,同時也是被抽去處理二線升級的人,這個數字就會隨著"那一週誰剛好有空"而波動,而不是一個可以被規劃出來的穩定結果。

以上都不是說這個目標不現實,而是說這個數字首先是一個人員配置和分類體系的決策,其次才是一個工具選型的決策——一份認真的方案會講清楚它的前提假設,而不是把一個單一數字包裝成從第一天起就有保證。

聊天成為受理入口之後,"24×7"實際上指的是什麼?

"24×7"這個說法背後其實是兩種完全不同的東西,而當請求可能在香港時間凌晨兩點抵達——因為總部那邊剛好在收尾一天的工作——這個區別就變得更重要了。

follow-the-sun(跟隨太陽)模式讓服務台隨著地球自轉,在各個有人值守的區域團隊之間交接,保證每個小時在某個地方都有一支真正在崗、齊裝滿員的班次。待命(on-call)模式則是一支規模更小的班後團隊保持可聯繫,但不是持續在崗,而是被呼叫之後才響應,不會實時盯著頻道。follow-the-sun很適合應對穩定但不可預測的請求量;待命模式是為真正的緊急事件設計的,不是為了處理日常聊天流量——一個夜間只有待命覆蓋的聊天頻道,會悄悄積壓起一堆未回覆的消息,第二天早上看起來,恰恰就是這整套方案本來想要解決的那個問題。

我們在《亞洲24×7多語言服務台指南》裡更詳細講過follow-the-sun交接和SLA分級怎麼運作;這裡只講當交接真正發生的地方從門戶變成聊天窗口之後,有什麼不一樣。

到底該選哪種模式,本質上是一個人員配置決策,只是被包裝成了一個覆蓋時段的決策。follow-the-sun排班需要每個區域都有足夠多、經過訓練的雙語一線人員,真正撐起那個"在崗"的班次——而不是名義上有一個人在班、實際在做別的事——夜間請求量穩定的公司才最值得為此買單。待命模式配置成本更低,但應該配一條明確規則:一條深夜未讀消息至少要拿到什麼。最低限度是,工單一旦生成,系統就在聊天線程裡自動確認收到,讓香港時間凌晨兩點發消息的那個人知道,自己的請求已經變成了一張工單,即便實質性的回覆要等到下一個在崗班次才會給出。

這和"這家公司到底需不需要全天候覆蓋"是兩個不同的問題,各自有各自的取捨。這裡預設答案是需要的,因為場景中這家公司的聊天頻道本來就從不真正關閉;還懸而未決的,是這24小時裡哪些時段需要一個真人在崗、實時回覆,哪些時段只需要一句確認收到。

一條聊天消息什麼時候該變成一次現場派遣,而不是一句回覆?

有些請求無論服務台運營得多好,都沒法在一個聊天線程裡解決——一台故障的交換機、一段斷掉的佈線、一次實體硬件更換。這裡不能讓步的一點是:升級為現場上門,必須是發生在同一張工單記錄裡、清晰可見的一步,而不是另起一段對話、換一個人重新說一遍。分類標籤、歷史記錄和SLA計時都要跟著工單一起進入派遣流程,而不是因為工作從聊天窗口轉移到了技術員的車裡就重新歸零。博訊公開的現場派遣SLA分級——覆蓋標準工作時段、延長工作時段和24×7緊急響應下的到場時限——存在的意義正是讓這次交接綁定一個雙方認可的計時器,而不是一句沒有邊界的"會有人過去看看"。

哪些事情本來就不該放在聊天線程裡處理?

聊天的優勢是快,而這恰恰是有些請求類別必須刻意排除在外的原因。權限審批——開通一項新的系統權限、恢復一名離職員工的帳號、批准安全策略的一次例外——需要一條有名有姓、可審計的審批鏈路,而不是羣聊裡一個劃過螢幕就消失的點贊表情。任何改變"誰能進入某個系統"而不是幫某個人用好已有權限的請求,都應該走進一個記錄能留存得比聊天記錄更久的流程。一個聊天原生的服務台,應該在識別出這類請求的第一時間就把它導流到正規的審批流程裡去,而不是因為它恰好是從聊天裡進來的,就試圖在同一個線程裡把它解決掉。

這如何嵌入一套更完整的管理型IT方案?

一個聊天式服務台是一段更完整支援關係裡的一環,而不是一個獨立產品。它建立在與管理型IT服務相同的基礎之上——監控、打補丁、當一段聊天對話升級為現場動手時的派遣——也遵循同一套報表紀律,這是任何一個可信的服務台都應該做到的,無論它是不是聊天式的:按分類統計的月度請求量、響應與解決時長,以及一個說清楚自己在統計什麼的一線解決率。博訊的按人頭計費的管理型IT方案按每用戶每月計費,香港地區起價為1至5人規模的855.14港元,隨人數與服務範圍擴大逐級上升到1247.40港元和1561.21港元——完整信息見價格頁面。如果你正在評估一個聊天原生的服務台方案,是否適合一家以飛書或Lark為工作平台、在香港和新加坡都設有辦公室的公司,歡迎聯繫我們的團隊,具體聊聊針對你的請求量,分類體系、人員配置和SLA該怎麼設計。

常見問題

飛書或Lark真的能取代工單系統嗎?

單靠它自己不行。飛書和Lark在它們本來的定位上非常出色——快速、原生的溝通——但一款聊天軟件本身並沒有工單、SLA計時、分類或者可追溯的關閉記錄這些概念。真正取代工單系統的,是"聊天軟件作為受理入口"加上"一層自動化,把每一條消息在到達的瞬間轉換成一張結構化工單"這兩者的組合。少了這一層,你得到的只是一個反應極快、但毫無結構的羣聊。

怎麼防止請求在熱鬧的羣聊裡被悄悄丟掉?

辦法是乾脆取消"丟掉"這個選項:每一條進來的消息在被任何人分診之前,就自動拿到一個工單編號,不依賴任何人恰好在一段不斷刷新的對話裡注意到它。再配上一條規則——沒有明確的解決說明,工單不能關閉——以及每天檢查有沒有消息沒有生成對應工單,這種情況通常說明自動捕獲漏掉了某個頻道或某種消息格式,需要從源頭修復,而不是每天靠人工去補漏。

這樣一個服務台,現實中的一線解決率應該是多少才合理?

完全取決於請求結構,以及"一線"這個詞到底是怎麼被定義的。如果一個服務台處理的大多是可重複、有文檔記錄的問題——密碼重置、權限申請、已知的應用報錯——並且配備了足夠多、受過訓練的雙語一線工程師,把目標定在較高水平,包括90%以上,是現實的。如果同樣的目標套用在一個大量是全新硬件故障或依賴供應商解決的請求結構上,或者用一個允許多天、多人蔘與的工單依然算作"一線"的定義去統計,那就不是一個目標,而是一個為了在幻燈片上好看而挑出來的數字。

不靠三支獨立團隊,怎麼處理三種書面語言?

用一支真正的一線排班團隊,內部對你的業務需要的三種語言都具備接近母語的能力,並配一條固定規則:用請求到達時使用的語言回覆。底層再配一套與語言無關的分類體系,這樣報表也不會因語言而碎片化——管理者查看月度工單量時,看到的應該是一張分類清晰的全景圖,而不是三份需要人工對帳的碎片。

聊天式服務台真的能支撐24×7覆蓋嗎?

可以,但前提是你清楚自己在用哪一種模式。follow-the-sun覆蓋——每個小時在某處都有一支在崗的班次——確實能穩穩接住夜間穩定的聊天流量。待命模式——一支更小的團隊被呼叫才響應,而不是實時盯著頻道——是為緊急事件設計的,不是為日常流量設計的,如果拿它來做follow-the-sun該做的事,夜間未回覆的聊天消息會悄悄堆積起來。

如果有員工還是更習慣發郵件而不是發聊天消息呢?

一套設計得當的受理層,應該把郵件當作匯入同一條工單流水線的另一個渠道,而不是逼著每個人都只能用聊天。分類、SLA計時和記錄留存的規則在兩種渠道下應該完全一致——請求從哪個渠道進來,不應該改變它被度量和彙報的方式,只會改變提問者發出請求時的體驗。

聊天式服務台實際上是怎麼被審計的?

方式和任何服務台一樣:靠每條消息生成的那份可追溯工單記錄,而不是靠聊天記錄本身。一份月度導出——創建時間、分類、是一線解決還是升級處理、關閉說明——讓管理者或外部審閱者能夠獨立重新核算請求量和解決率,這正是讓一份SLA報表可以被核實、而不只是被信任的那套紀律。

如果公司用的是Microsoft Teams或Slack而不是飛書、Lark呢?

這裡講的運營模式,並不依賴公司統一使用的是哪一款聊天軟件。那些不能讓步的原則——消息自動生成工單、經得起真實用戶考驗的分類體系、從消息發出那一刻開始計時的SLA、留存在聊天線程之外的可追溯記錄——無論受理入口是飛書、Lark、Teams還是Slack,都同樣適用。真正因平台而異的,是實現自動消息捕獲所需要的集成工作,而不是服務台本身的設計。