最近の検索


最近の検索はありません

Amy Dee's Avatar

Amy Dee

参加日2021年4月14日

·

前回のアクティビティ2024年11月18日

Zendesk Customer Care

フォロー中

0

フォロワー

4

合計アクティビティ

86

投票

29

受信登録

18

アクティビティの概要

さんの最近のアクティビティ Amy Dee

Amy Deeさんが記事を作成しました:

記事メールに関するヘルプ

質問

受信メールはどのようにチケットにスレッド化されますか?

回答

受信メールが届くと、Zendeskは既存のチケットへの参照がないかメールをチェックします。これにより、メールがチケットの更新として追加されるか、新しいチケットが作成されるかが決まります。

Zendeskでは、メールのスレッド化に関する主な参考資料を3つ確認しています。

1.メールヘッダーの要素

メールヘッダーのReferences行とIn-Reply-To行には、同じスレッド内の他のメールのメッセージIDが含まれています。Zendeskは既存のチケットのメッセージIDをチェックします。一致するものが見つかると、そのメールは一致するチケットへの返信として追加されます。

メールヘッダーはメールソースに表示されます。詳しくは、次の記事を参照してください:受信したチケットのHTMLと元のソースを表示する方法

メールヘッダーのトラブルシューティングの詳細については、次の記事を参照してください。「メールが間違ったチケットにスレッドされるのはなぜですか?」

2.メッセージ本文内のエンコードされたID

エンコードされたIDは、特定のチケットへの一意の参照です。Zendeskでは、すべての送信通知メールにデフォルトでエンコードされたIDが含まれているため、返信が正しいチケットにマッチするのに役立ちます。

エンコードされたIDは任意のメール本文に追加でき、Zendeskによって生成されるメールだけに限定されるものではありません。エンコードされたIDは、ZendeskがIDを検出するために、角括弧[1G7EOR-0Q2J]内に表示する必要があります。

3.Zendeskの受信アドレスでエンコードされたID

Zendesk Supportメールアドレスには、エンコードされたIDを含むエイリアスを使用できます。たとえば、mondocamサブドメインでエンコードされたID1G7EOR-0Q2Jを持つチケットのメールアドレスは、「support+id1G7EOR-0Q2J@mondocam.zendesk.com」のように表示されます。

この構造により、他の参照がない場合でも、メールが対応するチケットにスレッド化されるようになります。

このエンコードIDの使用はZendesk Supportメールアドレスに対してのみ機能し、外部サポートアドレスに対しては機能しません。

エンコードされたIDにアクセスする方法

エンコードされたチケットのIDは、以下の手順で確認できます。

  • マクロまたはチケットコメント内で{{ticket.encoded_id}}プレースホルダを使用して、エンコードされたIDを表示します。
  • Tickets APIを使用して、encoded_idパラメータを表示します。このアプローチにより、APIワークフローはチケットコメントを操作することなく、エンコードされたIDにアクセスできます。
メモ:標準のチケットコメントとは対照的に、メールのスレッド化では、サイドカンバセーションのコメントはメールヘッダーのReferenceIn-Reply-Toではなく、メール本文のConversation IDを使用します。

翻訳に関する免責事項:この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。

翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。

編集日時:2024年12月17日 · Amy Dee

1

フォロワー

1

投票

0

コメント


Amy Deeさんがコメントを作成しました:

コメントMeasuring success

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さんがコメントを作成しました:

コミュニティのコメント Feedback - Ticketing system (Support)

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さんがコメントを作成しました:

コメントMeasuring success

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さんがコメントを作成しました:

コミュニティのコメント Feedback - Ticketing system (Support)

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さんがコメントを作成しました:

コメントMeasuring success

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さんがコメントを作成しました:

コメントMeasuring success

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に届く前に拒否されてしまいました。

解決のステップ

これらのエラーは、ZendeskではなくMicrosoftによって生成されます。Zendeskはこれらのエラーの解決をサポートできません。ユーザーが突然配信不能通知やエラーメッセージを報告した場合は、メール管理者に連絡してください。エラーメッセージとメール設定を確認する必要があります。

メモ:このタイプのエラーは、以前は機能していたサポートアドレスで発生する可能性があります。これは通常、何かが変更されたことを意味します。たとえば、Microsoftがメール転送の新しいポリシーを実装した場合、既存のアドレスは更新しないと新しい要件を満たせない可能性があります。

メールドメインのメール管理者がこれらのエラーを調査し、解決することができます。Microsoftが 自動メール転送に関するポリシーを更新した可能性があり、これにより、長い間スムーズに機能しているサポートアドレスに影響が及ぶ可能性があります。詳しくは、次の記事を参照してください:「既存のメールアドレスで受け取ったメールをZendesk Supportに転送する方法」。

翻訳に関する免責事項:この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。

翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。

編集日時:2024年3月26日 · Amy Dee

1

フォロワー

1

投票

0

コメント


Amy Deeさんがコメントを作成しました:

コミュニティのコメント Feedback - Ticketing system (Support)

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さんがコメントを作成しました:

コメントExplore recipes

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

コメント