最近搜索
没有最近搜索

Amy Dee
已加入2021年4月14日
·
最后活动2024年11月18日
关注
0
关注者
4
活动总数
86
投票
29
订阅
18
活动概览
标记
文章
帖子
社区评论
文章评论
活动概览
的最新活动 Amy Dee
Amy Dee 创建了一篇文章,
问题
新到的电邮如何串连到工单?
回答
收到电邮后,Zendesk 会检查电邮中是否引用了现有工单。这决定了是将电邮添加为工单更新,还是创建新工单。
Zendesk 为讨论串电邮检查三个主要参考:
1.电邮标头中的元素
在电邮标头中, References
和 In-Reply-To
行包含同一讨论串中其他电邮的消息 ID。Zendesk 将检查现有工单上是否有这些消息 ID。如果 Zendesk 找到匹配项,电邮将被添加为匹配工单的回复。
电邮标头在电邮来源中可见。请参阅文章:查看新到工单的 HTML 和原始来源以了解详情。
有关电邮标头故障排除的更多信息,请参阅文章:为什么电邮串入错误的工单?
2.消息正文中的编码 ID
编码 ID 是对特定工单的唯一引用。Zendesk 默认在每封发出的通知电邮中包含一个编码 ID,这有助于将回复匹配到正确的工单。
编码 ID 可添加到任何电邮正文,且不仅限于 Zendesk 生成的电邮。编码 ID 必须出现在方括号内 [1G7EOR-0Q2J]
以便 Zendesk 检测到 ID。
3.Zendesk 接收地址中的编码 ID
Zendesk 支持电邮地址 可使用包含该编码 ID 的别名。例如,ID 已编码的工单电邮地址 1G7EOR-0Q2J
mondocam 子域名中的 会显示这样: support+id1G7EOR-0Q2J@mondocam.zendesk.com
更新。
此结构有助于将电邮讨论串讨论到相应的工单,即使没有其他参考信息存在。
这种对 ID 的编码仅适用于 Zendesk 客服电邮地址,不适用于外部客服电邮地址。
如何访问编码 ID
您可以按照以下步骤找到工单的编码 ID:
- 使用
{{ticket.encoded_id}}
在宏或工单评论中使用占位符以显示编码 ID。 - 使用 Tickets API 查看
encoded_id
参数。这种方法允许 API 工作流程访问编码 ID,而无需操作工单评论。
Conversation ID
电邮正文中的内容,而不是 Reference
或 In-Reply-To
添加电邮标题。翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性
如对翻译准确性有任何疑问,请以文章的英语版本为准。
已于 2024年12月17日 编辑 · Amy Dee
1
关注者
1
投票
0
评论
Amy Dee 进行了评论,
Hi David Durr !
That is a valid security concern, and it's one that Zendesk shares.
These account exports are always restricted to administrators. Agents don't have permission to see or initiate them. In addition, the account owner can restrict exports to administrators in specific email domains (or disable exports entirely). We have more information in this article: Restricting or deactivating account data exports.
Those settings apply to the account export tools described in this article. It doesn't extend to the API. That said, while agents can access some data through the API, the Incremental Exports API endpoints are all admin-only as well.
I hope this helps!
查看评论 · 已于 2024年8月28日 发布 · Amy Dee
0
关注者
1
投票
0
评论
Amy Dee 进行了评论,
Hi Riah Lao -
Correct again! Zendesk functions - including views, automations, and analytics - use the full timestamp of the SLA target. That means views should consistently show a 1:40 ticket ahead of a 2:20 ticket, even though they both show a “2h” badge. The badge is just there as a quick visual indicator for agents.
I hope this helps!
查看评论 · 已于 2024年5月02日 发布 · Amy Dee
0
关注者
0
投票
0
评论
Amy Dee 进行了评论,
Hi there!
Solving a ticket also fulfills all active SLA targets. This includes reply and update targets, which typically require a public comment. In your example, solving the ticket would fulfill the next reply time target, even if the agent didn't publicly respond to “Thank you.”
I hope this helps!
查看评论 · 已于 2024年5月01日 发布 · Amy Dee
0
关注者
0
投票
0
评论
Amy Dee 进行了评论,
Hi Riah Lao
Thanks for the question! Your example is spot on. If the time remaining is 2:20, the badge will round down and show “2h.” If the time remaining is 2:40, the badge will round up and show “3h.” The exact halfway point - 2:30 - also rounds down to “2h.”
SLA badges have three different units: minutes, hours, and days. They start displaying the next unit up when that unit rounds to 2. For example, a target of 36 hours and 30 minutes would round down to a “36h” badge. A target of 36 hours and 31 minutes would round up to 37 hours, which then rounds up to “2d.”
There is no unit above “days." If you have a 2-year target, you'll see “730d” in the badge. There is also no unit below “minutes.” When the target is at or below 30 seconds, you'll see “now” in the badge.
I hope this helps!
查看评论 · 已于 2024年5月01日 发布 · Amy Dee
0
关注者
0
投票
0
评论
Amy Dee 进行了评论,
Hi Jon!
At this time, there's no way to adjust how first reply time is measured. The system metric will start at ticket creation and end at the first public agent comment after that. The SLA target will wait for a public end user comment to get started (if the ticket was created with a private note).
You could create separate SLA policies for phone tickets. That wouldn't change the first reply target behavior, but it would allow you to manage those tickets and agent expectations separately.
I do have some good news. Our SLA team is hard at work on enhancements that will give users more flexibility over reply time SLA targets. That could help for workflows like yours. I recommend following our Announcements page for more information.
I hope this helps!
查看评论 · 已于 2024年4月15日 发布 · Amy Dee
0
关注者
0
投票
0
评论
Amy Dee 进行了评论,
Hi Hannah!
Schedules are applied to tickets, not SLA policies (or other business rules). For the SLA policy, you just choose between calendar and business hours for each target. If you choose business hours, the SLA will use the schedule associated with the ticket.
Professional accounts only have one schedule, so there isn't much flexibility with business hours. Enterprise accounts can have multiple schedules, though, and they're controlled with business rules. That would allow you to create corresponding schedules and SLA policies for tickets in certain workflows.
We have more information about schedules here: Setting your schedule with business hours and holidays.
I hope this helps!
查看评论 · 已于 2024年4月10日 发布 · Amy Dee
0
关注者
0
投票
0
评论
Amy Dee 创建了一篇文章,
问题症状
- 终端用户在发送电邮到客服电邮地址后,会收到来自 Microsoft 的退回通知。
- 通知开头为:您的消息无法送达。
- 消息包含一个错误或状态代码,带有
550 5.7.x
。 - 电邮未送达 Zendesk。
每个基础问题的消息文本都不同。然而,主要问题仍然存在:用户的电邮在到达 Zendesk 之前就被拒绝了。
解决步骤
这些错误是由 Microsoft 生成的,而不是 Zendesk。Zendesk 无法协助解决这些错误。如果您的用户突然报告退回通知和错误消息,请联系您的电邮管理员。他们将需要审阅错误消息和您的电邮配置。
您的电邮域名的电邮管理员可以调查并解决这些错误。Microsoft 可能已更新其关于 自动电邮转发的政策,这可能会影响长期以来一直正常工作的客服电邮地址。有关更多信息,请参阅文章:将现有电子邮箱中的新到电邮转发到 Zendesk Support。
翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性
如对翻译准确性有任何疑问,请以文章的英语版本为准。
已于 2024年3月26日 编辑 · Amy Dee
1
关注者
1
投票
0
评论
Amy Dee 进行了评论,
Hi @...! A business hours badge could work, but it would require total consistency: one schedule that never changes; no holidays (or exhaustively communicated holidays); all users in the same time zone; no SLA targets in calendar hours, ever.
If there's any variation in any of those points, a business hours badge becomes ambiguous. Multiple schedules, schedule changes, different regions, and different SLA policies all impact how much time is actually left on a target. Agents could no longer take the badge at face value.
Even if there is total consistency, SLA badges round their numbers to hours (or days) when the target is far enough away. This means two tickets could both have a "2 business hours" badge, but one is due Friday at 4:50pm while the other is due Monday at 9:10am. Agents should prioritize the Friday ticket, but they need an easy way to know which is which.
SLA badges in business hours put a burden on agents. Before agents can act on a badge, they'd need to interpret that number in relation to the schedule and their current time. That mental math is taxing, even in simple environments. In more complex environments, it's prohibitive.
SLA badges are designed to quickly prioritize workflows. It's important to ensure that they're all on the same scale, regardless of account complexity, and that the scale is intuitive at a glance. That's why badges show real time remaining. This allows agents to see accurate deadlines, without any extra effort required.
I hope this helps!
查看评论 · 已于 2023年6月16日 发布 · Amy Dee
0
关注者
3
投票
0
评论
Amy Dee 进行了评论,
Hi Leif Cederblom! At this time, Explore only captures SLA durations after the target has been fulfilled. There is no way to create an Explore report that shows live SLA counters for breached tickets.
This is due to how Explore syncs data. It isn't a live feed; it pulls data at periodic intervals. That means it has no way to maintain live durations for metrics. Explore can't tell whether an SLA has been fulfilled until after the next data sync, so durations would be stale.
If you need to monitor active SLAs in real time, we recommend using Views. You can export Views to CSV as well if needed. Explore is better suited for historic reporting.
I hope this helps!
查看评论 · 已于 2023年6月12日 发布 · Amy Dee
0
关注者
0
投票
0
评论