工单上写着“它坏了”。
Snag 送来的是实际发生的事。

支持团队通常只有一次机会询问客户任何问题。客户会用自己的语言描述故障，等到有人问起他们使用的是哪个浏览器时，他们早已关闭了标签页，继续工作了。而使用Snag，他们提交的是会话本身，而不是对会话的描述。

问题

一个故障至少要经过两道交接才能到达工程部门，而证据却往往落入最末端、最不擅长描述故障的人手中。客户只写了一句话。接手的人会回复，要求提供屏幕截图、浏览器、账户信息、故障发生时间——即便最终得到回复，也往往要等上一天，而且一半的问题都还没解决。与此同时，工单就一直处于所有支持队列都极其常见的状态：等待报告人回复。升级请求也因为同样的原因而被驳回。工程师无法重现的问题报告并非升级请求，而是一个研究项目，它会带着“无法重现”的回复被逐级退回——而这个回复注定会比故障本身更损害双方的关系。

Snag如何提供帮助

生产环境不适合放一个碍眼的小部件，所以 Snag 在那里很安静：角落里一个采用标准反馈图形的小图标，或者干脆什么都不渲染，由你的支持流程里已有的“报告问题”链接来打开捕获。两种方式下，客户都留在你的产品里，只做一个动作。他们发送的是会话本身——录制内容、控制台输出，以及页面实际发出的那些请求——被投递到你的跟踪系统，工单上附一条指向回放的链接。这些内容在上传之前就已在浏览器里遮蔽——输入内容绝不会被记录。这正是“支持团队看到了故障”和“支持团队经手了个人数据”之间的区别。而且所有套餐的成员数量都不限，整个支持排班上的人都可以待在工作区里，自己打开这些证据。

你得到的回报

一次升级，工程师第一次收到它就能动手，中间不必再给客户回一封信。缩短的是那个谁都不喜欢的队列状态：等待一个其实已经把他所知道的一切都告诉过你的报告人。你的团队向上交出去的东西不再是一段转述，而是一个链接——同一段录制、同一份控制台、同一个失败的请求，交给接手的任何人。把这件事摆到客户面前有三种方式，这份走查把每一种都实地演示了一遍。

人们实际会问的问题

用户需要安装任何软件才能通过这种方式报告错误吗？

不。所有操作都在用户当前页面内完成——只需在您的网站上添加一个脚本标签，无需用户下载、登录或批准任何内容。您可以自行决定其可见程度：可以是角落里的小图标，也可以完全不显示，用户点击后，系统会通过您网站上的“报告错误”菜单项调用该脚本。

用户在使用我们产品期间是否会被全程录像？

不会。一次捕获就是一次有意的操作：它从客户主动要求反馈问题的那一刻开始，等客户提交之后，小部件又会自己收起来。它收集到的内容在离开客户浏览器之前就已经过遮蔽——密码和表单输入不会被记录，敏感请求头会被剥离，明显的密钥会被抹去——所以你团队里的任何人都不会经手客户在输入框里打过的字。

二十个人报告了同样的故障。我们会收到二十张故障单吗？

报告在进入你的跟踪系统的路上会先做分流和去重，所以一次故障不会变成一整列几乎一样、还得有人手工处理的工单。这些报告里的证据仍然都在；省下的只是那些重复的工单本身。

这些细节的来源

本页面不涉及任何其他产品——所有信息均为Snag原创。如有信息过时，请发送邮件至 admin@dvcllc.io，我们将予以更正。