易歪歪eyy如何设置客服离线时的消息自动回复？

一、先把问题说清楚：离线时段的漏回复发生在哪一环

凌晨两点，一位客户在商品页点开客服窗口，打下“现在下单什么时候发货”。消息发出去了，界面没有任何异常提示。但此刻整个客服团队没有一个人在线，这条消息就静静躺在待接入列表里，直到第二天上午九点才被看到。类似的情形在节假日、交接班的空档、突发流量高峰时反复出现。要解决它，先得弄清它卡在哪个位置。

从系统角度看，一条客户消息进入后大致会经历“接收—排队—分配—接待—归档”几个环节。漏回复几乎不会发生在接收环节，而是卡在分配：系统找不到可接手的在线客服，消息就一直排队。此时客服离线时的消息自动回复起到的是承接与分流作用——它不解决问题本身，但让等待变得可被感知、可被管理。运营者需要接受的第一个事实是：它的目标是降低流失，而不是替代服务。

1.1 三类“离线”，性质完全不同

很多人把“离线”当成一个状态，实际至少可以拆成三种，而它们对应的处理方式并不通用。无人值守型指排班表上本来就没人，比如夜间与法定假日；临时离开型指客服在岗但暂时离开工位，比如午休或处理其他工单；容量溢出型指客服在线但会话已排满，新消息进不来。三者的客户体验和应对策略差别很大，自动回复在其中的价值也完全不同。

无人值守型是最适合自动回复的场景，因为你的目标本来就是明确告知“现在没人”。临时离开型更适合用超时未响应机制来处理——客户可能几十秒后就等到人，此时弹一条“客服已离线”反而显得服务混乱。容量溢出型则要格外小心：客户其实排得进队，只是要等，如果系统把它判定为“离线”并推送离线话术，客户容易误以为当天无人处理而直接流失。

1.2 自动回复能解决什么，不能解决什么

它能解决的是“消息没有回应”带来的焦虑，能明确给出下一次服务的确定性时间点，能让客户在等待期间用自助方式（例如回复订单号查询）获得一部分信息。它解决不了的是理解问题本身：除非你额外配置关键词规则或知识库，否则它不会判断客户问的是哪类订单、也不区分咨询与投诉。

这一点值得反复强调。经验性观察是，把自动回复当成“夜间客服”的团队，最终往往在复盘时发现夜间转化率并没有提升，真正提升的只有客户投诉中“没人理”这一类抱怨的比例。定位清楚，后面的取舍才有依据。

二、功能定位：自动回复家族里的四类机制

在客服系统里，“自动回复”通常是统称，底下有几种触发时机与目标都不相同的机制。把它们混在一起配置，是导致“客户被重复打扰”或者“该回的时候没回”的首要原因。以下四类划分在多数产品中普遍存在，具体叫法可能有差异，但逻辑相通。

• 欢迎语（首次触达回复）：客户进入会话时触发，与客服是否在线无关。它的作用是把“这里有人”这个信号先给出去。
• 关键词自动回复：客户消息命中预设词库时触发，与在线状态无关，用于分流高频问题。
• 离线／非工作时间自动回复：也就是本文的主题，核心判定条件是“当前没有客服可接待”或者“处于设定的非服务时段”。
• 超时未响应自动回复：客户消息发出后一段时间内无人应答时触发，属于在线状态下的兜底。

为什么要分开看？因为触发条件一旦重叠，同一条客户消息可能连着收到两三条自动化消息。经验性观察是，客户对“两条以上无人感的自动消息”容忍度很低，往往直接判定为机器人或干脆不再回复，后续人工介入的成功率也随之下降。因此在易歪歪里动手配置离线自动回复之前，建议先确认欢迎语与关键词回复的开关状态，避免叠加。

2.1 与“智能客服”的边界

有些团队会把“离线自动回复”和“智能客服”当成同一件事。差别在于：前者是固定文案的条件触发，配置成本低、结果可预期；后者依赖语义理解与知识库，需要持续投喂语料、定期评估准确率，维护成本明显更高。如果你的诉求只是“夜里有人回应一声”，前者足够；如果诉求是“夜里自动给出准确答案”，就需要评估后者，并且要做好答错的兜底。

2.2 版本与端侧前提

本文描述的是配置思路与通用路径模式。截至当前的最新版本，各端的功能开放程度可能并不一致：桌面端与网页管理后台通常提供最完整的触发条件设置，移动端多数只提供开关与简单文案编辑。具体差异请以你实际安装的客户端为准，不要以他人的截图作为唯一依据。

三、配置前的三项准备

直接进后台点开关，通常会在十分钟内踩坑。把下面三件事先想清楚，后面的配置会顺很多。

3.1 先把“离线”定义清楚

多数系统的离线判定不是单一条件，而是若干可能性的组合：全部客服账号登出或离线；处于设定的非服务时段，例如每天 18:00 至次日 09:00；会话尚未被任何客服接入；客服在线但已达接待上限。你要先回答一个问题——这几种情况里，哪些应该触发自动回复？

以“客服在线但已满负荷”为例，客户其实等得到人，此时推一条“客服已离线”的提示属于误导。合理的做法是把它排除在触发条件之外，或者改用另一套话术，例如“当前咨询较多，我们会在几分钟内接入”。这类区分看起来琐碎，但它直接决定了客户会不会觉得你们的服务“忽冷忽热”。

3.2 准备好模板，而不是临场写

模板至少要包含三要素：确认收到、说明时间、给出替代路径。例如“您的消息已收到，人工客服将在今日 9:00 后按顺序回复；如需查询订单状态，可回复订单号，系统会先为你拉取信息”。第三句是很多人会漏掉的部分，它决定了客户是“继续等”还是“去别家看看”。

模板长度不宜超过三行。移动端一屏能读完的文案，实际阅读率明显更高；超过四行会被折叠，客户大概率只读第一行，后面写的服务承诺等于白写。

3.3 确认账号权限与端侧支持

自动回复这类全局配置通常属于管理员级权限，普通客服账号一般只能查看不能修改。还有一种常见情况是：你能看到开关，但保存后提示权限不足或需要管理员审批。遇到这类提示不要反复重试，先确认自己的账号角色，再决定是由管理员统一配置，还是申请相应权限。

四、最短可达路径（分平台）

下面给出的是通用路径模式。入口名称在不同版本中可能略有差异，请以实际界面为准。整体思路是先找到“自动回复”分组，再定位到“离线”或“非工作时间”子项，最后配置时段、文案与发送范围。

4.1 桌面端

1. 登录易歪歪桌面客户端，进入设置或管理后台区域。
2. 找到“自动回复”或“消息托管”一类的分组。
3. 选择“离线自动回复”或“非工作时间回复”子项。
4. 打开开关，依次配置生效时段、触发条件、回复内容与发送范围。
5. 保存后不要立刻关页面，用另一个账号发一条测试消息验证。

桌面端的优势是配置项齐全，适合做一次性完整设定。它的劣势是配置结果可能只作用于当前登录环境——如果你是多设备、多账号轮值的团队，需要确认规则是保存在账号侧还是设备侧。判断方法很直接：换一台设备登录同一账号，看规则是否还在。

4.2 移动端

移动端一般提供的是简化入口：进入“我的”或“工作台”，找到自动回复开关，开启后选择已有模板或做简单编辑。触发条件的精细配置，例如时段、接待上限、去重间隔，多数情况下仍需回到桌面端或网页后台完成。

这意味着一个很常见的坑：只在手机上开了开关，用的是默认时段，而默认时段可能与你的实际排班并不匹配。表面上开关是打开的，实际上夜间那一段根本没触发。建议在手机上配置完后，回到桌面端复查一遍规则详情。

4.3 网页管理后台

网页后台通常是配置最完整的入口，尤其适合多人协作。路径模式大致为：登录后台 → 客服设置或会话管理 → 自动回复 → 新建规则。它的优势在于配置完成后不需要逐台设备同步，所有登录账号读取同一份规则。多人轮值的团队强烈建议统一在后台配置，而不是各端各设一套，否则后期排查问题时很难判断是哪一份规则在生效。

4.4 失败分支与回退

保存失败常见于三种情况：权限不足、必填项未填、时段设置与其他规则冲突。回退方式也很简单：先关闭这条规则的总开关，而不是删除。删除之后如果发现是别的原因导致的，你需要重新配置一遍。关闭开关既能立刻止血，又保留了配置内容便于排查。

五、触发条件怎么设：四类判定逻辑与组合

触发条件是整个配置里最容易设错的部分。它决定了“什么时候发”，而客户体验的好坏，八成取决于这一步。下面拆成四类来看。

5.1 时间窗触发

按排班表设置服务时段，时段外一律触发。这种方式最直观，适合服务时间固定的团队。要留意跨天时段的写法：18:00 到次日 09:00 属于跨天，部分产品需要拆成两条规则，分别是 18:00–24:00 与 00:00–09:00，否则午夜之后的那一段可能不生效。

验证方法可以复用：把测试规则的时间窗设成当前时间前后各五分钟，然后分别在前段、跨天点、后段各发一条消息，观察触发情况。这个测试大概需要十几次消息就能完成，比事后翻日志快得多。

5.2 在线状态触发

以“当前是否有客服在线”为条件，与钟点无关。它更适合排班不固定、或者有人随时可能上线的团队。风险在于状态判定可能存在滞后：客服刚关闭客户端，系统未必立刻标记为离线，反过来也一样。经验性观察是，状态类触发在切换瞬间存在短暂的不确定窗口，因此不建议把时间窗与在线状态设成“任一满足即触发”，否则容易出现重复发送。

5.3 会话状态触发

更精细的做法是叠加会话维度：仅当该会话尚未被任何客服接入、且客户消息数达到某条阈值时才触发。这样可以避免客户连发三条消息就收到三条自动回复。多数系统提供“同一会话只发一次”或“冷却时长”之类的选项；如果找不到，就用规则里的发送频率限制来近似实现。

5.4 冷却与去重的取舍

冷却时间需要权衡：太短会形成骚扰，太长则客户第二天来问时收不到提示。一个可用的起点是同一会话在一个服务时段内只触发一次，客户发送新消息后不重置计时。是否值得为长会话设置重置，取决于业务节奏——高客单价、长决策周期的行业更适合允许重置，因为客户往往隔几小时又回来问一次。

触发方式	适用场景	主要风险
时间窗	排班固定的团队	跨天时段易漏配
在线状态	排班不固定、随时有人上线	状态切换存在滞后窗口
会话状态	高并发、短消息密集	配置项较多，易误设
冷却去重	所有场景的辅助手段	间隔过长等于没兜底

六、消息模板怎么写：把“等待”讲清楚

模板是客户唯一能看到的内容，它承担三个任务：让对方知道消息没丢、知道大概等多久、知道眼下能做什么。三者缺一，客户就会转向其他渠道。

6.1 变量与占位符

多数系统支持在模板中插入变量，例如客户昵称、当前时间、预计回复时段。变量的具体写法因产品而异，常见形式是花括号包裹。使用前务必在测试会话里发一遍，确认变量确实被替换成了真实内容；如果原样显示出花括号，说明该变量在当前版本不被支持，需要改用手写文本。

另外要避免“变量过载”。一条消息里塞四五个变量，读起来会像系统日志，反而降低信任感。通常保留昵称与时间两个就够了。

6.2 语气与长度

把自动回复写得像人，而不是像系统通知，差别往往只在几个字。移动端建议控制在三行以内。一个实用判断标准是：把模板念出来，如果自己听着别扭，客户大概也会觉得别扭。

6.3 不要承诺做不到的事

最典型的错误是写“客服马上回复”，而实际排班里根本没有值班人员。另一类是写“24 小时在线”，但只有夜间触发了自动回复、白天并无人值守。合规角度看，服务承诺类表述在部分行业属于受监管内容，模板上线前最好过一次内部审核。这不是技术问题，但翻车概率不低。

七、三个可复现的小场景

抽象讲完，用三个具体场景把配置落到地上。以下数据均为示意，请按自己团队的实际排班替换。

7.1 场景一：三人小团队的夜间兜底

假设服务时间是每天 9:00–18:00，其余时间无人值守。做法是把触发条件设为时间窗，冷却设为“同一会话在本次离线时段内只发一次”，模板写明“今日 9:00 后按顺序回复”，并附上一条自助路径，例如回复订单号可查询物流。验证方式是在 18:05、次日 8:55、次日 9:05 各发一条测试消息，预期是前两条触发、第三条不触发（已进入服务时段，改由在线流程处理）。

7.2 场景二：节假日批量公告

春节这类连续假期，与其改排班，不如单独建一条规则，把时间窗设为整段假期，文案里写清楚恢复服务的日期与假期内的应急渠道。这里需要注意的是，假期规则与日常的夜间规则可能重叠。处置方式是在假期开始前先禁用日常夜间规则，假期结束后再恢复启用。这个“先禁用再启用”的动作很容易被忘记，建议在日历里设一个提醒。

7.3 场景三：大促期间的容量溢出

大促期间客服在线但会话排满，如果你把这种情况也判定为离线，客户会以为当天没人。更合理的处理是单独写一条话术，说明“当前咨询量较大，正在按顺序接入”，并且不承诺具体分钟数。与离线规则区分开，避免客户在同一次咨询里收到两套互相矛盾的说法。

八、例外与副作用：什么时候不该触发

任何自动化机制都有它不该介入的时刻。离线自动回复尤其如此，因为它的触发条件是“感知不到人”这种相对粗糙的判断。

第一种例外是已进入人工会话的客户。如果一位客服已经和客户聊到一半，因为换班下线，系统此时给客户推一条“客服已离线”的通用话术，体验会非常割裂。多数系统提供类似“已被接待的会话不再触发”的选项，配置时建议开启。

第二种例外是投诉与售后类会话。自动回复的冷静语气在投诉场景里容易被解读为敷衍。可行的折中办法是按入口区分：售前咨询走标准话术，售后或投诉入口使用另一套更简短的模板，并直接给出人工处理的时间承诺。

第三种例外是短时离开。客服只是午休二十分钟，此时更合适的是超时未响应机制，而不是离线话术。判断标准可以简化为：预计无人时长超过一小时，用离线规则；低于一小时，用超时规则。

8.1 常见的副作用与缓解

副作用之一是重复发送，成因通常是多条规则的时段重叠。缓解方式是建立一张简表，列出所有启用中的自动回复规则及其生效时段，配置新规则前先对照一次。副作用之二是客户误判，例如把自动回复当成真人回复后继续说了一大段，结果无人应答，情绪反而更差。缓解方式是在文案里明确标注这是自动提示，并且给出明确的人工接入时间。

九、与机器人或第三方的协同

有些团队希望离线时段不仅回复，还能顺带完成查单、留资、建工单。这通常需要引入机器人或第三方系统。这里能给的建议是通用的：只在你确实能验证其行为的前提下接入，并且遵循权限最小化原则。

具体来说，为第三方分配权限时，优先使用只读或限定范围的令牌，避免直接授予账号的完整控制权；接入后先在测试会话里跑通完整链路，包括正常回复、异常回复、客户中途退出等分支；同时保留一个“一键停用”的入口，出问题时能立刻切断，而不是等着对方修。至于具体有哪些第三方方案可用、支持到什么程度，这属于会随时变化的信息，建议以你所用平台的官方说明为准，不要依赖二手截图。

十、验证与观测：怎么确认它真的生效了

配置完成不等于生效。下面这套验证流程不依赖任何内部权限，用一个客服账号加一个普通账号就能完成。

1. 用普通账号在服务时段内发一条消息，预期不触发离线话术。
2. 把测试规则的时间窗临时调整到当前时间，再发一条，预期触发一次。
3. 在同一会话内连续发三条，观察是否只收到一条回复。
4. 换一个普通账号重复第三步，确认冷却是否按会话隔离。
5. 检查变量是否被正确替换，而非原样显示花括号。
6. 把时间窗改回真实排班，再在不同的边界点各测一次。

如果系统提供自动回复的发送记录或统计入口，可以进一步对照：发送次数与触发会话数是否吻合、是否存在同一会话的重复记录。若这两项对不上，通常意味着有另一条规则在同时生效。

十一、故障排查：现象 → 原因 → 验证 → 处置

下面按现象归类整理，便于快速定位。

11.1 完全不触发

可能原因包括：规则未启用、时间窗配置错误、当前实际有客服在线导致判定为在线、账号权限不足导致保存未生效。验证方式是先确认规则状态，再用测试账号在明确的离线时段发消息。处置上，先从最简单的总开关查起，不要一上来就怀疑系统故障。

11.2 重复触发

常见原因是多条规则时段重叠，或者冷却设置过短。验证方式是暂时禁用其中一条，观察现象是否消失。处置上，保留覆盖面更精确的那一条，删除或关闭另一条，而不是两条都留着“以防万一”。

11.3 客户反馈收到的是乱码或空消息

多数与变量使用不当有关，例如引用了当前版本不支持的变量，或换行符处理异常。验证方式是在测试会话中逐字比对，确认哪些字符被替换、哪些没有。处置上，先退回到纯文本模板，确认链路通畅后再逐步加回变量。

11.4 只在部分端触发

如果客户从某个渠道进入时不触发，多半是该渠道未纳入规则的发送范围，或者规则本身只在特定端生效。验证方式是分别从不同入口进入会话各测一次。处置上，检查规则的适用范围设置，必要时为不同渠道建立独立规则。

十二、适用与不适用场景清单

判断要不要开这项功能，可以对照下面这组条件。

适合开启的情形：服务时段固定且明确、夜间或节假日确实无人值守、咨询以售前问题为主、客户对响应速度的敏感度中等、团队有能力定期维护文案。

不适合开启或需要谨慎的情形：7×24 有人轮值、业务涉及强时效承诺（例如即时配送、限时抢购）、咨询以投诉与纠纷为主、无人负责文案更新、同一时段已经有多条自动规则在运行。

后者中尤其要注意强时效业务。客户在深夜下单前问“能不能明天早上送到”，你回一条“9:00 后回复”，等于是把这个订单让给了别人。这种情况更合理的做法是提供自助查询入口，而不是套用通用话术。

十三、最佳实践检查表

把上面的内容收敛成一份可以照着走的检查表，配置前过一遍，配置后再过一遍。

• 明确了“离线”的判定范围，并排除了“在线但满负荷”这类容易误导的情况。
• 确认同一时段没有其他自动回复规则在运行。
• 模板包含确认收到、时间承诺、替代路径三要素，且不超过三行。
• 文案中没有无法兑现的服务承诺。
• 已进入人工会话的客户不会被再次触发。
• 冷却与去重已设置，且经过连续多发测试。
• 变量在测试会话中被正确替换。
• 跨天时段单独验证过午夜前后的表现。
• 规则保存位置已确认是账号侧还是设备侧。
• 留有一个可快速停用的入口，并写进了团队的应急预案。

这份清单不必追求一次全部打勾，但其中两条建议优先处理：一是“离线”的判定范围是否已经把在线满负荷排除在外，二是同一时段是否存在多条规则并行。这两项一旦出错，后面的文案与冷却设置再精细，也很难把体验拉回来。

十四、常见问题（FAQ）

十五、小结与下一步

回到最初那个凌晨两点的场景。这一段缝隙无法靠加人填满，但可以被一条配置得当的自动回复承接下来。核心结论只有三句：把“离线”的判定范围先定义清楚，别把在线满负荷也当成无人；把模板写成三行以内、有明确时间承诺的样子；上线前用测试账号在边界时刻各跑一遍，确认不重复、不漏发。

下一步的建议是，先不动全局设置，用一条临时规则在小范围内跑一周，对照客户的实际反馈与人工介入的成功率再决定是否长期保留。自动回复是兜底机制，它的价值不在于发了多少条，而在于有多少客户因为这条消息愿意继续等下去。

从产品演进的一般规律看，自动回复与知识库、会话分配之间的联动往往会逐步加强，端侧能力的差异也可能随之缩小；不过这属于经验性判断，具体能力与开放范围请以官方更新说明和你实际安装的客户端为准，不建议依据二手截图提前调整线上配置。