We’re very excited to finally begin rolling out a new and improved version of both Agent Collision and Live Ticket Updates beginning November 24th. This will be done as part of a rolling release with a target to end on November 28th.

What’s changing with agent collision?
What are Live Ticket Updates?
Does this affect any other feature?
Anything new for App developers?
Want access to these features early?
I have questions!

What’s changing with Agent Collision?

While agents can see if someone else is viewing the same ticket they are, it is not clear what they are doing beyond just looking at the ticket.

Screen Shot 2014 11 11 at 6.01.58 PM

This can lead agents to abandon a ticket they could have otherwise begun working on because they assume the other person looking at the ticket must also be working on the ticket. Or, it leads to agents ignoring the viewing notification and proceeding with a ticket update – only to find that the other person really was working on the ticket, and also made an update.

These two problems lead agents to collide, despite the feature being intended to prevent that from happening, and becomes a lot more challenging as your support teams grow. That’s something we wanted to improve.

See who’s editing

You’ll be able to easily distinguish between who is simply looking at a ticket versus someone who has made the first steps to editing the ticket.

A blue border indicates that the agent has begun editing a ticket, which occurs when they begin typing a new comment or when a field’s value is changed.

See who’s not focused right now

OK, so we can’t tell you who is “focused” at the neurological level, but we can tell you whether or not someone who has the ticket open in their interface is actually looking at that ticket right now.

When an avatar is faded out in this way, it indicates that they have gone to another part of the Zendesk application. Search, another ticket, views, etc. The same will happen to anyone who is also an editor.

Note this does not monitor if you are focused on the browser tab or window.

Room for everyone else

If you’ve got a large team of agents all over an urgent ticket, last thing you want is row upon row of profile pictures. A total of 8 agents can be visible on a single row, going over that will cause an overflow.

We’ll keep all the editors we can in view, moving the folks that have been viewing for the longest amount of time to the overflow.

Plenty of other details

As well as the above highlights, here’s some things we didn’t cover:

  • Mouse over any profile image to get the agent’s full name and their current status
  • Click into the stack to see who’s there, and what they’re doing
  • Position in the stack is important. New viewers enter at the top of the stack, but editors are always anchored to top (they’re the most important after all)

But wait, there’s more!

What are Live Ticket Updates?

We let you know when there is a new update on a ticket whenever possible by way of a small notification in the top left of the agent interface.

Screen Shot 2014 11 11 at 6.03.43 PM

The agent can go ahead and click the button. This relies on them a) noticing it and b) deciding to actually click the button. If they don’t click the button, and decide to proceed anyway, they end up clobbering whatever may have been changed while they were working on it.

This is of particular risk around tickets because having the most current information is paramount to efficient and effective support.

Tickets will now live update

When a new comment is added, be it by another agent or an end-user via email, it will appear on your screen almost instantly. Ticket field, or perhaps even ticket form got changed? You’ll see that immediately. If anything happens to the ticket at all, you’ll now know about it.

We’ll highlight anything that got changed so you can keep track:

Screen Shot 2014 11 12 at 4.43.41 PM

The highlighting stacks, so if you go on a quick 15 minute break and a bunch of updates have come in, you’ll see those updates highlighted and be informed of who made them.

Will I lose a comment I’m typing?

Even though updates to a ticket will come in live, any comment you’re typing will be completely uninterrupted. You will not lose your comment.

What about ticket fields I’ve made changes to?

Here’s the magic. If you’ve made a change to a field and have not yet saved the ticket, if an update comes in changing that field then you will lose the change you made. If the update didn’t change your field, you won’t lose the change.

Let’s run through a few quick scenarios.

Simple fields

Fields such as drop down, checkboxes, text input – whether custom or system – are examples of simple fields.

Screen Shot 2014 11 13 at 10.07.37 AM

You’ve made a change to the “Type” field, changing it from “Incident” to “Question”. You have not yet saved your update, because you are in the middle of typing a comment.

An update comes in:

Screen Shot 2014 11 13 at 10.09.12 AM

Another agent has changed the same field you were making a change to, but that agent saved the update. You lose the change on that field, but your comment is still intact.

Now, let’s take the same scenario and change it just slightly.

Screen Shot 2014 11 13 at 10.07.37 AM

Again, you’ve made a change to the “Type” field, changing it from “Incident” to “Question”. You have not yet saved your update, because you are in the middle of typing a comment.

An update comes in:

Screen Shot 2014 11 13 at 10.13.05 AM

This time, another agent changed a different field to the one you changed. As a result, your change is kept and waits for you to save the ticket. Your comment is still intact.

Tag fields

Tag or “tagger” fields are a little more complicated. These are fields such as “Tags” and “CCs”.

Screen Shot 2014 11 13 at 10.16.27 AM

In this scenario, there is already a tag saved on the ticket, “a_tag”.

Screen Shot 2014 11 13 at 10.17.11 AM

Now you add “b_tag”, but you do not yet save this.

An update comes in:

Screen Shot 2014 11 13 at 10.27.04 AM

Now this is a little different from the “simple field” example. Even though the update contained changes to the same field as you had made changes to, it is a field that can take multiple objects within itself. As a result, we preserve your unsaved changes while also showing you the updated value.

This works in the same way for CCs, too.

In summary, you will always know the most current state of the ticket in real-time. You may lose some changes to ticket field values, but only if it’s because that value really did change. You will never lose a comment you are typing. You will always be 100% up to date when looking at tickets. We think that’s pretty cool.

Does this affect any other feature?

There is only one feature directly impacted by changes here: Play.

Play is a feature you’ll see appear on views. The idea behind Play is very simple: you click it and Zendesk will serve you tickets from the view in the order they present themselves in that View.

The part that’s changing here is a feature of play: We skip tickets other people are viewing so you only get served tickets that you can get going on right away without worrying about colliding with another agent.

Previous to these changes, Play would sometimes end up serving a ticket to an agent already looking at the ticket. This was due to the way in which collision used to work: If you moved away from a ticket tab (to go to Search, another ticket tab, etc) then you would be considered no longer viewing the ticket.

Now that we track you as viewing a ticket even if you are not focused on it, we’re able to instruct Play to skip those tickets which should completely remove the risk of Play serving you a ticket someone else is viewing.

Anything new for app developers?

When we began building this feature, we knew we wanted to include some framework updates for app developers to take advantage of. And you can take advantage of them right now!

There are two events to take a look at. ticket.updated will let you know when and who updated a ticket. ticket.viewers.changed will let you know when someone joins or leaves the ticket, or moves from a viewer or editor or into and out of idle states.

Don’t forget, you can share app ideas or get help from our app team and community of developers. If you want your test account given access to the new Collision and Live Updates features, fill this in and we’ll get you going.

What is a “rolling release”?

A rolling release means that, instead of turning on a feature for every Zendesk account, the feature will be turned on for a percentage of customers at a time. The speed of that rollout is controlled manually by us.

Want access to these features early?

Fill this in and we’ll get you going. We’ll be processing applications as quickly as we can as we approach the rollout. If you want to get in ahead of that rollout, sign up now!

I have questions!

We like questions! Please post in this announcement if you do have any questions at all. If you have specific concerns or would not like to post publicly, please email [email protected] and you will get through to me directly (but may experience a delay in response).