在飞书里运行服务台：香港与新加坡双语 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,都同样适用。真正因平台而异的,是实现自动消息捕获所需要的集成工作,而不是服务台本身的设计。