A step-by-step example of how to configure the "Autosearch" functionality for End Users (includes some reporting advice)

Version 16

    Environment: Self Service with Service Desk 7.4 +


    What and why?


    In Service Desk 7.4 some new functionality was introduced which allows you to introduce an automatic knowledge search process action for your End Users.  The whole concept has been introduced so that it creates a way to bring knowledge articles to the attention of those End Users who may not ordinarily take the time to search through your knowledge base themselves.


    By presenting End Users with a screen of relevant knowledge results before they are able to raise a support incident, then you are more likely to be able to deflect (answer/fix) the question or problem.  In this way, the value of your knowledge content increases because your content is helping to resolve issues before they reach your support Analysts.  This should in turn minimise the requirement for your Analysts to talk End Users through so many repeat questions and therefore freeing them up to deal with the more complex issues or more proactive work (such as submitting more knowledge articles when they resolve problems).


    At the end of this article I have included a link to some Crystal reports that I have written.  By reporting on the information captured by implementing this process you are then able to see what percentage of customer contact is managed by existing knowledge and track the success of your Self Service site in reducing the number of incidents raised.  You are able to also see which of your knowledge articles or which analyst(s)' articles are the most well used and most successful at resolving issues before they reach the support team.


    How it works

    When the process has been implemented how this will look is:

    • When an End User clicks New Incident (or other process object) they are presented with a very cut-down incident window which is designed just to start a knowledge search.  This could just have the Title field on it and some text to say "Type in a description of your issue" perhaps.


    • Instead of seeing a button to Save their changes the only option that the End User has is to click Search which uses the text that they have entered to search through the knowledge articles that are published for End User viewing.


    • An article record is always raised but depending how the End User progresses the incident from here your process can automatically progress in ways which you have predefined. 
    • The End User are then asked whether they found the articles they were presented with useful or not.
      • If the End User selects that the articles were useful, the Search Status value on the incident is recorded as 2, the End User is brought back to their previous screen in Self Service, and you can design your Autosearch incident process to move the incident straight to the Resolved status.
      • If the End User selects that the articles were not useful, the Search Status value on the incident is recorded as 1, your End User is told the incident number that has been raised for them, and you can design your Autosearch incident process to reinitialise straight into your usual Incident process (or to reinitialise to a particular process based on a category that you asked the End User to select).
      • If the End User doesn't reply whether it was useful or not and instead abandons logging the incident the Search Status value will be left at 0.  In this instance you can have a bulk action scheduled which will pickup these incidents and either assign them to someone to follow up or close them (perhaps with a closure category of "Autosearch Abandoned" so you can report on these later on).


    Step-by-step example

    Here is a step-by-step example of how you could implement this on your incident object to achieve the results shown above:

    • In Object Designer, modify your Incident Management - Incident object to ensure that it has the behaviour of "Automatic Search".  This makes a Complete Search action available for the object in Process Designer, and creates the Search Matches collection and Search Status attribute on the Incident object.


    • Still within Object Designer, change your Title attribute to be set to "Is Autosearch?" = True.



    • Design a new window for your End Users to use when they first log an incident which will just search the knowledge base.  Make this window available in Web Access.


    • Publish this to your End Users using rules so that they see this window upon creating an Incident but see the usual End User window when updating an incident.


    • In Process Designer, create a new incident condition:
      • Where Search Status = 2

    autosearch new2.PNG

    • Create a new Incident Process which has a process design like below:

    autosearch new.PNG

    • Set the value or runtime value on the Reinitialise automatic action:


    • In Self Service, remove your existing new incident link for End Users and add in a process link to your newly designed Autosearch process.


    • Create a new query which looks for Incidents with a Search Status = 0 and which are older than a day.  Then add a new Scheduled Bulk Action so these are Resolved with a Resolution category of  "Autosearch Abandoned".



    Reporting on the outcome of searches

    In order for Managers to track how many deflections (incidents which never reach your team as the End User finds their answers in knowledge) your knowledge is creating against the incidents which still come through to Support, you may want to create a query similar to the one below.  I have created this as a grouped query in console and then published as a dashboard with a bar chart in Web Desk:




    Crystal Reports

    I have added two simple Crystal reports to this article: Example Crystal Reports to support the Autosearch functionality I have created these based on the Autosearch data that you would collect if you implemented the process outlined above.  The reports will work against Service Desk 7.4 and 7.5.