Tom McLellan

Hi Gishani, 

In our case we're dealing with small business owners and consumers who are already a bit frustrated at having to contact Support. The context is they need help with our software product because it's not sufficiently self-serve or is too hard to use, so the last thing we want to do is put up another barrier when they're trying to get help. 

We make it very easy to contact us through a custom “contact form” that's pre-authenticated to the user within our app, so the majority of our tickets are pre-authenticated. We still allow cold inbound email… we just make a point to reply and confirm on any account-impacting issues. For example, if someone wants to delete their account, we explain we can do this and ask them to reply “remove” or “confirm” etc to our email, and the fact that they received our email and replied, we take that to mean they are the authenticated email owner.  

We're due to add MFA soon and I expect we'll limit some of our email support options for MFA customers. For example, destructive account actions would require logging in with your MFA device. 

I suppose if the user had DMARC email authentication on their sending domain, maybe that could be a way to validate that they really do belong to their sending domain (e.g. it might be cool if Zendesk showed a checkmark or something alongside a DMARC-validated inbound email). 

We still haven't moved to the chatbot approach yet however we have relatively low volume. At some point with AI improvements it would be a nice addition. Hope that helps! 

Thank you Dane for the creative workaround, we'll give that a try.

Here's my use case: 

We get some regular test tickets as part of an automated testing process run by a large customer / software company. I just want to set a rule so "every ticket from user@email.com should be closed or deleted automatically"... like a gmail filter, but applied to our helpdesk.  

I think there's a usability problem because I can't figure out how to do this. It seems like I should be able to do this through Business Rules (screenshot below), but the interface just teases me with a "present" / "not present" option. I can't figure out where to match an actual data value (in this case, an email address of the automated test user). 

Can someone please tell me how to do this or confirm if this is actually a product limitation?  In case it helps, we're on the Growth Suite. 

Thanks, 

Tom 

It seems like there are two different use cases here:

1 - Embedding Zendesk HC resources into an app / website so users can access articles/resources in context. Ideally there would be a Guide Settings > Security option where the admin can disable "X-Frame-options" header.

2 - Embedding potentially unsafe HTML: This could be better managed with a Content-Security-Policy so the account admin / developer could set some parameters on safe/unsafe resources/scripts/css/etc.  

I'm working on use case #1 for an Ionic app (iOS, Android, and single page app for web) with one code base. We're not relying on Zendesk for any direct user authentication. Without the X-Frame-Options, we're looking at these workarounds for help center articles: 

a) Use the zendesk API to load specific articles  

b) Implement the deprecated Support SDK for iOS/Android and classic web widget for web users 

c) Implement messaging SDK / web widget, but it seems to be missing some key features around JWT authentication  

d) Break context and kick users out of our application into the help center site through a browser or new tab. 

e) Use a different CMS for our help articles 

Maybe I'm missing something and there's an easier way? I was hoping to simply show the help center in an IFrame with our existing in-app "Contact Support" button at the bottom. 

Update: In case it helps anyone, we went with option (a) Zendesk's article API to list and show articles directly in our single page application since iframes are not allowed. We're also experimenting with linking over to help center pages directly in a new tab / browser. 

Thanks Lou for clarifying, I see what you mean. The (awful) chat experience makes a good case for letting customers choose, though allowing for a cold inbound email does create some questions about authentication (e.g. you need the customer to reply again in order to confirm/proceed with any serious account changes, to avoid the risk of someone spoofing/imitating an email address). 

Thanks for both your comments.... that is interesting, you may be on a better pricing plan. I'm not able to send emails to support@zendesk.com anymore (it bounces back with a reply) and get forced to use the chatbot / live chat option instead. I've noticed that Twilio Sendgrid has recently phased out their email support as well. 

I think we'll experiment with live chat and in-app messaging but continue to offer email support. 

Hi Allen Lai | Head of CX at Otter.ai, thanks for sharing this - it's an interesting question of how and whether to remove email support.

I did a related post (https://support.zendesk.com/hc/en-us/community/posts/4647146945690-Pros-and-Cons-of-Removing-Email-as-a-Support-Channel) and wondered if anyone has any metrics or experiences on this before seeing your post. 

If you do discontinue email support, it would be interesting to hear how you managed the "Can't login" scenarios and how / whether it changed any key metrics. Thanks 

I've noticed a trend of some larger SaaS companies like WPEngine and Zendesk deciding to go all in on live chat / bots and remove email as a support channel, including the removal of "support@domain.com" type emails.  

I'm sure there isn't a one-size-fits-all answer to this, but as I'm looking at future support strategies for my software business, I'd like to understand:

- What are the main benefits (for our company and/or our customers) of shutting off email support and requiring all help through live chat?  Does it actually lower ticket volume and/or time per ticket? 

- Is there a risk that existing customers find it frustrating to lose the email support option and churn?  

I'd be curious if anyone with a smaller customer service operation has tried this recently and what it did to their support volume, metrics, and/or churn. As a customer, it seems like this is an ongoing trend, so I'd like to understand the rationale and plan our support channels better. My current thinking is to meet customers where they are (within reason) including email support. 

Thanks, 

Tom 

We use Zendesk as an email ticketing system because our customers find email to be faster and more convenient than trying to connect over chat. 

For example, the option to re-assign a ticket to another agent (by selecting them from the dropdown) wasn't working, so I sent a quick message to support@zendesk.com. I got an auto-reply telling me that Zendesk had discontinued email support and that I should contact Zendesk through messaging. 

While logged in the Agent interface, I tried to start a live chat, but the chatbot insisted on asking for my email, even though I was already logged into the Agent interface, and then wanted to send me a PIN code to verify my identity. That would seem unnecessary if the messaging widget were properly integrated to the Agent interface... we wouldn't do this to my customers because they wouldn't like the extra friction, and our NPS would suffer. 

At some point, I'd love to offer customers more choice including a messaging option, but I would only roll it out when it's properly integrated for an easy and fast experience. 

I've been a huge fan of Zendesk but the irony of not being able to send an email to your support team (regarding your email ticketing features), and having to spend more time through your messaging channel, seems at odds with your mission of being a service-first CRM company that builds software to improve customer relationships. I'm sure the idea looked good on paper, but I hope you introduce email again in the future, or even an option to pay more and get support by email. Thanks for leaving this post open and allowing for feedback.