Report on Received At Email Address
CompletedIt is important that we understand which email addresses are receiving the most traffic. It would be helpful to include "Received at" email address in the ticket attributes sent to Explore.
-
Official comment
Hi all,
Ticket email address attribute was added to the Support: Tickets dataset.
The complete list of attributes and their descriptions can be found in the Metrics and attributes for Zendesk Support.
-
Bumping this one again, in the hopes that an Explore PM will catch it and respond.
This would be a really big help in identifying popular channels of contact. We're currently trying to consolidate and deprecate some addresses, but we can't tell which ones receive volume, making it really hard to tackle this project intelligently. The only way we could get this data historically is to try to export and iterate through several hundred thousand tickets via the API, which is a waste of dev resources.
This data's already part of the core ticket model (it's the "recipient:" attribute) it would be very helpful to have it made available in Explore. I won't presume to know what's involved in adding a new attribute to Explore, but from the end-user side, this feels like a really easy win.
Thanks for considering!
-
Yes, we would really appreciate the ability to run reports directly based upon the email address through which the inquiry/ticket was received. It's much cleaner/safer than having to go through an intermediate step of creating a trigger that creates a tag, or having to base it on the group/agent these tickets were assigned to . . . any of these could have changed during the desired reporting range (or you thought of them too late) . . . then you miss the opportunity to get the data you need.
Thanks for considering this!
Mark
-
A second +1 from me! I really needed to be able to build a report off this data today and was let down.
This is already an attribute on the ticket model in Support, can it please be added to the Explore Dataset?
Thanks!
-
This is essential to our business, we need the option to report on volume of incoming tickets received at each of our Support email addresses. This is quite an old thread (4 years?) but I was encouraged to post here, any updates to speak of?
-
Upvoting this as well. I was looking to provide data to teams that have email addresses setup but never utilized email as a channel. It makes it very hard for us to maintain our instance from an administrative view if there is a lack in data that is available for us to share with our customers. Eventually we will have tons of stale data in the system, and no way to report on what is being used vs not. Please add the received at email attribute to explore.
-
Yes please! This would be extremely helpful so that we can see which products and customers make more use of email tickets. We'd love to stop inbound email as a channel, since it takes the longest to get the data we need to help the customer. Being able to see which products and regions are ready for this switch would be great!
-
+1 on this topic as well.
We have about 13 e-mails, each pertaining to a type of customer.
I have just checked and my GMail inbox says i've received about 1700 emails on a time frame, but only 637 tickets have been created. We need to know what is, and what is not generated, as well as if something was created but was assigned to another Team.
-
@... - not much of a worry I think but rather wondering why ZD aren't adding the "received at" as attribute given this is a great help for us.
The work around you're providing is kinda tedious given we have so many email address where ticket was originated.
Again, this thread is running for almost 5 years now. -
We have 70+ email addresses within our Enterprise account and depend on being able to see how many tickets we receive per address. There is a workaround with adding a specific tag to each ticket allowing to identify the "received at" email, but it is not beautiful. Therefore having an attribute in Explore to report upon is critical for us.
-
Yes, pls build this attribute.
-
Hi all,
Quick update on what we're doing:
We use a custom dropdown field called "Received At" (not to be confused with "Received at" in business rules). We add each email address to the custom Received At field. Then, we create a new trigger for each email address in our instance. If the Received at value = xyz@abc.com, the Received At (custom) value is set to xyz@abc.com. And so on for each email.
The custom field is reportable, and the business rules set it based on the Received at value when the ticket is created through email. I hope this is helpful to other teams as well!
-Z
-
Hello Eugene Orman - we currently now at H2 of 2021 but we still haven't heard anything from the Zendesk team about this request.
As per your comment you will be looking for alternative on the 2nd half of 2020. Kindly give us an update on this request and where it standing now.Thanks!
-
Would hate for this to hit 6 months without a comment and disappear.
The workaround doesn't work for me because it doesn't capture historic data, but also because we use wildcards in our forwarding rules, so an email could be received in Support without that specific address being configured in advance.
For that matter, I was surprised I couldn't use received_at in an advanced search query.
-
Indeed, we would truly see the value in the capacity to run reports straightforwardly founded on the email address through which the request/ticket was gotten. It's much more clean/more secure than going through a middle of the road step of making a trigger that makes a tag, or putting together it with respect to the gathering/specialist these tickets were allocated to . . . any of these might have changed during the ideal revealing reach (or you considered them past the point of no return) . . . then, at that point, you pass up on the valuable chance to get the information you want.
A debt of gratitude is in order for thinking about this!
-
+1 we need this attribute
-
+1 We also need this capability in Explore
-
Our company is looking to clean-up our 30+ existing support addresses. We could use an attribute like this to help us understand which email addresses are being used and which emails we can phase out.
The suggested workaround is not helpful for our use case. It would require creating 30+ triggers and it would not include data on past tickets.
-
This would definitely be nice to have. We use MANY different incoming email addresses for many different reasons to "segregate" tickets. What's odd is that this attribute IS available in a view. Unfortunately, views only go back so far (6 months, I think?) whereas Explore goes back as far as you'd like.
-
Last update from Zendesk was 7 months ago indicating this might be added in the first half of 2020... We're in July now... Any update here? We need this, too.
The "workaround" only works if it was set up from the beginning, so it can't account for closed tickets.
-
Still no update on this matter ?
Zac solution isn't a solution.
It doesn't take into account all previous history.
-
Hello Eugene Orman - is there any update with this attribute? It's been 3 years since it has been raised.
-
+1 this really needs to be added in Explore.
-
Piling on here, please add this to Explore. This is yet another basic item that is missing from the move from GoodData.
-
+1 to have this date in Zendesk Explore. This is an obvious question (since a while) and should be available in the reporting tool. Hope to see soon a real action plan.
-
+1 great to have this feature soon
-
That's +1 from me as well. It seems very odd that this information is not accessible in the reporting framework. We have quite a number of different email channels and want to report on tickets created via different channels.
-
This was an extremely helpful answer. Adding the custom tags as part of a trigger on incoming tickets for each Received At address is helping us get the data we need for one-off reports for the time being, but does not help historically, so hopefully this feature can be added soon.
-
+1
-
Any update here? This feels like a huge miss to not be able to pull reporting based on received at.
Please sign in to leave a comment.
64 Comments