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

Greer Davis
参加日2021年4月15日
·
前回のアクティビティ2021年10月27日
フォロー中
0
フォロワー
0
合計アクティビティ
11
投票
4
受信登録
2
アクティビティの概要
バッジ
記事
投稿
コミュニティへのコメント
記事へのコメント
アクティビティの概要
さんの最近のアクティビティ Greer Davis
Greer Davisさんがコメントを作成しました:
We also need this functionality. We use an answering service for low volume times, and we expect our agents to call the user back. We may be on the phone with the user for a few minutes, and then spend another not insignificant amount of time writing a follow up response to "count" our first reply time. But really, we replied as soon as we called back. There seemed to have been a way to do this in Insights (which we never used) and there doesn't seem to be a way to do this in Explore. If there's not a way to track this, is the suggestion to send the user an initial informationless email just to "stop the clock" on FRT so we can get a more accurate measure? Do we have to create a bunch of extra custom fields for this so we can track those instead?
コメントを表示 · 投稿日時:2021年4月03日 · Greer Davis
0
フォロワー
2
投票
0
コメント
Greer Davisさんが投稿を作成しました:
What is the problem?
We use PagerDuty and trigger words (and a few other things) to catch issues we know are going to present major workflow issues for customers - so far, this has worked decently well. However, some issues aren't major so we don't have trigger words (everything would set off PagerDuty otherwise!) and that's ok, unless we get a whole bunch of them at once, which would indicate a larger platform-level problem that might not be caught by our error logging tools. Our only indicator is a sudden increase in volume of tickets (for us it's something like 10+ within 5 minutes, but other higher- or lower- volume shops will be different).
Why is it a problem?
We have a contractual obligation to respond to system-wide defects, and we recently discovered this is a way things can manifest so we want to track it, and can't.
How do you solve the problem today?
On a hope and a prayer that our PagerDuty triggers and engineering logging alerts are enough.
How would you ideally solve the problem?
My first thought was to use automations that allowed tracking ticket volume (i.e. "x number of newly created tickets within y period of time") that we could set to notify PagerDuty that we need to look at the queue asap.
How big is the problem (business impact, frequency of impact, who is impacted)
So far it's only happened a handful of times, but I absolutely see it happening with much more frequency as our business grows. I could see it potentially happening a few times per quarter (pretty bad in terms of customer experience if we don't catch it). Our agents and leads are impacted since they don't necessarily see the whole picture in terms of volume, and our customers can't work effectively (we make public safety software so this is quite a large issue).
投稿日時:2021年3月02日 · Greer Davis
5
フォロワー
10
投票
2
コメント
Greer Davisさんがコメントを作成しました:
It's not useful to have reports that include everything that's closed_by_merge...most of our clients write in via email and don't bother with threading so we do a lot of merging. Many of my queries are a bit pointless unless we can exclude those tickets.
コメントを表示 · 投稿日時:2019年5月06日 · Greer Davis
0
フォロワー
5
投票
0
コメント
Greer Davisさんがコメントを作成しました:
We'd like to use this similarly to others who've posted here, as well as tracking "if we missed a call, who (if anyone) was online at the time? Do we need to staff up if we're missing calls?
コメントを表示 · 投稿日時:2019年4月10日 · Greer Davis
0
フォロワー
1
投票
0
コメント
Greer Davisさんがコメントを作成しました:
I'd also like to be notified of when the drillthrough feature works again. Is there an idea on timeline for a fix? We've been using this to check issues with individual tickets and spot checking the query is working correctly.
コメントを表示 · 投稿日時:2019年1月24日 · Greer Davis
0
フォロワー
0
投票
0
コメント