Recent searches


No recent searches

Konstantin's Avatar

Konstantin

Joined Apr 15, 2021

·

Last activity Aug 04, 2023

Former Certified Zendesk Support Administrator; Still active with the community.

Following

0

Follower

1

Total activity

93

Votes

3

Subscriptions

35

ACTIVITY OVERVIEW

Latest activity by Konstantin

Konstantin commented,

Community comment Q&A - Objects, workspaces, and rules

Nicholas Deary,

Instead of using the "Ticket Status" and "Updated Via" options, try using the "Ticket" option, as this allows for the "is updated" parameters. So your Conditions would look like:

Assignee | is | {agent's name}

Ticket | is | Updated

You may also want to add the "Current User is not Agent" option, to ensure that only your customers/end-users are the only ones triggering this rule...unless you want other Agents' updates to trigger this policy, then you would want it to say "Current User is not Assignee".

I hope this helps.

~Konstantin

View comment · Posted Aug 04, 2023 · Konstantin

0

Followers

1

Vote

0

Comments


Konstantin commented,

CommentBusiness rules

Chad Susa (Gravity CX - Zendesk Partner),

That placeholder works for all Custom Fields, no matter what type of Field they are. The main take-away about placeholders, if you use this for Drop-Down Fields, you will get their Tag identifier versus their "label"; For the "label" (i.e. user-friendly value), you will want to use ticket.ticket_field_option_title_. One other note when using the "label" placeholder option, if you have nested (i.e. drop-out) values in your Field options, you will see the value displayed as such:

Example

Field is called "Support", with the following options:

  • Access::Can't Login
  • Access::Portal Unavailable
  • Device::Not Powering On
  • Device::Replacement
  • ...etc

This is how you would see your placeholder values, when they are populated. Just in case, placeholders can be used in:

  • Automation policies
  • Trigger policies
  • Macros
  • Inbound and Outbound API Calls (via Webhooks)

I hope this information helps. If there is something more specific, please provide your Use Case and I will try to help answer your question/s the best I can.

~Konstantin

View comment · Posted Jul 19, 2023 · Konstantin

0

Followers

0

Votes

0

Comments


Konstantin created a post,

Post Discussion - Tips and best practices from the community

Tags are extremely powerful in Zendesk, and are used for all sorts of things, from API calls to Explore report generation. However, you can find your Tags section within tickets sometimes getting too lengthy. Here are some ways to make your tags work for you, while limiting the amount of characters needed for them.

 

Ticket Fields

For your ticket Field options, it is best to limit your tags to roughly 3-5 characters per Field/Sub-Field (i.e. using the double colon to create drop-out options). For example, you have a Field (Support Issues) with the following options:

  • Device Issue
  • Network Issue
  • Portal Issue

You would want to create your Tags as such:

  • sup-iss_dev_iss
  • sup-iss_ntwk_iss
  • sup-iss_port_iss

Doing this not allows you to properly identify the Field and the associated option, but also helps with keeping the number of tags that are applied to a ticket. The other item that assists with limiting tags on tickets, is using Conditional Fields on your Forms, as this will limit what Fields are visible on a ticket, thus limiting the Tags listed.

Macros

When utilizing Macros to add Tags to tickets (whether for reporting or to assist with ticket Automation), it is best to utilize the same formatting structure used for Field Tags, but using the "mcr" in place of the Field name/value. For example, you need a Macro to add the Tag "jump_sensor", your Tag in the Macro should be set to:

  • Macro Name:  Set "jump_sensor" Tag
  • Action:  Add Tag "mcr_jump_sensor" (without quotes)

This will help you to identify that this came from a Macro versus being applied via a ticket Field or Automation/Trigger policy.

Automation and Trigger Policies

For these, use the same format as Macros, but swap out "mcr" for the following:

  • Automation policies:  "auto_" (without quotes)
  • Trigger policies:  "trg_" (without quotes)

Again, just some helpful ways to make Tags work for you, while limiting the amount of space they take up within your tickets.

 

~Konstantin

Posted Jul 17, 2023 · Konstantin

1

Follower

5

Votes

2

Comments


Konstantin created a post,

Post Discussion - Tips and best practices from the community

Brands are normally thought of as a way to allow companies to offer customers ways to reach specific support teams; However, Brands can also be used to support your employees.
See Setting up multiple brands for details on configuring Brands.

For example, if you are looking to have employees submit tickets to specific internal teams, but you don't want them going through the process of manually generating tickets from the Agent view, you can setup a new Brand (with Help Center enabled). From there, you setup any necessary Fields, Forms, and Triggers (i.e. ticket routing rules), and ensure you have the "Agents can manage requests from Help Center" option enabled.

Example Use Case

You have your IT team (they support employees only) and your Customer Support team in the same instance, and want employees to submit tickets via the Help Center (Guide) portal.

Start by creating a new Brand that will be for your IT tickets to be submitted through. Once you create the Brand, you will need to enable the Help Center (Guide) portal, as this will allow individuals to submit tickets.

Once you have your Brand setup and the Help Center available, you will want to create your ticket Fields and Form/s that IT will need to support all employees. For your Form/s, ensure it is only visible to this new Brand, while ensuring the other Form/s are only associated with your Customer Support Brand. Also ensure your IT Form/s are set to be visible in the portal, otherwise no one will be able to access them.

Once all that has been completed, you will then need to enable the "Agents can manage requests in Help Center" option; This allows everyone (employees listed as Agents and those listed as End User, not just those listed as End User) to be able to access the Submit a Request button. Now just capture the URL to the new Help Center portal, that way your employees know where to go to submit their requests.

NOTE: If you need to limit ticket visibility, you can set all Roles to only allow Agents access to their assigned Groups, or you can set your IT Group to Private, so only those set as Requester or CC on the ticket will have access.

If for some reason you have strict compliance policies you have to follow, then I recommend having a second instance setup for your internal teams that need to be fully segregated from all other Zendesk users.

 

~Konstantin

Posted Jul 17, 2023 · Konstantin

1

Follower

5

Votes

3

Comments


Konstantin commented,

Community comment Feedback - Ticketing system (Support)

Stan Neumann,

See comments in the "Why can you not CC a support address or use in side conversations?" article.

Basically, you will need to add your email addresses as End Users within your Organization. To clarify, you will need to add your company (if it doesn't already exist) as an Organization, then add the emails as users of the Organization. From there, manually verify the email addresses and you should no longer see those go into the Suspended Tickets queue.

~Konstantin

View comment · Posted Jul 17, 2023 · Konstantin

0

Followers

0

Votes

0

Comments


Konstantin commented,

Community comment Q&A - Users, groups, and organizations

James Penny,

To go along with what Ahmed Zaid said, you will also need to select the checkbox next to the "Enable agents to manage requests from help center" option, otherwise only those set as End Users will be able to access the Guide portal side.

As a note, my company started off with this method, but then moved to having two instances, as we required some teams to have access to multiple teams' tickets (without being assigned to those Groups), while some teams needed to remain localized to just their Groups. Since some of the localized teams (like Procurement, HR, and Finance) couldn't have other teams seeing/accessing their tickets (Compliance/Security requirements), we moved them to their own instance and turned that Help Center portal into the "Employee Support" portal.

~Konstantin

View comment · Posted Jul 17, 2023 · Konstantin

0

Followers

0

Votes

0

Comments


Konstantin commented,

Community comment Discussion - Tips and best practices from the community

For my company, we labeled our Trigger categories as such:

  • 01 - Ticket Routing
  • 02 - Ticket Actions
  • 03 - Ticket Notifications

This was due to what we considered a priority. For us, the priority was ensuring tickets were routed to their proper teams. From there, ticket updates (i.e. automatic actions) were next on our list, with ticket notifications being least (necessary and valid, but not as high a priority).

Basically, it comes down to what you need to be top priority, and creating a grouping structure that helps you best organize them. This functionality was definitely a huge "step up" from the previous behavior, of just a large list.

~Konstantin

View comment · Posted Jul 17, 2023 · Konstantin

0

Followers

0

Votes

0

Comments


Konstantin commented,

Community comment Feedback - Ticketing system (Support)

@...,

Thanks for the quick response on this, and for providing some insight into some Roadmap work in progress; I look forward to seeing what comes out.

~Konstantin

View comment · Posted Jul 17, 2023 · Konstantin

0

Followers

1

Vote

0

Comments


Konstantin created a post,

Post Feedback - Ticketing system (Support)

This feature request is for adding the ability to have sub-grouping for Triggers.

USE CASE

Today, I am currently using the grouping for my Zendesk Triggers as such:

  • 01 - Ticket Routing
  • 02 - Ticket Actions
  • 03 - Ticket Notifications

Since our teams are growing, it would be nice to add sub-grouping to allow for better sorting and identification of Triggers; The format would look like:

  • 01 - Ticket Routing
         * Support
         * Provisioning
         * etc...
  • 02 - Ticket Actions
         * Support
         * Provisioning
         * etc...
  • 03 - Ticket Notifications
         * Support
         * Provisioning
         * etc...

~Konstantin

Posted Jul 06, 2023 · Konstantin

1

Follower

2

Votes

2

Comments


Konstantin commented,

Community comment Feedback - Ticketing system (Support)

I am also interested in the Jira sidebar app being able to connect to multiple Jira instance.

USE CASE

My company was bought by another company; The parent company and several of the children companies all have Jira. With our Support team needing to communicate with teams across various Jira instances, it would be nice if they could use the sidebar app to accomplish this. If not through a single sidebar app, then possibly have the ability to install multiple instances of the sidebar app to connect to the various instances, and have a way to label each sidebar app with the instance it is connected to.

 

~Konstantin

View comment · Posted Jul 06, 2023 · Konstantin

0

Followers

0

Votes

0

Comments