Using skills-based routing

Return to top

11 Comments

  • Chad Smith

    In the admin, how are skills reordered so they are more logically navigated by the agent while updating a ticket?

    0
  • Danijel Moric

    Hi all, trying to setup skill-based routing for my team.

    Following the guide I am almost there. The problem is when I add the rule "Skills is Current user's skill" to the testing view, I receive the error saying the view can't be saved. Any way I can figure out why is the error appearing? The preview is correct but I can't save the view.

    0
  • Ola Timpson

    @... - do you have the view selected in the Routing page as a skills match view? That would block certain conditions being added. If you're using the filter in the View conditions then you wouldn't need it to be selected as skills match view as well.

    1
  • Danijel Moric

    Ola Timpson - Thank you!! That worked!! I thought it was necessary to add a view in the routing page to connect/filter the tickets. 

    0
  • Paul Strauss

    Is there a way to create a routing rule to handle the following scenario?

    We have a group of agents who all possess a skill for servicing a specific brand, however, some of the agents are only serving as additional capacity during peak periods, and we'd only like them to be assigned a call, chat, or email in the event that all of the regular agents are busy or offline.

    Is this possible? If so, how would you go about setting that up?

     

    0
  • Terry Ehrhard

    We are seriously considering Skills Based Routing for one of our teams that support over 60+ vendors and have close to 100 associates to support those vendors, often 1 or 2 people per vendor.  Thus skills based approach seems like a strong option.

    Yet in evaluating this functionality there are several things prohibiting us moving forward

    1. We don't see a means to enable the normal "Standard Agent" to add or remove skills thus enabling them to move between various vendors to support peak ticket activity.  This appears to be an Admin-only setting which needs to be more flexible to enable the Agent to determine those changes, much in the way they can set any of their characteristics on their profile page.

    2. The lack of routing rules to evaluate form field data after ticket creation is a significant limitation.  This skills routing is an excellent concept but limiting to only ticket creation and only data prior to triggers firing is serious limitation to be addressed.

    3. Similarly to above, the skills should be reassessed upon any ticket change including automations or triggers dynamically.  Instead of manually modifying the skills on the ticket, the criteria at the skill level should be constantly re-evaluating tickets as they change and adding/removing the skill on the ticket as those attributes change. 

    4. Other groups NOT using skills still see the skills inside their form even when those skills don't apply.  There needs to be a way to set or configure which groups or forms are using skills and those that are not.

    5. More granularity is needed on the Views utilizing skills.  Rather than just "is" and "is not" black and white across ALL skills, specifying WHICH skills to evaluate is needed.  For instance we originally had plans to separate out two different skills; one for vendor and another for country/region.  That was until we determined that ANY skill being met would cause that ticket to appear.  Basically there is no way to create an "and" condition to see we want to show a view where ticket and user have skills "vendor" AND "country/region".   Basically ANY skill being met would show that ticket which isn't sufficient. 

    Would really appreciate feedback from the product team if any of these items are being addressed and when.

    1
  • Barry Neary
    Zendesk Product Manager

    @...: first of all, apologies for the late reply to your post

    1) This ability for someone other than admin to be given permission to edit an agent's skills is on the roadmap for 2022. I dont have an exact date but likely late Q1

    2) and 3) The ability to be able to automatically change skills post ticket creation is also key roadmap item for 2022

    4) To understand this more fully - you want to be able to specify that the skills are shown only in some forms and not others? Similarly you should be able to configure it so that the skills field appears in tickets that are assigned to certain groups and not others?

    5) My understanding is that currently the agent must have all skills associated with the ticket for them to be able to see it. So in your example, currently the agent would have to have both the vendor and country skill that matches the ticket's in order for them to see it in a view which is filtered by skills. It sounds like this is what you want?

    0
  • Barry Neary
    Zendesk Product Manager

    @...: sorry for late reply

    We are working on an omnichannel routing engine which will have a feature enabling overflow to occur as you describe. For now I am not sure there is any automated way for your skilled agents only to be used on non-skilled tickets in the case of other agents not being available.

    0
  • Terry Ehrhard

    Thanks for the reply @...

    Regarding point 4) Correct on both.  We have completely different groups working in completely different parts of the country.  One is North America (NA) and other is Germany (DE).  NA has skill types (think of an NA Skill with different vendors/partners/etc) they work with while DE has completely different skill type that contains their vendors/partner/etc.  NA doesn't want/need DE's skill type or skills shown.  Likewise DE doesn't want need NA's skill type or skills shown.  And lastly if a group is not using skills for their form/tickets, no skill types or skills should be shown at all. 

    Regarding Point 5) See samples below on what we have had to do to work around this.  We started with defining a Country skill type and Vendor Skill Type thinking that we could create an "And" condition, yet quickly learned that "ANY" skill being met caused the ticket to appear. As an example if a ticket was defined as AU, then ticket appeared in the view, OR if Google skill was met, then ticket appeared in the view. Thus there is no means to say All or which skill types must be met to cause ticket to appear.  Instead we had to create a skill type for each iteration of a vendor and country.  Fortunately these situations are limited right now but we could see if we used skills more often in other groups that using skills would be unmaintainable. 

    Fitbit - AU
    Fitbit - NL
    Google - AU
    Google - NL
    Google - US

    Appreciate the team focusing on this as we see great potential if functionality can be expanded.  We have a single view for one group that supports upwards of 70 vendors (ie skills) with each Associate/Agent given abilities to switch skills using a custom app we had to create to give the means to switch skills as needed.  Looking forward to the next update

    0
  • Riccardo Centomo

    There i some way to create a trigger notification skills-based routing?

    We have set the skills but the notification of new ticket still arrive to all agents of the group.. We would notify only the specific agents of the group that have the specific skills..

    0
  • Cheeny Aban
    Zendesk Customer Care
    Hi Riccardo, 

    Are you pertaining to email notification? If yes, you can create a trigger and use tags to segregate the tickets from each other or if you have a ticket field for Skills, you can also add it as a condition under meet all, then target the group recipient under actions. I hope that helps
     
    0

Please sign in to leave a comment.

Powered by Zendesk