3 Replies Latest reply on Apr 13, 2017 7:30 AM by kjette

    Reporting Email & Web Interface Tickets

    nickmorrisonrrp

      We are trying to find out how many tickets are being created via web interface.

       

      We are moving away from specific Request Types and using generic types for efficiency. This will cause reporting to be less specific.

       

      Any ideas?

       

      Thanks in advance.

        • Re: Reporting Email & Web Interface Tickets
          kellytice

          I was trying to see if there was an obvious field in the database but i haven't found one.  :\

           

           

          So, i don't have a good answer on how to find this out for historical tickets, but with little bit of work you could set something up to track current/future ones (even if you only leave this in place temporarily).

           

          In a nutshell, you could create 2 different Action Rules that check the tickets when they are created and automatically does one of the following things:

          • Writes a Note into the ticket (that only Techs can see) with some text like "ThisIsAPortalTicket" or "ThisIsAnEmailTicket" according to the type of ticket it actually is
          • Sets a custom field (that only Techs can see) a particular way

           

          In that type of setup my first Action Rule would look like this:

          • First tab (Action Rule Info)
            • Give it a name
            • Set Rule Triggering to "only when updated by a Client" and "only at Ticket Creation"

          ActionRule1-EmailTickets-Page1.png

           

          • Second tab (Criteria)
            • Set "Last Update Trigger" to "E-Mail From a Client"

          ActionRule1-EmailTickets-Page2.png

           

          • Third tab (Actions)
            • Click "Modify Ticket" and click "edit" to enter a dialog where i could add a Note to the ticket automatically. 
              I'd want to make the text i use for the note unique (so it is easily searchable) and I'd want to uncheck the "Visible to Client" box.

          ActionRule1-EmailTickets-Page3.png

          Alternatively, on this Actions tab I could choose to do something other than adding a Note, like choosing a particular value in a Custom Field.

           

          Since the steps above only cover the email tickets, I would repeat the steps above to add a 2nd Action Rule.  

          The main differences there is that the second tab would have a rule for Latest Update Trigger = Client Interface

          and the third tab's Action would be putting in a slightly different (but still easily identifiable) bit of Text into a Note or setting a slightly different option on the Custom field.

           

          This is what it would look like:

          ActionRule1-EmailTickets-Page4(results).png

           

          As you might surmise, having 'extra' notes or custom fields in my tickets might be somewhat annoying if you had to have it long term, but it would be pretty to leave something like this in place for a short amount of time.  It would make it easy to search on all tickets in that time range that have a Note with "ThisIsAnEmailTicket" or "ThisIsAPortalTicket" to get a count.

          1 of 1 people found this helpful
          • Re: Reporting Email & Web Interface Tickets
            gdoch

            Our method:

            Anything submitted to us via email is categorised as request type: "Email report" at ticket generation, then it's retegorised accordingly by helpdesk staff.

            .

            So running a ticket search on "History + Contains: "Email Report" gives the tickets submitted in that fashion,

             

            Everthing else was submitted by other methods (helpdesk analyst, self service portal, automated task etc)

            1 of 1 people found this helpful
            • Re: Reporting Email & Web Interface Tickets
              kjette

              I asked SW support this exact question back in January and was told no, its not possible however they have added a Feature Request for it.  I ended up adding a custom field called Ticket Source and populated it with Self Service, Phone, Email, Walkup, IM etc.  Its now a required part of ticket processing.

               

               

              2 of 2 people found this helpful