Can I report on the received at address within Insights? Follow

Comments

15 comments

  • Avatar
    Alice Chapman

    Is there a way to apply this trigger to update existing tickets?

  • Avatar
    Jessie - Community Manager

    Hey Alice!

    Triggers only fire when a ticket is updated, so if you went the Trigger route the change wouldn't be made until the ticket was updated. If you want to go the business rule route, you'd probably want to use an automation. Automations run on a regular basis, which means that all tickets would eventually get the update (unless they're in Closed status - Closed tickets can't be changed).

    You can also do a bulk update on your tickets right in the interface, or by using the API. One of these would probably be the best way to do it.

  • Avatar
    Alice Chapman

    Thank you Jessie!

  • Avatar
    Sebastiaan Wijchers

    I need reporting on this as well, but I'd rather not use tags. I also need to report historically, but even when I update tickets with the API, I can't update closed tickets. Wouldn't the support address be a nice addition to the data set in Insights?

  • Avatar
    Jessie - Community Manager

    Hey Sebastiaan!

    It wouldn't help with the historical reporting part of things, but have you thought about adding a custom dropdown field that you can set with a trigger based on the support address used? Then you'd be able to report on that field.

  • Avatar
    Daniel Cooper

    I would love to see this become a part of Insights reporting. This feels like a critical data point (and it is for my team) to understand where email volume is coming in.  We utilize apps like Select an Address to adjust the email address that we send out for email addresses we have decommissioned and are monitoring to ensure that volume starts to reduce to those accounts.  I would love to see two things: 

    An attribute for the original support address, and an attribute for the current support address.  These would help us understand our email flows much better than what we can do today.  I've added some feedback to product support for my request as well.  

  • Avatar
    Emily Littlefield

    You can sort of get around this limitation by creating a View for each of the incoming email addresses and then exporting the View as a CSV file. It would be ideal if you could do it in Insights so that you could add it to dashboards.

  • Avatar
    Rich (Edited )

    I definitely plan to use tags/groups/organizations to be able to slice and dice ticket reports across our various user cohorts. However, given received at address is not available in insights reporting I have no way to setup what would have been an interim stopgap solution for until I've made the necessary structural changes to the Zendesk to facilitate this reporting. Additionally, since closed tickets are read-only, I wouldn't ever be able to update any of those with the required tags to include them in a historical reporting data set. This is disappointing. For less mature Zendesks "received at" address is often the only way to segment out ticket volume across different user cohorts.

  • Avatar
    Jessie - Community Manager

    Hey Rich!

    I've pinged our Community Moderators to see if any of them have suggestions for how to work around this limitation. Hopefully they'll have some insight to share with you!

  • Avatar
    Daniel Cooper

    Hi Rich, 

    I you may be able to roll your own Received at reporting option as outlined below. 

    1. Create a custom drop-down field for "Received at" and include all of your support addresses as options. 
    2. Create a trigger that sets the drop down to the matching support address based on tickets created and received at the support address. 
    3. If you want to go further, there are apps on the marketplace that will allow you to hide/restrict these fields so agents don't tamper with them.  

    With this setup, you should be able to report on your newly created drop-down field to capture received at, and it doesn't require any agent action because your triggers will do the updating.  This won't help with closed tickets, and you would have to set the drop-down for any current tickets, but at least it gets you started for reporting on the Received at address where it wasn't an option before.  

    For those wanting an alternative option, our team actually created a variant of the Select an Address app that auto populates a text field with this data for us (it pulls the recipient address off a ticket and inserts it into a custom text field).  The app hides the field from agents, and allows us to not have to maintain triggers.  This is huge for us as we have several hundred support addresses and they change frequently so we don't have to administer hundreds of triggers just for reporting. 

     

  • Avatar
    Rich

    Thanks Jessie and Daniel!

    Daniel, these are helpful suggestions. I was about to begin the process of setting a unique tag for each support address but I will consider the dropdown solution. In a past Zendesk my company had two domains that were socialized to different end-user groups (support@companyinc.com and support@company.com) which created some headaches with routing/assigning based on received at address since it could have been either. And sometimes I needed to use the received at address as an "All" condition where I would not be able to put both variants at once. So I would set the tag for both variants and use the tag in all subsequent triggers as a proxy for received at address.

    The drop down method sounds like a slightly more elegant workaround which would accomplish all of these things as well as facilitate reporting. And I think looking at a specific drop down would be "cleaner" than looking for tags in reporting because there would be a lot more noise and potential for confusion or mistakes when using tags since there might be several similar tags to choose from.

    I'll need to also look into the Select an Address app and your variant as well...that sounds like even if I don't want/need to do it that way I can open up my mind to new approaches for other related situations.

  • Avatar
    Daniel Cooper

    Glad to help! Note our select an address app is based on the Zendesk Labs one on Github, but has been extremely customized. What we are doing in the app to do what you are asking is reading the recipient address and populating a hidden text field when the ticket is opened by an agent. That might be much simpler to implement on its own if you don’t need the select an address app’s standard feature.

  • Avatar
    Rich (Edited )

    I guess, one more question on this...what marketplace app can allow me to make certain fields read-only for agents? Is there one?

    There is another thread (started in 2013 lol) requesting this feature which I've already upvoted.

  • Avatar
    Daniel Cooper

    I'm not aware of one for read-only fields, but you may find some luck with the Hide Ticket Fields (free) app.  I haven't used this app myself, but hiding the field is how we've limited our app.  I would expect that your agents may still be able to change the field with macros but you can assess that risk on if hiding is enough for you.

    Since the app is free, there is little limitation to testing if the app will meet your needs.

  • Avatar
    Rich

    Very cool, I think hiding it ought to be good enough. Thanks again for for your help Daniel!

Please sign in to leave a comment.

Powered by Zendesk