亚博Zendesk可见性(发布说明、更新等)
功能请求摘要:
我们需要更多地了解Zendesk每天所做的更改(代码更改等)。亚博
描述/用例:
Zendesk对代码进行了一些更新，直接影响了实例，导致核心功能无法工作。亚博据说，并不是所有的更新都包含在发布说明中，所以我们没有办法将代码更改联系起来，或者在这个时候保持额外的关注任何可能中断的东西。
给我的理由是因为他们这样做许多这似乎没有任何预期的影响，通知不会证明是有用的。我想提出一个相反的观点，即我们应该自己决定什么是有用的。也许是一种订阅他们正在调整的确切变化的方法
ie。如果他们正在调整占位符，我们使用它们，我应该得到通知
限制或缺少功能对业务的影响:
如果更新导致功能中断，则会导致升级，问题未被注意的时间延长，或者更糟的是，从未被注意到，这会导致浪费时间去弄清楚发生了什么，何时，何地，为什么以及如何修复它。以下是一些影响我们的代码更新示例:
- 我们使用了一个有bug的占位符(不知道)，ZD修复了破坏占位符的bug。这导致向请求者发送空白消息
- 子票据接收到一个更新(似乎对它们如何处理这些类型的触发事件的更新进行了更改，导致负责处理事件的系统用户(即“当前用户”)不被识别为代理)，这阻止了触发器的触发，每次父票据更新它时都会重新打开子票据。这导致团队没有收到后续通知
- 我们在票务中得到空白回复，你只能在“查看原始邮件”选项中查看回复。根据我们的CX团队的说法，一个代码修复将于4月18日实施，但它没有发布在发行说明中，所以如果他们没有直接告诉我们，我们就不会知道它已经修复了。
-
我百分之百赞同。
亚博Zendesk在没有充分通知用户或事先测试的情况下就将更改推向生产环境。eap和beta之所以存在是有原因的，所以我不明白他们为什么这样处理。
其他近期对代理体验有直接影响/导致bug的改动有:
1.在客户上下文面板中，当打开组织时，将强制重新加载页面
2.在客户上下文面板中，现在包含了时区，并且跨越了两行最糟糕的是，一些管理员甚至可能没有及时注意到导致缺陷的bug /更改。
亚博zendesk的USP是他们的易用性和直观的设计——所以我真的很难理解为什么他们不把重点放在这一点上。 -
一个具体的问题是，当更改提前宣布时(例如Slack Legacy集成弃用，或分页更新)，当推出或延迟推出时，没有进一步的公告。即使提前宣布了变更，也应该在变更发生时在发布说明中提及。如果更改延迟，则应通过帖子或发行说明进行说明。
-
在过去的几个月里，这种情况对我们来说也发生了好几次。我追踪了一些非常奇怪的bug，导致Zendesk内部回滚。亚博我还偶然发现了一些很好的API端点，如果能听到这些端点就太好了。
我想到了一些例子:
- Cloudflare更新开始阻止注释创建，如果某些代码字符串包含在内。
- 除非你在事件视图上，否则评论会停止加载
- 当在对话框中点击链接时，超链接弹出窗口不再显示
- 票据API端点上的cc_emails_id属性停止填充
- 已经引入了新的API端点(我们很想了解这些，因为我们正在以更复杂的方式解决一些痛点)
-
大家好，非常感谢你们的反馈——这真的很有帮助，很有建设性。与我们的客户进行影响变更沟通的团队有兴趣建立一个电话，更深入地讨论您的想法;我们会在几周内找个时间让你们聚在一起。
一旦我们解决了这个问题，我会在这里更新。如果其他人有反馈或想要参与对话，请在这里发布您的想法，我们也会让您进入循环。 -
我们刚刚从Zendesk团队成员那亚博里听到的这是政策不提前宣布变更，除非它达到了一些任意的门槛。我真的建议应该重新评估这项政策——例如，在这个新的草稿功能中，我们可以看到所有相关的指南文章都是根据作者日期在4月中下旬起草的，但没有发表，直到上线那天才发布公告。
请登录留下评论。
5个评论