大多数B2B SaaS支持团队在固定延迟（通常是解决后24小时）发送CSAT调查，因为他们的旧服务台只提供一个配置字段。这个单一延迟正在悄悄地降低你的回复率并扭曲你收集到的信号。解决方案不是改变这个数字。而是四条发送规则，每条规则都与渠道、工单长度和工单解决的时间相关联。
关键要点
- 固定的24小时CSAT延迟是工具的产物，而不是最佳实践——它将四种非常不同的对话类型平均化为一个平庸的发送窗口。
- 聊天解决的工单的回复率在最初几小时后急剧下降；电子邮件工单的表现相反，受益于更长的暂停。
- 长的、多次接触的工单需要延迟调查，直到第一个工作日之后，以便评分反映的是解决方案，而不是困境。
- 在一天晚些时候解决的工单应该等到下一个工作日早上——在夜间发送会降低打开率，并将你的调查标记为事务性噪音。
- 从一个延迟转移到四个延迟的团队通常会看到有意义的回复率增长，同时减少拉低分数的"愤怒发泄"尾部。
为什么存在24小时规则（以及为什么它对B2B SaaS不适用）
24小时CSAT延迟是遗留工单时代的民间传说。较旧的服务台附带一个调查触发器——"状态=已解决后X小时"——所以每个团队都选择了一个感觉安全的数字。24小时成为默认值，因为它足够长，客户可能已经测试了修复，但又足够短，他们仍然记得这次互动。
一旦你看到B2B SaaS支持团队在一周内处理的四种真实对话类型，这个逻辑就会崩溃：
- 关于账单切换的两分钟聊天。
- 跨越三个工作日的异步电子邮件交换。
- 涉及工程部门的复杂错误工单。
- 用知识库链接解决的"我如何"问题。
这些对话除了状态字段外没有任何共同之处。以相同的偏移量为所有工单发送调查，相当于针对四个受众运行一个广告创意。
窗口1：聊天解决的工单——在两小时内发送
实时聊天对话很短、同步且情感新鲜。客户的"我记得那感觉如何"的窗口很快就会关闭。如果你的调查在第二天早上到达，你已经失去了大多数会立即给你五星评级的人，并且你过度关注了仍然足够恼火以至于记得的人。
对于聊天渠道工单，在解决后两小时内触发调查，最好在访客关闭标签页之前将其嵌入到聊天小部件中。Helptal聊天小部件支持在聊天结束时进行一键点赞/点踩评级，这会在它消失之前捕捉到那一刻。如果你回退到电子邮件进行聊天调查投递，请针对同一工作日——而不是第二天早上。
窗口2：电子邮件解决的工单（少于三条消息）——在下一个工作日早上发送
对于短电子邮件交换（两到三条消息、一个代理、无升级），客户需要一段时间来确认修复有效。但"一段时间"是几小时，而不是整整一天。
最佳时间是下一个工作日早上，在客户时区的上午8点到10点之间。这个窗口：
- 给他们时间测试修复。
- 在他们整理收件箱时抓住他们（高打开意图）。
- 避免"调查在晚餐时到达"的陷阱。
如果工单在中午之前解决，你可以压缩这个时间——对于客户显然仍在活跃的快速解决方案，同一天下午3点本地时间有效。
窗口3：长期运行或升级的工单——至少等待48小时
这是固定延迟程序造成最大伤害的地方。跨越五天、两名工程师和四次后续的工单会带来情感残留。如果你在解决后24小时要求评分，客户仍在处理这个困境。他们会评价体验，而不是解决方案——而体验很艰难。
在触发以下任何标志的工单上等待48小时，有时72小时：
- 超过五条公开回复。
- 在两个或更多代理之间重新分配。
- 优先级在任何时点提升为高或紧急。
- 跨越超过两个工作日。
延迟给修复时间在生产中证明自己。在当时会评价3/5分的客户，在使用修复两天没有问题后，通常会评价5/5分。
窗口4：在工作时间后解决的工单——推迟到下一个工作日早上
如果你的代理在周四晚上7:47解决了一张工单，不要在周五晚上7:47发送CSAT电子邮件。你现在在客户精神上为周末检查时发送了它，它将在200封电子邮件的周一收件箱中未读。
规则：任何在客户时区下午5点之后解决的工单都应该将其调查保留到下一个工作日早上9点，并完全跳过周末。周五晚上的解决方案在周一早上发出。仅这一条规则就往往能恢复固定延迟程序泄露的有意义的回复率。
四窗口矩阵
| 工单类型 | 发送时间 | 原因 |
|---|---|---|
| 聊天解决，少于10条消息 | 2小时内，最好在小部件内 | 情感新鲜；记忆窗口很短 |
| 电子邮件解决，2-3条消息 | 下一个工作日早上，本地时间8-10点 | 客户需要时间验证但不会忘记 |
| 长期或升级（5条以上回复、多日） | 解决后48-72小时 | 让修复证明自己；冷却情感残留 |
| 在下午5点之后或周末解决 | 下一个工作日早上9点 | 避免夜间收件箱埋没 |
第五条隐含规则：如果客户在24小时内重新打开工单，不要发送CSAT调查。这是一个不同的信号——将其作为重新打开率而不是满意度分数进行跟踪。
如何在没有自定义构建的情况下实际配置这个
大多数团队听到"四条规则"就假设这意味着一个开发人员项目。事实并非如此。这意味着你的自动化引擎需要支持基于渠道、消息数、优先级历史和解决时间的条件延迟。以下是实施顺序：
- 审计你当前的CSAT发送时间分布。 提取过去90天的已解决工单，按上面的四个类型分类，并检查每个类型的回复率。你几乎肯定会发现一个类型拉低其他类型。
- 在你的服务台的自动化系统中构建四条触发规则。 每条规则匹配一个类型并在正确的偏移量处排队CSAT电子邮件。
- 抑制默认的"在解决时发送CSAT"自动化，以便四条条件规则是唯一的路径。
- 测量30天。 每个类型的回复率、每个类型的平均分数和收集的总回复数。与你之前的固定延迟基线进行比较。
- 调整。 2小时、48小时和上午9点的阈值是起点。你的客户群会有自己的节奏。
Helptal如何适应
Helptal的触发和自动化引擎正是围绕这种条件路由构建的——在渠道、消息数、优先级历史和解决时间上匹配，然后在正确的偏移量处排队CSAT投递等操作。聊天小部件处理聊天解决工单的对话内CSAT捕捉，所以你根本不会将这些客户反弹到电子邮件。CSAT报告按渠道和工单类型分解回复率和分数，这是你实际运行上面第一步审计所需的。
常见问题
关闭工单后何时应该发送CSAT调查？
这取决于工单类型。聊天解决的工单应该在两小时内获得调查，最好在小部件内。短电子邮件工单在上午8点到10点之间的下一个工作日早上发送效果最好。长期或升级的工单需要48-72小时，以便修复可以证明自己。在下午5点之后或周末解决的工单应该等到下一个工作日早上9点。
B2B SaaS支持团队的良好CSAT回复率是多少？
回复率因发送时间、受众和调查长度而异，但大多数运行固定24小时延迟的B2B SaaS支持团队的回复率为个位数到低两位数。转移到基于渠道和工单长度的条件发送时间的团队通常会看到有意义的改进，最大的收益来自小部件内聊天CSAT和避免夜间发送。
我应该在每张工单上发送CSAT调查吗？
不应该。跳过在24小时内重新打开的工单（解决方案没有保持——改为跟踪为重新打开率）、客户从未回复代理第一条消息的工单，以及你的团队标记为垃圾或自动解决的任何工单。调查这些会产生噪音，拉低回复率和分数可靠性。
CSAT调查应该有多长？
对于解决后支持CSAT，一个问题——点赞或点踩——带有可选的评论字段。多问题调查属于季度NPS计划，而不是事务性CSAT。解决后CSAT的全部要点是捕捉快速的情感读取；更长的调查会破坏这个目的，并在大多数测量中将回复率降低大约一半。
CSAT调查发送时间是否影响分数本身，而不仅仅是回复率？
是的，这是固定延迟的被低估的风险。在长工单上发送太早会捕捉情感残留而不是解决方案质量，拉低分数。在聊天工单上发送太晚会失去会给予高评级的客户，并过度加权仍然足够恼火以至于回复的客户。发送时间既改变了谁回复，也改变了他们说什么。
本周，提取你过去90天的CSAT数据，按上面的四个工单类型分类，并查看每个类型的回复率。回复率最差的类型是你的固定延迟失败的类型。在触及其他类型之前，为该类型构建一条条件规则——一次一条规则，测量30天。如果你正在评估支持这种条件CSAT路由而无需自定义构建的工具，Helptal的免费计划包括你运行实验所需的触发引擎和CSAT报告。