6 Replies Latest reply on Feb 11, 2014 3:28 PM by usbc

    Best match problem

    siplus

      Hello everybody.

       

      I'm building a ticketing system for our support.

       

       

      After a ticket is created, single problems are added to its ProblemList variable by clicking on entries from a 100+ problem portal. For the sake of simplicity, let's say that:

       

       

      ticket 1 has problems a, e, f

      ticket 2 has problems a, b

      ticket 3 has problems c, d, f

       

       

      and so on.

       

      (Let's also simplify by limiting the possible problems to a max of 10 and sorting the contents of the ProblemList field on modify, through a custom function).

       

      now comes ticket n, with problems b, c, d, g

       

       

      The wish

      -----------

      is to have a portal showing solved tickets, sorted in decreasing order by "best problem set match".

       

      In my example we would have ticket 3 in first position, with a correlation factor of 2, followed by ticket 2 with CF = 1. Ticket 1 does not appear, obviously.

       

       

      One idea

      ------------

      Would be to build 10 relationships R1 to R10 and set CF = PatternCount(list (R1::ticketID) & ... & list(R10::ticketID); ticketID)

       

       

      The question

      -----------------

      is: how would you implement "The Wish" most efficiently ?

        • 1. Re: Best match problem
          erolst

          siplus wrote:

          One idea

          ------------

          Would be to build 10 relationships R1 to R10 and set CF = PatternCount(list (R1::ticketID) & ... & list(R10::ticketID); ticketID)

           

          You're making this overly complicated …

           

          If you flag your problems EDIT: tickets as solved, you can add as a relationship predicate and remove the portal filter on matchcount EDIT: for the Ticket_self relationship.

          • 2. Re: Best match problem
            siplus

            Well actually the situation is a bit more complicated. What you mark as solved is the ticket, not the problems. The problems are a client's perceived list of concerns which might - or not - meet the real situation.

             

            Example: a lot of data is on a shared volume. Client says "I can't print scanned documents", "I can't import images". The solution is : mount the shared partition, which has somehow been dismounted. Ticket solved.

            • 3. Re: Best match problem
              erolst

              Note the edits on my original post; I meant "tickets solved" since I was referring to the Ticket_self relationship and the portal filter which then would be unnecessary.

              • 4. Re: Best match problem
                siplus

                If you want, it's something like an expert system: patient says

                 

                - got headache

                - lack of appetite

                - can't concentrate

                 

                and you come up with the most probable diagnostics, ordered by probability of being the right diagnosis, based upon past ones.

                • 5. Re: Best match problem
                  erolst

                  While this is truly fascinating – and this forum could use such a system – what you wanted was an efficient method to see a list of solved tickets, sorted by their count of 'problems' matching the problems of the current ticket.

                   

                  Got any other (perceived) problems? Shall we open a new ticket?

                  • 6. Re: Best match problem
                    usbc

                    Parsing it down, you will have created a table (library) of solved symptoms. Each would have a ID , an agreed name, and field containing "keywords". And of course the actual solution. As opposed to solved tickets.

                     

                    Much like one would have a table of components for a mechanical assembly or tasks for a flat rate repair system.