Using skills-based routing (Enterprise)

Have more questions? Submit a request

29 Comments

  • Wouter van Gessel

    I'm missing some explanation in the articles, what will happen if a ticket matches a Skill. The article doesn't say if the ticket is then assigned to an agent, a group of agents, or what business rules can be attached. 

    What if we create a business rule that all French tickets should go to our two French colleagues: How will this show up in their Zendesk views? What happens if both colleagues are on leave, can other agents still see tickets? I'm missing an example of a business rule in the explanation. Hope you can help! :)

    3
  • Matt Savage

    Piggybacking on Wouter's comment ^ as it seems we're going in a similar direction.  I also don't understand the specifics of where/how the routing occurs here and how it meshes with existing triggers/automations.  

    I'd also like to see (either manually or via machine learning) some way of estimating capacity in the routing, via some method similar to agile story points.  In the above scenario, if there are 2 French agents, it'd be incredibly helpful if the system could attempt to route a ticket to whichever one is a) available, b) has the most free capacity, and/or c) failover to some other location (i.e. a group) if neither agent can presently handle it.

    Can you provide more info on why skills aren't reevaluated on update like trigger conditions?  The scenario I foresee is: customer fills out a contact form, selecting the wrong product/value --> Skill A is set.  Agent w/ Skill A updates the ticket w/ correct product/value, which would then match Skill B instead (which they may not have).  What's the utility of keeping Skill A set when the ticket has now been identified as needing Skill B?  I understand this may be a limitation set for the early version of this feature to keep it simple but it seems like it'll be problematic in more complex routing scenarios, especially for internal transfers between teams (e.g. Support <--> Billing).

    2
  • Andrew Checkley

    Same as others above, I have tried playing with it in sandbox and although setup as described no routing occurs ?

    0
  • Kristen Mirenda

    Thank you so much for the feedback! We're working on augmenting this documentation with some additional info. In the meantime, hopefully this will help.

    This is the first iteration of this feature, and it doesn't yet cover all the use cases we plan to support over the coming months.

    For now, we retain the "pull" paradigm of agents taking tickets from views. To show agents which tickets match their skills, add a "Skill match" column to the view. If the agent looking at the view has all the skills required by a ticket, that ticket will have a checkmark next to it.

    The next release will offer a filtered experience that will work with Play mode. Therefore, for many customers, this version of Skills-based routing is best suited to the time-consuming task of setting up and testing new routing flows. We've published some best practices to guide you.

    In addition to seeing how tickets are matched to an agent, you can see which skills were applied to a specific ticket, and update them if needed. Only admins can do this right now. This will help you QA and troubleshoot your new routing rules.

    Routing rules run before triggers, and for now on ticket creation only. Manually updating skills on the ticket is the only way to change them. We do not currently re-run routing rules on ticket update to ensure ticket update performance isn't compromised, but that use case (essentially, "re-routing") is one of the things we're working on for a future release.

    Additionally, we're working on a "push" paradigm of routing tickets directly to agents, which would likely entail a way to ensure that they're going to agents who are available and not overloaded. 

    There's some more information about our plans for Routing in the launch announcement. This is just the first step in a long journey!

    1
  • Justin

    I have a use case that may not have been considered. 

    Can a ticket have multiple skills assigned to it?

    For example lets say that I have the "Mandarin" language skill, and the "Refund" skill. Both are different skill types but may be present on a ticket.

    0
  • Kristen Mirenda

    Hi @justin -- a ticket can absolutely have multiple skills assigned to it! That's what makes skills-based routing especially powerful. An agent will be considered a match for a ticket if they have all the skills that ticket requires. So in the example you gave, an agent that only has "Mandarin" and not "Refund" would not be considered a match (in the future we will be looking at partial match logic). 

    1
  • Aimee Spanier

    Hi, all. The article has been updated to (hopefully) clarify some key points, and better reflect the current functionality. Leave comments if you have any other questions or clarifications. Thanks!

    0
  • Andrew Checkley

    Looks good, but needs automatic intelligent routing. i.e. assigning to the appropriate person at point of raise. if multiple matches then assign to the agent with the least amount requests taking into account current state of assigned tickets and SLA 

    0
  • Will Ginsberg

    @kristen mirenda -- there needs to be an ability to show the skill match column as checked if the agent has ANY of the skills on the ticket (not ALL) of the skills. It's also really frustrating that if a given ticket doesn't have any skills applied that the ticket is shown as checked in the skill match column. 

    As of right now I don't see a clear way to:

    a) Assign a specific skill to an agent for a specific ticket topic

    b) Without assigning skills to all tickets (so that all tickets don't appear as checked, because ticket MUST have a skill in order to appear unchecked in "Skill match" otherwise they're shown as checked)

    Because of (b) I need to assign a skill to all tickets we receive that has no agents assigned, BUT because agents must have ALL skills assigned and I can't assign agents to the "mass skill" that I applied that means that the "Skill match" column never appears checked. 

    Just to simplify in case it helps...

    Let's assume you have two skills. Skill one applies to every ticket received (so that they don't all appear as skill matched because they lack a skill), skill two applies to tickets with specific criteria. Skill one has no agents assigned and skill two has one agent assigned. 

    Because of the fact that agents must have ALL of the skills and the agent assigned skill two but isn't assigned skill one, they never see skill match. 

    Super frustrating! If every ticket without a skill wasn't checked as skill matched you'd solve a lot of headache and this product would work. 

    0
  • Kristen Mirenda

    Hi @andrew and @will -- I could not agree more! Both direct routing (assigning) to agents and partial skill match are part of the vision for the future. We're building this out one layer at a time. We know this version isn't optimal for all use cases, but we wanted to release it as soon as we had an end-to-end solution, rather than hold back completely until the feature is "done" (there's no such thing anyway). This approach allows us to provide something useful and lets us gather real usage data to inform our next iteration.

    0
  • Will Ginsberg

    @kristen mirenda

     

    I 100% get that there are a myriad of use cases but I don't understand how this product works properly.

    If a ticket doesn't have a skill it appears as skill matched. This means that in order to even think about "disqualifying" tickets from skill matching you need to assign the ticket a skill. 

    So, seriously, this sounds snarky but it's not intended that way...how is this product supposed to work? What's a use case where this works as intended? Having a specific view for a skill? What's the point of skills then? I'm probably totally missing the mark but trying to figure out an example of where skill matching works. 

    0
  • Tom Morris

    If we're more and more going to use Views for agents to see what they need to be working on, rather than the home 'Tickets requiring your attention', it would be useful if we could replace 'Tickets requiring your attention' with a (custom) View, that is shown to the Agent in place of the default 'Tickets requiring your attention'.

    2
  • Paul Lawrence

    Is the new Routing feature an easier interface to design triggers or is it a replacement for triggers?

    In my zendesk account an agent can be in multiple content specific groups. I have triggers setup to route tickets to the correct content group by string searches so agents can solve tickets based curent priority of their content.

    It would be nice if routing gave a choice to assign to an agent or a group under skills.

    0
  • Kristen Mirenda

    It's all good @will -- this is part of the learning.

    We conceived of a "skill match" as answering the question, "does the agent have all the skills needed to take this ticket?" -- that's why a ticket with no skills will match everyone.

    If you want to disqualify tickets from skills matching, could you work with the conditions on the view where you put the column? Would you also mind talking a little about the use case for disqualifying tickets to help us understand what you’re trying to do?

    --

    @tom -- That's similar to the direction we're heading. We found that not a lot of customers made use of 'Tickets requiring your attention' however -- how are you using it?

    --

    @paul -- We envision this as a replacement for some (actually, a lot of) triggers. We also envision it as a replacement for some groups that exist solely to segregate the tickets a particular agent can work on. We are working towards direct agent assignment as part of automated routing, but you will always be able to use triggers in concert with routing rules if you so choose.

    1
  • Kristen Mirenda

    There's been such great feedback in the comments sections of a few different articles relating to the current release of Skills-Based Routing. 

    We'd love to have most of that happening in one place, and we think the release announcement makes the most sense.

    So if you'd like to provide input, please do it there! It'll be easier for us to respond, and you'll be able to see and engage with others' ideas as well. 

    Thank you -- we're so grateful for your feedback. It's one of the main reasons we're taking an iterative approach, which gives us the chance to take it into consideration while we're still designing and planning. Keep it coming! (Just, over there.) 

    0
  • Massimo DiDio

    if the ticket does not get automatically assigned to agents yet, how do agents know which skills we have set for them unless we specifically tell them? 

    0
  • Kristen Mirenda

    Just a note that @Massimo's question has been answered in the comments of the release announcement, where we're currently funneling the discussion.

    1
  • Amber Barnes

    When configuring skill conditions, we are missing ticket fields in the drop down options. Why is this? Are some excluded for a reason?

    0
  • Kristen Mirenda

    Hi @amber, it depends on which ticket field you're looking for. Not all of them were included -- generally we included ones that were available or relevant on ticket creation. Custom fields should be supported as well. If you're looking for a newish custom field you might try a hard refresh on the admin UI. 

    0
  • Sean Starwind

    It seems as though, at the moment, we can only set 1 view for skills match on the routing settings page?

    Are there any plans to allow this to be set on more than one view?

    1
  • Kristen Mirenda

    Hi @Sean! That's in the plan, but first we want to make sure it's solid with the one view limit under real-world usage. I can't give you timing yet, we're gathering performance data and the more folks use it the sooner we'll know!

    0
  • Alex Aguilar

    Can agent skills be updated/changed via api?

    1
  • Kristen Mirenda

    Hi @Alex! Not yet, but that's high priority in our backlog.

    0
  • Martijn Snels · pluscloud.nl

    Hi Kristen, this goes together with the options to admins to update the skills of a ticket via the API I assume? Surprised the feature is first released before the API, normally this is the other way around.

    0
  • Kristen Mirenda

    Hi @Martjun -- ideally, but we don't have a delivery plan yet as it's still just in the backlog.

    0
  • Brandon Kreines

    Hello! Are there any plans for us to be able to grant non-admin roles the ability to change what agents are assigned to which skills? We'd love to be able to have our agent supervisors change those at their discretion.

    0
  • Kristen Mirenda

    HI @Brandon -- it's on the backlog, but I can't give you a timeframe yet. But thank you for describing the use case, that's really helpful!

    0
  • Wes Shank

    @Kristen - I promise I have read through this before asking and it sort of looks like you were just asked this but I think the question was about changing the Agent skills. My question is, it looks like the document was updated that the agent could now change the skills on the ticket, where initially only an Admin could. Am I seeing that correctly? Our agents have to clean up so much for our clients it really makes it a deal-breaker for us if we can't clean up the skills.

    0
  • Kristen Mirenda

    Hi @Wes! Good spot -- I think perhaps you saw a premature update that was briefly/mistakenly live. So I might as well tell you what's coming!

    As mentioned in the announcement a few weeks ago, we're working on a setting to configure whether the skills box does or doesn't show up on the ticket form for admins. The use case here is when the admin has tried out SBR but decided not to roll it out. This will provide a way to make that box go away if you're not using it.

    In the course of implementing that, we realized that we could probably use this setting to cover view/update options for both admins and agents. So we went for it, even though it's solving a different problem. We will test it out in beta first.

    However, we've decided to hold back just for now on the update option for agents. Because we're also working on the ability to re-run routing rules on a ticket, and we want to think about automatic and manual updates together. 

    So when we do release this configurable setting in the coming month(ish), initially the options will be:

    1. Admins see an editable skills box, agents see a view-only version. 
    2. Admins see an editable skills box, agents see nothing.
    3. Nobody sees anything.

    We didn't want to pile too many use cases on this one enhancement. But soon we'll take the next step and test a solution to the additional need that you described.

    At this stage in our evolution, Zendesk workflow has reached a level of complexity where we want to be careful introducing changes, especially to agents. Doing it incrementally gives us room to test use cases separately and more easily unwind if we need to.

    TL;DR: we well are on our way to allowing agents to update skills on tickets, via incremental steps to allow us to get it right.

    0

Please sign in to leave a comment.

Powered by Zendesk