Michael H

^ What @Jeremy Robinson said, times infinity.

Modification of the sign in window should be one of the elements customisable in a Help Centre theme, and it's strange that it isn't.

And sign in options need to be far more granular. It shouldn't be limited to just what Zendesk choose to offer; but whatever your end-customer wishes to offer to their consumers.

If they want to offer LinkedIn sign in, develop a login to a custom system, offer a platform independent OpenID connect method, or kill off the sign-in window entirely and instead redirect everyone over to the end-customers SSO system to ensure a consistent presentation of login, security and brand to their users - then that should be available.

And honestly, this shouldn't be hard to do, and shouldn't be so far down the list of enhancements that a five year old thread is still receiving much the same comments and requests.

Am I missing something with implementing this code?

Reading the thread, and taking the last post from @Tim, I understand the totality of the implementation path being this:

1. In Guide, go to /theming/workbench
2. Select your theme, and press view theme.
3. press Edit code.
4. Edit script.js, and add the code to the end of the file. Save changes.

And that's it - it should display right?

Having followed these steps on my Guide instance, running the Copenhagen theme, I don't get anything let alone the change i'm expected.

Here's a page from my Guide instance which I would hope gets this auto TOC:
https://help.wafresh.com.au/hc/en-au/articles/360007488692-What-happens-if-an-item-is-out-of-stock-or-unavailable-

Appreciate any help or feedback to understand where I'm going wrong.

I've got it, finally figured out how to exclude signature from SMS messages.

See the updates to the original post.

Also thanks to a 4yr old post which helped me stumble on the method:
https://support.zendesk.com/hc/en-us/articles/203662146/comments/203487578

@Brett: FYI - I'm now dealing with Support on this, and I agree that removing one or more of these might be the solution.

The problem is relying on a tag-based solution means that if the tag isn't there, it goes via another channel.

So i'm wanting to build this in a way that caters for the 'lowest common denominator' agent, who can and will forget to add tags, which in turn could prevent the customer receiving the response through the same channel - thus creating avoidable customer frustration and in turn increase interaction cost and retention/satisfaction risks.

I'd also hope that by the time I get to the end of resolving this, I can actually share a 'missing manual' style post for helping people get their SMS setup on Zendesk right (because as a result of going through this process, I've discovered a lot of gaps which will trip users up and impact service).

I couldn't agree more with this, and if I could upvote it by more than one I would.

The WYSIWYG formatting options for tables leave a lot to be desired, and unless you have patience to get into the HTML (or worse - the style sheet for your help centre) and use your experience there to deliver a better table experience, it next to impossible to do things easily.

And this in turn creates a barrier to entry for smaller and growing business who don't have HTML, code or design experience in their arsenal; as they can't take advantage of the benefits Zendesk Guide can provide for better customer experience and reducing the overall cost of omnichannel support provision by decreased human interactions and shorter interaction lengths.

Has anyone found, or do you know of, a definitive guide for properly making Zendesk Support work with the SMS components of Talk?

Specifically:

1. SOLVED: Proper Triggers rules to ensure that replies to inbound SMS messages are replied to as SMS.
2. SOLVED: How to configure an agent signature to ensure that it isn't used in responses to any SMS communications; using ticket tags and liquid markup in the account-wide signature to create some cases that define the signature contents.

 

Where I was stuck:

1) Updates to tickets not being SMS'd to customer:

When i've created a ticket where I've specified the requester by entering their phone number into the Requester field, the first message has gone without problem.

As discussed later in this post, removing one of the channel actions gets it done.

Will update all the screenshots for my trigger recipes to show how this is done.

2) Preventing signature being included in SMS

This is solved by the use of tagging the ticket with certain tags, AND using liquid markup in the signature.

In short, I've used liquid markup to look for three tags in a ticket. If anyone of these three tags occurs, it creates a case statement which has no content. And then there's the else result where none of these tags appear.

Code to achieve this:

--------

{% assign tags = ticket.tags | split: " " %}{% for tag in tags %}{% case tag %}
{% when 'sms-outbound' %}
{% when 'sms-apioutbound' %}
{% when 'sms-inbound' %}
{% else %}
Kind regards,

{{agent.name}}
Customer Service Team
Your Company Name
{% endcase %}{% endfor %}

--------

 

 

Original public response, which correctly triggered outbound SMS

 

Follow-up public response which triggered no action at all

 

Trigger to cause outbound SMS on new ticket

 

Trigger that is supposed to cause outbound SMS on an update to a ticket, but isn't

Agree with OP. This change to the Facebook response workflow for wall posts is needed.

It's just a mess when responding now, as it all looks out of place.

At the moment, we handle wall posts through Facebook Page Manager, and when it's all done - return to zendesk to take ownership, tag and classify, before marking as solved.

That strategy however is ok for a smaller company like ours, but doesn't scale at all to larger organisations.

@Manon: Do you have an example of the email (both visual and text/code) you can share that demonstrates the use case and problem you’re trying to solve, along with some sample links?

Would help me and potentially others both visualise and understand the problem you’re trying to solve with this use case, to lend our support or input.

Yes, and please.

Absolutely agree with the OP, there's a real need to update the Trigger mechanism to prevent the possibility of other processing triggers being applied once a specific one is done.

I should be able to say "Once you've done all of this, don't do anything else - ever, otherwise my day as an Admin might be painful if someone else has written a bad trigger which I have to spend ages hunting down to correct".