Recent searches


No recent searches

Dan Sowden's Avatar

Dan Sowden

Joined Apr 15, 2021

·

Last activity Feb 28, 2023

Following

0

Followers

0

Total activity

27

Votes

12

Subscriptions

9

ACTIVITY OVERVIEW

Latest activity by Dan Sowden

Dan Sowden commented,

CommentTicket customization

There appears to be a limitation for this field type which I've not seen for any other ticket fields:

I'm not able to find any documentation explaining this limitation, bit this is a total of 5 such fields including deactivated fields - not just active fields.

View comment · Posted Aug 31, 2022 · Dan Sowden

0

Followers

1

Vote

0

Comments


Dan Sowden commented,

CommentTicket customization

Hi,

I'm really excited about using this new functionality, but I have some observations about the two biggest challenges I foresee in us adopting this:

Firstly, for user objects we have a drop-down that's hard-coded for a list of our agents to add an "Incident Manager" field on tickets. For this we have triggers to automatically update this value on first assignment and agents maintain their own views of their tickets. We could easily switch this out using a lookup relationship field, except that the main benefit should be to add a view of "My Managed Tickets" where the condition is to have the incident manager = "(current user)" instead of having each agent maintain their own views, but this is not an option. Also, we could retire all of the agent specific triggers with a single one that updates the field to "(current user)", but the same restriction applies here.

Secondly, for ticket objects - for some incidents we always want a problem ticket to be created, so we could use one of these fields for this purpose and make it mandatory for solving the ticket. However, where we currently use problem tickets there's an easy way to view all incidents linked to it - this won't exist using a lookup relationship. The best solution I can find would be to search for "fieldvalue:1234", which may bring back other tickets which have a number the same as the ID in a different field, or the even less convenient search "custom_field_64286819...:1234" and have all agents save the field ID for searching.

I think these would be the two main sticking points I will have with my agents if I try to move us across to this feature - which is a shame because I suspect that these will stop us fully embracing this great new functionality.

Can you confirm if these two cases have been considered or what the roadmap looks like to more fully integrating these fields into other areas of the system?

Thanks in advance!

Dan

View comment · Posted Aug 16, 2022 · Dan Sowden

0

Followers

3

Votes

0

Comments


Dan Sowden created a post,

Post Discussion - Tips and best practices from the community

It is becoming increasingly common to see pronouns in social media bios and in email signatures. There are many great reasons for including pronouns, which are best explained in one of the many articles written on the subject - for example this article in the Zendesk blog titled "Why gendered language is everyone's business".

Adding or providing pronouns in communications can help to show you as allies, can help people feel welcome, and show that you as an organisation are inclusive and won't discriminate.

However, there isn't an immediately obvious way to include these in a standard way across all of our agents - and also in a way that would be optional per agent.

Solution: Allow agents to include their pronouns using Signatures

This can easily be achieved using the signature functionality - so agents can then add in their gender pronouns if desired or not if they prefer not to:

How do I do this?

Step 1 - Update the signature in your Zendesk

In the Signature/Agent Signature text box (for instructions on how to find this, follow the steps in this article), enter the following signature text:

**{%if agent.signature != blank %}{{agent.signature}}{% else %}{{agent.name}}{% endif %}**
Company Name
[CompanyWebsite.com](http://www.companywebsite.com/) | [LinkedIn](https://www.linkedin.com/company/company-name/)

This will include the agent signature in bold if the agent has one defined, or the agent's name/alias if they do not.

Below this, you can include your company name and any links to company websites and/or social media pages using the standard Markdown syntax.

Step 2 - Have your agents update their signatures

Your agents will need to navigate to their profile page:

And set a signature which is their name and their gender pronouns:

If they do not have a signature specified, then their full name (their Alias if it's specified, or else their name on their profile) will be used in its place.

Step 3 - send public updates on tickets

As soon as this has been configured, all public updates will automatically be suffixed with the signature and will be included in emails and ticket updates as viewed on the Zendesk request portal.

Posted Mar 16, 2021 · Dan Sowden

1

Follower

5

Votes

4

Comments


Dan Sowden created a post,

Post Discussion - Tips and best practices from the community

It's handy to collaborate or refer tickets to other teams by assigning tickets over or using the @mention feature, however some workflows may require the entire ticket history to be included in an email, using the ticket.comments_formatted placeholder.

This is especially useful if you are working with light agents, or with agents who prefer to read the full history in a single email and reply rather than logging in to Zendesk to review the history before replying to the email. 

But on the other hand, with this placeholder comes a risk that the latest note may not be an internal note and the entire thread could be forwarded on (including any internal discussions) to clients or customers who should not see the internal notes.

This can most likely happen where an agent or light agent is copied on a ticket for information and wants to chip in or forward an interesting public update without realising that the top update is not the only one included in the email.

Solution: Add a warning to the top of the emails

The easiest way to warn agents of this potential pitfall is to add a big red warning across the top of the email whenever the ticket contains any internal notes:

This will make all agents pause before sending any ticket history outside of the organisation.

How do I do this?

To add this warning, you can leverage the liquid logic to check for any internal notes and add the warning if so.

In your automation/trigger/CC text which includes the ticket.comments_formatted placeholder, simply prepend the email body with the following block (removing the whitespace, which has been added here for clarity):

{% for comment in ticket.comments %}
{% unless comment.is_public %}



THIS EMAIL CONTAINS INTERNAL NOTES WHICH SHOULD NOT BE FORWARDED TO CLIENTS


{% break %}
{% endunless %}
{% endfor %}

{{ticket.comments_formatted}}

ie. as below -

And that's it!

Once you have added this block before all instances of the comments_formated placeholder, you can be assured that there is an obvious warning included on all emails which could contain internal discussions which should not be forwarded.

Posted Dec 07, 2020 · Dan Sowden

0

Followers

6

Votes

3

Comments


Dan Sowden commented,

Community comment Feedback - Ticketing system (Support)

+1 for this

We've implemented a flavour of the 'bump bump solve' process that will send an email to the requester on a date driven by a date ticket field, but there's no way of clearing the date when the client replies. This means we've had to implement some triggers to default the date, but it's added some complexity and some risks of accidentally emailing at the wrong time to what should be a fairly simple process.

In an ideal world we could have a single trigger that checks if the date is "not present", and default it to X days in the future - but because we can't clear it when the requester replies, we also need to check if the date is in the past (which isn't possible directly, so we check if it's in the previous 9999999 days) or if it's in the next X days before we change it to X.

View comment · Posted May 22, 2020 · Dan Sowden

0

Followers

2

Votes

0

Comments


Dan Sowden commented,

Community comment Feedback - Ticketing system (Support)

+1. The level of control around editing, deleting tickets, adding tags etc. should be available for users and organisations too - it's far too easy and destructive for agents to delete users instead of simply suspending them.

View comment · Posted Apr 04, 2018 · Dan Sowden

0

Followers

1

Vote

0

Comments