Kaseya Community

How do i react to customer replies?

This question is answered

Hi,

I'm having problems with configuring the Service desk module. I'd like to have some kind of action and notification when a ticket gets new email from the customer. My fairly similar scenarios are the following:

1. A customer replies to an open ticket. What should i do to have that ticket stand out on my list of tickets? I'd rather not get a Kaseya-internal message about it when a flag, a filter or a view on "actionable" tickets will do. Is there a way to use the "On Ticket Change" procedure on email replies? Just me adding a note or changing an attribute should not be wrongly identified as a customer reply kind of "On Change" event.

2. After the issue has been solved, i move the ticket to a "Work complete" stage, inform the customer and set a flag to "Awaiting feedback". How can i catch a response from the customer so i know whether they've approved or disapproved the solution, before the ticket is automagically escalated to the "Solution approved" stage?

There are two problems i've ran into and i guess it's just because of my lack of understanding. I think there should be Stage-specific "On Ticket Change" procedures so that i don't have to do giant if-trees in the global On-Change routine. And if i'm not entirely wrong, a "On Ticket Change" procedure will be fired if a ticket is moved from one stage to another, either manually or by a procedure. If so, is there a way to move the ticket to a stage and not to have the On Change fire? Or should i create a new custom variable saying that the next time the ticket enters the On Change procedure, it should just skip processing it? Sounds like a kluge to me :)

Help!

 ~rL  

Verified Answer
  • You (and the documentation) are correct.  The Ticket Change procedure will complete as <current stage> and then re-run IF NECESSARY as <new stage>.

    To get around your problem in question 1 we have certain scenarios including something like IF <EditingUser> IS NOT EQUAL TO <Assignee> THEN which will only fire the resulting step if the changes were made by the customer, or by an admin not assigned to that ticket.

    Concerning your second question we use another IF in the Ticket Change procedure to test if a new note was added (Again, by NOT Assignee) and then assign the status back to Open and/or change the stage back to "LastRealStage"

    I'm not sure whether I agree that different stages should have separate change procedures.  It would be nice to have smaller procedures and not a tangle of IFs, but I've been able to accomplish everything I needed to so far.  You just need to know what properties and variables are available to you and get creative with your IF/THEN/ELSE statements.

All Replies
  • Hold that mess of a thought. I just might have a clue.

    Having consulted the Kaseya Service desk reference manual, i revise my previous belief. I now believe that if a ticket's Stage is changed, either manually or procedurally (and that includes any procedure induced escallations), the On Change procedure will be fired for the "source" stage but not for the new or "target" stage. According to the docs, if a stage is changed, the On Change procedure is interrupted ,the on Exit procedure of the old stage is run, then the On Entry procedure of the new stage, and finally the original On Change procedure is resumed.

    What is not entirely clear is whether a procedure induced escallation that moves a ticket to a new stage will fire the On Change procedure.

  • You (and the documentation) are correct.  The Ticket Change procedure will complete as <current stage> and then re-run IF NECESSARY as <new stage>.

    To get around your problem in question 1 we have certain scenarios including something like IF <EditingUser> IS NOT EQUAL TO <Assignee> THEN which will only fire the resulting step if the changes were made by the customer, or by an admin not assigned to that ticket.

    Concerning your second question we use another IF in the Ticket Change procedure to test if a new note was added (Again, by NOT Assignee) and then assign the status back to Open and/or change the stage back to "LastRealStage"

    I'm not sure whether I agree that different stages should have separate change procedures.  It would be nice to have smaller procedures and not a tangle of IFs, but I've been able to accomplish everything I needed to so far.  You just need to know what properties and variables are available to you and get creative with your IF/THEN/ELSE statements.

  • Hi chammond,

    I'll check with the first IF-sentence you mentioned. That should do the trick. But i'm having problems with the second one; last time i tried with if [ticket property] AllPublicNotes HasChanged, i got an error message. Maybe it was just bad karma.

    Thanks for the idea!

    ~rL

  • Ah yes, and with regards to the On Ticket Change procedures, i would like to have one global On Change procedure which always fires (but can be overridden not to) and one per-stage On Change proc.

    From the top of my head, i'd suggest that the per-stage On Change procedure would fire first so that it could be set not to fire the global procedure.

  • @Robin - Try this: IF <ChangesAsHtml> EXISTS "A public note was added" THEN

    We had kaseya pro services setup our first Service Desk (back when they were charging for it...) and thats how the gal did it.



    [edited by: chammond at 9:44 AM (GMT -8) on 1-19-2011] t