Fine Tuning: How to build your ideal workflow

This Fine Tuning is about what to consider when building your workflow, including:

• Triggers and Automations
• Business Schedules and SLAs
• Macros and Views

Also, be sure to check out Part 1 of this Fine Tuning discussion.

To find more Fine Tuning articles, see Fine tuning resources.

Part 1: Triggers and Automations

My last Brick by Brick Fine Tuning covered the basic pieces you’ll need to build your ideal Zendesk instance and how you can configure them to meet your specific needs. This time, I will dive into the remaining bricks to help you piece together your ideal workflow.

Triggers

Triggers are wonderful things. They are event-based system actions that run on either ticket creation or ticket update. There are many ways to utilize triggers in Zendesk, but they can all be boiled down to these few categories:

• Assign tickets to a specific agent or a group of agents.
• Change ticket field values or add/remove tags.
• Notify users (or targets) of created or updated tickets.
• Change user or organization field values (on ticket update only)

Potential pitfalls:

Zendesk has a few standard triggers that you may want to deactivate or alter. If you don’t check through your list of triggers before you go live, you may end up with an inbox full of unwanted notifications.

The Notify Requester of comment update default trigger is the most important trigger in your account. This is the trigger that sends your ticket comments to your end users. If you alter or delete it, be aware that it may impact your ability to communicate with your customers.

Try not to have each trigger do too much. The more complicated your triggers are, the harder they will be to troubleshoot and maintain.

If you have an open Zendesk Support instance where anybody can submit tickets and no registration is required, first-reply triggers (that fire upon ticket creation) using any of the placeholders below can be targets for relay spam.

• {{ticket.title}}
• {{ticket.requester.first_name}}
• {{ticket.requester.last_name}}
• {{ticket.requester.name}}

Relay spam occurs when mail is sent to a destination via a third party (in this case, Zendesk) to hide the source of the email address to impersonate the 3rd party. These placeholders are targets for relay spam because they use an anonymous endpoint that allows anyone to enter any text or links they want.

To avoid the risk of your account becoming a target for relay spam, consider configuring your instance to be closed or restricted, as discussed in Configuring end user access. Otherwise, in an open Zendesk Support instance, do not use the placeholders listed above in the subject or body of your first-reply triggers; use static text instead. This ensures that the email notification that is sent when a ticket is created, for example, does not replace a salutation intended to say “Dear Amanda Smith” with “Dear www.spam.com.” Using these placeholders in other triggers (after the first reply) is acceptable because, at that point, you’ve established that the interaction is genuine.

Best practices:

Use a naming convention and stick to it. Ideally, you will be able to tell a trigger’s function based on its name. It’ll save you quite a bit of time if you don’t have to click into each trigger to see what it does. Here are some examples:

Set Priority - Normal

Set Schedule - North America

Assign to Group - Tier 1

Notify Requester of Comment Update

If your list of triggers extends beyond one page, the naming convention will be very important. You can search for triggers based on title.

The order of your triggers is important. The system will check against every trigger every time a ticket is created or updated. My suggestion is to order your triggers in the following way:

1. Change/Update ticket values - triggers that change ticket values such as priorities, status, any other field value, or add tickets should be listed first. This is because these triggers can impact ticket assignments and notifications.
2. Ticket assignments - triggers that assign tickets to groups or individual agents should be listed after triggers that update any other value on the ticket.
3. Notifications - triggers that send notifications to users or targets should be listed last. This is because you will want the system to make any necessary changes before you send out notification emails.

Within each of the categories listed above, you will want to order your triggers from specific to general conditions. This will prevent your catch-all triggers from firing over your more targeted triggers.

Keep your triggers simple and deliberate when possible. The simpler your triggers are, the easier they will be to maintain as you scale or change admins.

Questions to ask yourself:

1. Do your agents live in Zendesk all day or in their email?
2. Which of your agents need email notifications?
3. When do they need to be notified?
4. When do your end users need to be notified?
5. Which items in your workflow can be automated?
6. Which items in your workflow need to be automated?
7. How should your notification triggers be worded?

Learn more about how to create and manage triggers here. 

Automations

Automations are time-based system actions. They run on an hourly basis, and usually have time-based conditions. You can use automations to do the following:

• Assign tickets to a specific agent or a group of agents.
• Change ticket field values or add/remove tags.
• Notify users (or targets) of created or updated tickets.
• Change user or organization field values.

You may have noticed that the actions that can be performed by automations are the same as the actions that can be performed by triggers. The difference between the two is not which actions they can perform, but which conditions can set them off. Automations allow you to perform system actions when it has been x hours since or x hours until an event.

Potential pitfalls:

Automations only run a maximum of once per hour. This makes it difficult to rely on them for high priority updates. If a ticket comes in even one minute after your automations run, it may still see the ticket as 0 hours since created an hour later when they run again.

When you set a hard time-based condition (such as Hours since created is X) instead of a softer catch all time-based condition (such as Hours since created is greater than X), your automations may not run during the hour that your ticket qualifies. This puts you at risk for missing important notifications or ticket updates.

Best practices:

Before creating an automation, ask yourself if it’s better to use a trigger or an automation for the desired results. In many situations, triggers are more effective because they can be fired instantaneously.

When possible, use the greater than/less than conditions instead of the is conditions when creating time-based automations. This eliminates the possibility that your ticket slips through the cracks without firing the automation. Note that when you do this, you will need to add a nullifying condition and action in order to prevent a loop (the system will warn you if this is necessary).

To make this work, simply have your conditions check for something (like a tag or field value) that the ticket shouldn’t have before the automation runs, and then make sure that the automation makes a change that disqualifies the ticket for the next time the automation runs. This will ensure that the automation does not run multiple times.

You can use automations to create an automated bump, bump, solve workflow. This ensures that your tickets don’t go stale if the requester fails to respond, and also keeps these tickets from unnecessarily clogging your views.

Questions to ask yourself:

1. Should this be a trigger or an automation?
2. Do you need the system to notify you or take action when a ticket has gone stale?
3. How long should a ticket be in the solved status before it is closed?
4. How should your notification emails be worded?

Learn more about how to create and manage automations here.

Part 2: Business Schedules and SLAs

Business schedules

Business schedules may not be as flashy as triggers or automations, but they can still play an essential role in your workflow. Setting business schedules allows you to:

• Perform system actions with triggers and automations inside or outside business hours.
• Specify time in business hours (instead of calendar hours) within automations and SLAs.
• Provide accurate service targets through SLAs.

Potential Pitfalls:

The first schedule in your list is your default schedule, and it will be applied to all new tickets. You cannot rearrange your schedules, which means that you cannot set a new or existing schedule as your default schedule. You will need to delete every schedule above it (or change its name and properties) in order to set a new schedule as a default.

You can add holidays to your schedules, but they do not carry over from year to year. This means that you will have to enter them for each year manually.

Holidays are dates that will be taken out of your business schedule. This means if you only work a half day, your business hour-based SLAs will be paused all day. (It could be a good thing, depending on how you look at this.)

You cannot clone schedules. This means you’ll need to enter your holidays each year on each schedule manually.

Make sure to set your time zone! Your schedule will only be effective if it’s in the correct time zone. On some plan types, you can set the timezone on each individual schedule. On other plan types, you can set the schedule here.

Best Practices:

Make a plan before you start entering schedules. Enter your default schedule (if you have one) first. This schedule will be applied to all new tickets by default, which means that any SLAs applied to the ticket using business hours will follow this schedule.

If you use multiple schedules, use triggers to assign schedules to tickets. For example, you could create a trigger that assigns to schedule x when a ticket is assigned to group x. If you do this for all schedules, it won’t matter which one of your schedules is set as the default.

You can’t clone schedules, but you CAN clone holidays! You still have to enter them manually, but you can at least clone them and change the dates. This is the best way to enter your recurring holidays.

When creating your holidays, you cannot set reduced hours. The entire day is exempt from your schedule. Use these days as catch-up days, as they will likely be lower volume anyway.

Questions to ask yourself:

1. Do you support your end users 24/7/365?
2. Do you have any teams that are only available during specific hours or days?
3. Do you have any holidays with reduced hours?
4. How many different schedules should you create?

Business schedules are not available on Team plans. Learn more about how to create and manage schedules here.

SLA policies

Many companies have commitments to their customers that determine the length of time expected for certain events.

Zendesk Service Level Agreements allow you to prioritize your tickets by adding service targets to them. The available targets include:

• First Reply Time (The time between ticket creation and the first public comment by an agent.)
• Requester Wait Time (The total time that a ticket spends in New, Open, and On-Hold statuses.)
• Agent Work Time (The total time that a ticket spends in New and Open statuses.)
• Next Reply Time (The time between an end user comment and the next public comment by an agent.)
• Periodic Update (The time between a public comment by an agent and the next public comment by an agent.)
• Pausable Update (The time between each public comment from agents when the tickets are in the New, Open, and On-hold statuses. It is paused whenever the ticket is put into Pending status.)

Potential pitfalls:

Zendesk SLAs require that you use the system priority field. If a ticket is not assigned a priority, then your SLA policies will not apply to it.

If your SLAs are based on business hours and you have multiple schedules, then you will need to ensure that each ticket has the proper schedule applied. If not otherwise specified, each ticket will use the default business schedule.

The First Reply Time target will be instantly satisfied when an agent creates a ticket (even if they set the requester to an end user). This is because the ticket description will count as the first public comment by an agent. Because this target will be instantly satisfied, it will appear that this ticket has been handled.

The Next Reply Time target will not work for internal tickets. The target measures the time between an end user comment and the next public comment by an agent, so this target will ignore any tickets requested by agents.

Avoid using every target in one policy. Decide between Requester Work Time, Agent Work Time, or neither. Using both of these targets in the same policy is unnecessary and will overcomplicate things.

SLA breaches are not available as qualifying events for use in triggers. This means that there is no way to build an immediate notification of breach trigger.

Best practices:

There are six different targets that are available to you. You don’t need to (and shouldn’t) use them all in one policy.

The First Reply Time targets are a great way to ensure that every new ticket is addressed within a reasonable amount of time. The Next Reply Time targets are just as important for the same reason. Generally, we recommend building the NRT targets to closely resemble or completely mirror the FRT targets within the same policy.

Pick one or none between Agent Work Time and Requester Wait Time, as they are both measuring the time it takes to solve a ticket. AWT is measuring this from the perspective of the agent, so it pauses when tickets are on hold and/or pending. RWT is measuring this from the perspective of the requester, so it only pauses when a ticket is pending.

Pick one or none between Periodic Update and Pausable Update, as they are both measuring the time between public comments made by agents.

Questions to ask yourself:

1. Are you contractually obligated to meet specific service goals?
2. Do you have internal service target goals?
3. Do you need multiple policies or one blanket policy?
4. How do you prioritize your tickets?
5. Do you have a service goal for the time it takes to solve a ticket?
   If so, should it be measured from the perspective of the requester or from the perspective of an agent?
6. Do you support all of your customers 24/7/365?

Would you like to check your targets against calendar hours or your business schedule?

SLA policies are not available on Team plans. Learn more about how to create and manage SLAs here.

Part 3: Macros and views

Macros

Macros are agent-activated scripts that can perform multiple actions on a ticket at once. It’s important to know that a macro can only do what an agent can do and that the ticket changes will only be saved after the agent updates the ticket.

Using macros can increase your agents’ productivity by reducing their number of clicks.

Macros can:

• Add comment text
• Update ticket fields (drop-down and checkbox only)
• Add or remove ticket tags
• Add CCs
• Change the assignee
• Set the ticket subject (title)
• Add attachments to ticket comments

Potential pitfalls:

Macros are essentially shortcuts for agents. The macro can only do what the current user can do. For example, if an agent does not have permission to edit ticket tags, the macro will not add or remove tags when that agent runs the macro.

Macros do not update text, multi-line text, date, numeric, or regular expression ticket fields.

Best practices:

Just like with drop-down fields, you can nest macros. Nesting macros is a great way to organize them and keep them clean.

You can run multiple macros in one ticket update. This means that you don’t have to build a macro for every possible situation. Keep it simple.

Use placeholders! Starting your comments with {{requester.first_name}} will make even your most generic responses seem personalized. You can also use placeholders when you set the subject of the ticket.

You can assign macros to all agents or to specific groups. If a macro should only be seen by a few of your agents, make sure to restrict the macro to those agents to reduce clutter.

You can search for macros. Start typing the macro title when you are in the macro menu inside of a ticket, and it will filter your macros in the menu.

To make macros easily searchable, create a naming convention and stick to it.

Use macros to update multiple tickets at once. You can do this from your views screen by checking the boxes next to multiple tickets and hitting the black Edit tickets button in the top right corner. Once there, apply a macro and submit.

You can use triggers and automations in tandem with macros. For example, you could have a macro that adds a tag that immediately activates a trigger. Think of all the possibilities!

Questions to ask yourself:

1. What are the most common issues that your end users submit tickets for?
2. What should your comment text say?
3. Should your macro leave a public or private comment?
4. Which agents should have access to which macros?

Macros are available on all plans. Learn more about how to create and manage macros here.

 

Views

I’m saving the best piece for last. Views are quite possibly the most important piece of your workflow. Views determine which tickets are readily visible by your agents and the order in which they should be worked.

Views are NOT folders. They are saved searches or filtered databases. Think of them like smart playlists in iTunes.

Potential pitfalls:

Do not create overcomplicated views. The more conditions that your view has, the more filtered your results will be. This can be a good thing, but it can also be disastrous. If you have too many conditions, you might find yourself losing tickets.

If you have too many views, your agents might not prioritize your tickets the way you’d like. Avoid this by paring down your views to only what is necessary.

If you leave your browser open to a view, it will not automatically update. It will refresh every time that you click the view (or refresh the page).

Views can only show up to 30 tickets per page. If your views are not sorted correctly, you might miss important tickets.

Best practices:

Like macros, views can be assigned to all agents or specific groups. In many cases, creating custom views for each of your groups makes sense. This will ensure that each agent is only seeing relevant information.

If you are using SLAs, it makes sense to sort your views by Next SLA Breach. This will ensure that all tickets will eventually filter to the top.

Use the play button! The play button sits on the top right corner of your views page and throws you right into the next available ticket in your view.

Questions to ask yourself:

1. How should your tickets be prioritized?
2. Which tickets should each group see?
3. How do you classify your tickets?

Learn more about how to create and manage views here.