升级过程和宏模板
除了格式问题之外，许多错误和报告的客户问题都被遗忘了，而它们本应该被升级。
为了解决这个问题，我创建了一个标准化的格式。
我用代理创建和执行的流程包括几个不同的步骤，并进行了记录。
1:代理使用“升级Bug”宏:
行动:
- 评论模式/私人
- 小组/ L2
- 评论
Zd id #{{ticket.id}}
报告代理:{{current_user.name}}
联系人:{{ticket.requester.name}} / {{ticket.requester.email}}
公司:{{ticket.organization.name}}
登录网址:
问题总结:
用一两句非常简洁的话来解释这个问题。
注意不要包括重建步骤、结果或任何其他应该包含在单独字段中的细节。
复制步骤:
1:导航到事件“{{ticket”。ticket_field_[自定义字段代码]}"位于URL:
[网址转到这里]
2 .步骤2
3 .步骤3
预期结果:
实际结果:
频率:
处理:
注:
2: L2代理在Jira中记录票据，并将Jira添加到现有的ZD票据的自定义字段属性中。
3:一旦Jira票据被记录，票据被发送回L1代理与下一步或请求额外的信息。
4: L1代理将bug ticket记录在内部热点日志中。
在整个过程中，以下几点始终是正确的:
这些字段总是必需的，永远不会从bug报告中删除。
个人升级票务负责保持客户的最新情况，并分享潜在的解决方案和/或进展，如果依赖于开发，销售或运营。
如果不同的公寓正在向服务台提供信息，并且可能需要一些时间，那么机票将被搁置。
顾客永远不会看到或知道他们的机票被搁置了。代理商会让客户知道错误票已经归档，他们的票将保持“打开”状态，这对他们来说就是这样。
在每个发行版中，已解决的bug票据都会从热点问题列表中删除，并添加到内部知识库中的“已解决的bug”类别中。代理通过测试确认问题实际上已经解决，然后通知所有有与该bug相关的开放票证的客户。客户会得到通知，他们的罚单被认为已经解决了。收集整理就细节而言，还有一些要详细说明，不过我就不跟你说了。
如果你有任何其他问题，或者你想分享你的想法或建议，请告诉我。
-
爱。它。感谢你分享另一个很棒的建议，贾斯汀!
-
你支持多个产品吗?如果是这样的话，我们将销售超过150种软件产品。我们有大约100个开发团队负责处理bug。在宏中，您似乎将组设置为L2。每个L2团队都必须创建一个宏吗?
-
嗨,苏珊,
我有段时间没见贾斯汀了，所以我不确定能不能得到他的回复。也许这里还有其他支持多种产品和开发团队的人，他们可以分享他们的过程。
你可以阅读我们如何升级门票给我们的开发团队在这里Zende亚博sk上的Zendesk。它没有提到需要多个宏。这里的每个开发团队都有自己的小组，所以我们会进行相应的分配。
好运！
-
嗨,苏珊,
上面的宏是为一个基于SaaS的软件平台创建的(有很多附加功能)。我会继续寻找一些更符合您的用例的东西。
@Jennifer，对于我在阅读这篇文章时注意到的错误，我能做些什么吗?
-
哦，嗨，贾斯汀!你就在我身边。很高兴见到你。：）
格式混乱是因为我们把这篇文章从Web Portal迁移到了帮助中心。很抱歉!如果你想把清理后的版本发邮件给我，我可以把它复制/粘贴到这个里面。
-
谢谢你，贾斯汀。我已经创建了触发器，也使用了你的宏的一部分。我只是想知道有没有我没找到的圣杯。
文章已停止评论。
6个评论