Can I report on the received at address in Explore?

Return to top

10 Comments

  • Ryan Mumby

    I have some beef with this. It's sort of an excuse, and it's not actually correct.

    "It is not possible to report on what email address a ticket was received at because there is not a metric for the received at address of tickets."

    Received at is not the metric, received at is the attribute. The metric is # of tickets. And yes, received at IS an attribute that exists in zendesk about tickets. For some insane reason you refuse to include this attribute in the ticket data synced to explore. It existed in Gooddata for years, but you've stubbornly and seemingly without good reason been avoiding adding this to explore for a long time - there have been numerous questions and product suggestions that all have lots of traction and user requests, but nothing.


    Your work around also does not cover historical tickets which is extremely limiting, and frustrating.

    I would suggest you update your answer, because it is incorrect, and I would also suggest that you implement this asap because the demand for it is huge and there's been no good reason provided as to why it can't be done. 

    15
  • Oliver White (Admin)

    I agree completely with the above, received at is an important attribute which exists on the ticket data, so to not include this within Explore doesn't make a lot of sense to me. As above, I want to report on historic tickets which simply isn't possible via your suggested workaround.

    4
  • Terry Ehrhard

    Adding fuel to the fire - to make matters worse the "Received At" is actually TWO addresses, not one.  One address is the address Zendesk assigns as the recipient, which is actually the first system address in the TO line if there are more than one system addresses listed, and the other address is the Zendesk system address the email was sent to via Exchange.  These two addresses are not the same and not consistent because what the requester places in the TO line in whatever order is very different than what Exchange will determine how to send it.  If your requester sends to just a single address then there is no issue, but when they send to two or more of your addresses, then this is when this impossible scenario exists.

    This field needs to be broken up so that these two values are separated and completely agree this value needs to be in Explore.  Due to the inconsistencies of what I describe above and lack of being able to determine the true "Received at" email address since this value is NOT available via any API, the means to have these two addresses identified as a variable within the UI, via API and via Explore is critical.  The only way I have found to address this situation is to make a single trigger for EACH system address, meaning each external corporate domain address AND each zendesk system address.  In our case this would account for hundreds and hundreds of triggers (and eventually thousands) to determine what/how the email was received. 

    Unacceptable.....  Fix this Zendesk!

    3
  • Jamie Noell

    We have implemented our own version of "Created via" which includes tracking which "received @ email" as well as more detail about manual tickets vs. tickets truly raised by a requester in the Help Center.  While this works, this does mean ongoing maintenance each time we add a received@ email to our instance.  It would so helpful to have received@ as a attribute in Explore just as we have in a View.

    1
  • Meg Gunther

    I'm working to combine our various instances. I need this for historical purposes, not on new tickets. I'm super confused on why this wouldn't be available. Has anyone found a work around or anything for historical tickets?

    1
  • Julio R.
    Zendesk Customer Care
    Hi Meg,
     
    Can you provide more details about what would be your business case and what you are trying to achieve?
    -2
  • Yanni (Test Account)

    @Oliver White (Admin)

     
    I agree completely with the above, received at is an important attribute which exists on the ticket data, so to not include this within Explore doesn't make a lot of sense to me. As above, I want to report on historic tickets which simply isn't possible via your suggested workaround.

    _____________________________________________

    Correct! We are also doing migration, and the said workaround is not applicable for all old tickets.

    Workaround is retroactive, we are hoping for the availability of this attribute soon.

    2
  • Meg Gunther

    @Julio R.

    We've recently purchased another company and are moving there teams version of Zendesk in to our Enterprise version. They had 7 support addresses, having the ability to run an Explore report on the received @ would allow us to know the usage of each address. Currently there are three catch all addresses, since we can't search by triggers (since they don't add tags) there isn't a way short of looking at views that gives us the traffic level of each support address.  
    For future work, Were looking to track total traffic of each support address, which we can't do, We have over 160 triggers so adding a tag in to each and then keeping track of what each tag is so that I can reverse engineer that these tags equal this addresses seems like a massive lift when you can just enable the data point, this is not something that changes so it would only need to appear in one data set.  If you need more details please let me know. 
    Thank you!

    0
  • Julio R.
    Zendesk Customer Care
    Thanks Meg for the detailed description.
     
    I encourage you to upvote the following feature request: Report on Received At Email Address.
     
    Conversations with a high level of engagement get flagged for product managers to review.
     
    Aș per the retroactively workaround, for the time being I’d suggest exporting the data using the API and creating the reports externally. The property recipient designates the original recipient e-mail address of the ticket (Zendesk Support Address).
     
    0
  • Meg Gunther

    Thanks! I'll give that a go. 

    0

Please sign in to leave a comment.

Powered by Zendesk