最近の検索
最近の検索はありません

James Sanford
参加日2021年4月16日
·
前回のアクティビティ2022年2月01日
フォロー中
0
フォロワー
0
合計アクティビティ
72
投票
2
受信登録
62
アクティビティの概要
バッジ
記事
投稿
コミュニティへのコメント
記事へのコメント
アクティビティの概要
さんの最近のアクティビティ James Sanford
James Sanfordさんがコメントを作成しました:
Hey Jason!
Apologies, the Satisfaction Score metric is only available in the Tickets Dataset and is comprised of attributes that are only available to the Tickets Dataset so it is not possible to recreate this within the Ticket Updates Dataset.
コメントを表示 · 投稿日時:2019年6月29日 · James Sanford
0
フォロワー
1
投票
0
コメント
James Sanfordさんがコメントを作成しました:
Hey Jason!
Please note that you are using a dataset that is not on the most current schema (Support: Tickets, Users, Organizations) and we would recommend following the process outlined in Which datasets use the latest data schema? to make sure you are using a current dataset schema.
Since you are looking to show this data based on the time of the event it would be necessary to use the Ticket Updates Dataset. If you wished to make a comparison between these two Queries we would recommend placing both of those on a Dashboard side by side so that you can see those long term trends in relation to the time of the event of those ratings. Please note that if you are using the Tickets dataset to view the long term trends of this and using a date dimension such as Date Solved then the you are seeing that data based on the Date the Ticket was Solved and not the Date of the Satisfaction Rating event. You may wish to move your current report over to using the Ticket Updates dataset as well if you wished to review those trends based on the date of the rating as well.
コメントを表示 · 投稿日時:2019年6月21日 · James Sanford
0
フォロワー
0
投票
0
コメント
James Sanfordさんがコメントを作成しました:
Hey Danny!
I think I've got a solution for you then but it would require the Zendesk Support Enterprise plan to make this work.
My suggestion here would be to create a new schedule to use just for your Talk routing. This schedule would be 5am-3am so that the 3am-5am window you wanted calls routed to your Overflow number would be considered "outside" the business hours. You can leave Voicemail On for Inside Schedule routing and only have that off for Outside schedule so that you'll get Voicemails during your desired timeframe and calls routed to your answering service during your desired window.
When your team has set themselves to Offline for Talk at the end of their regular shifts your calls would go straight to Voicemail based on there not being any Agents available to take those calls.
This suggestion could require other adjustments such as Triggers to set the Schedule that would be applied to tickets created from Talk if you have SLAs or other configurations that rely on your "normal" schedules.
コメントを表示 · 投稿日時:2018年11月28日 · James Sanford
0
フォロワー
0
投票
0
コメント
James Sanfordさんがコメントを作成しました:
Hey Danny!
My suggestions for this workflow require Zendesk Support (Professional or Enterprise) and Zendesk Talk (Team, Professional, or Enterprise).
Please make sure you have configured your Talk Number settings under Admin > Channels > Talk > Numbers > (expand the Number settings) Routing > Schedule to use the business hours schedule you have configured for your account.
Please ensure you have Voicemail disabled for the Inside Schedule and/or Outside Schedule for the option that aligns with your desired workflow under the Voicemail tab in the Numbers settings from the above screenshot.
You can then enable/disable Overflow routing for only the Inside/Outside Schedule you want calls to be routed to your Overflow Number for. If you have disabled Overflow for Inside Schedule then you will not see calls forwarded to your answering service if an internal agent fails to pickup a call.
コメントを表示 · 投稿日時:2018年11月24日 · James Sanford
0
フォロワー
0
投票
0
コメント
James Sanfordさんがコメントを作成しました:
Hey Nadia!
I was able to get this working after reviewing the Setup Instructions for Sending Messages in Slack which recommend using the text property for the JSON payload. Please keep in mind the Description is the very first comment for a ticket, so if you would like to pass a different ticket comment you'll need to update the Placeholder you use in your payload.
I hope this method will work for you as well!
コメントを表示 · 投稿日時:2018年11月03日 · James Sanford
0
フォロワー
0
投票
0
コメント
James Sanfordさんがコメントを作成しました:
Hey Lettie!
When building reports it's important to keep in mind how the date dimensions that you use to slice or filter your report align with the data you're looking to report on. Since the 'About' field may get updated throughout the course of a ticket before finally settling to the selection that best fits the nature of the inquiry you will normally want to report on this field's value after a ticket has been solved.
Reviewing the Insights Date Dimensions for attributes that align with solved tickets and a week interval indicates that a selection from the Date (Ticket Solved) folder such as "Week (Sun-Sat)" or "Week (Mon-Sun)" best aligns with the data you're looking to report on. As a general recommendation I would normally advise using "Week (Mon-Sun)/Year (Ticket Solved)" or "Week (Sun-Sat)/Year (Ticket Solved)" to ensure that your report shows you only the data you want to report on from the weeks in this year.
Insights: One-touch tickets is a great guide to get you started on 1-touch tickets reporting. If you needed to include the About field as a slice on this dataset you would just select the name of your About field from the attributes under How when building your report. You can reference Reporting on custom fields in Insights (Professional and Enterprise) for additional information on including your custom About ticket field in your reports.
コメントを表示 · 投稿日時:2018年7月10日 · James Sanford
0
フォロワー
0
投票
0
コメント
James Sanfordさんがコメントを作成しました:
Hey Geoff!
If you'd like to have your Agents suggest new articles be created we would recommend creating an article template for that. Within that article you can list the information that you're asking for those Agents to provide as the foundation for those articles which your team can fill out in the same manner as they would when flagging an existing article for review.
Your team can then route the flags from that Request Article Creation template to the appropriate team to have them work on creating those initially.
コメントを表示 · 投稿日時:2017年12月05日 · James Sanford
0
フォロワー
0
投票
0
コメント