Re: [otrs] Prevent Escalation if ticket is locked
The idea is that for certain clients that are managed by an specific agent, we don’t want other agents to touch those (since they are complicated set-ups or new clients that aren’t tickets that are easy to answer for anybody other than the managing agents). We’re looking for a quick flag where we can identify the ticket as ‘don’t touch, i’ve got this’ - they are opposed to the ‘locking’ ticket solution as (1) that involves opening a ticket and reviewing it (which is too much to expect when somebody is already behind) and (2) it doesn’t prevent escalation anyway. Is there such a flag, or such a solution? - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Prevent Escalation if ticket is locked
If a ticket HAS an escalation SLA, it should be impossible to circumvent the escalation without a update to the ticket saying why and who authorized the exception. One simple way to work with that: create a script that can be run to update the ticket via email. That should reset the counter and document who's responsible for the SLA exception. > On Mar 28, 2014, at 7:26 PM, "Leah Kelly" wrote: > > We have a set up to where a ticket that has gone 60 minutes or over without a > response is escalated. > Once an action item is made, the time is supposed to reset, but it seems to > be keeping the tickets in > escalated view regardless. > > I am looking for a different way to say ‘I am working on this ticket’ - one > that actually keeps it out > of escalation and one that preferably doesn’t involve opening the ticket > first. > > - > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Prevent Escalation if ticket is locked
We have a set up to where a ticket that has gone 60 minutes or over without a response is escalated. Once an action item is made, the time is supposed to reset, but it seems to be keeping the tickets in escalated view regardless. I am looking for a different way to say ‘I am working on this ticket’ - one that actually keeps it out of escalation and one that preferably doesn’t involve opening the ticket first. - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Prevent Escalation if ticket is locked
> We have a set up to where a ticket that has gone 60 minutes or over without a response is escalated. In human terms, what does "escalated" mean to you? And "without a response" means ... first response or any response? > Once an action item is made, the time is supposed to reset, but it seems to be keeping the tickets in escalated view regardless. No, you have to do the action that pertains to the milestone. If it's a first response escalation, an outbound response must be recorded in the ticket. If it's an update, that means another outbound response. If it's a solution, that's closing the ticket. If you don't want to obey those milestones, a practical (?) way to do do that is to use generic agent every 10 minutes to check for ticket change before 1 hour [ago] and state new, then to change the STATE of the ticket. (create them of type OPEN: but "hey, this is > 1 hour old", >one that preferably doesn't involve opening the ticket first. Which is "locking the ticket" without responding to the ticket. Unless you mean open = clicking ticketzoom to read the ticket, which, effectively, why bother with your plan? There's no need to assign a ticket or lock a ticket if you're not going to work on it... But, yeah, use Generic Agent to assign an owner if you must... On Fri, Mar 28, 2014 at 1:25 PM, Leah Kelly wrote: > We have a set up to where a ticket that has gone 60 minutes or over > without a response is escalated. > Once an action item is made, the time is supposed to reset, but it seems > to be keeping the tickets in > escalated view regardless. > > I am looking for a different way to say 'I am working on this ticket' - > one that actually keeps it out > of escalation and one that preferably doesn't involve opening the ticket > first. > > - > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs > - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Prevent Escalation if ticket is locked
> certain clients that are managed by an specific agent, we don't want other agents to touch those (since they are complicated set-ups or new clients that aren't tickets that are easy to answer for anybody other than the managing agents) Also, among other things is to create a queue for the *agent[s]* who are handling these specific clients. Make sure that the agent[s] are a member of a newly created group(s) related to the agent queue(s). Reworded: New Queue: AgentXQ or TeamXQ. Queue has a Group: grp_x If you've enabled CustomerGroupSupport, customers that are allowed to see tickets for AgentXQ or TeamXQ should be members of grp_x (also, the appropriate agents should be members of grp_x). On Fri, Mar 28, 2014 at 10:36 AM, Mathias Braeunling < mathias.otrsmailingli...@gmail.com> wrote: > Hi, > > I think you are mixing up two things here: > - Saying "I'm working on this ticket" is actually done by locking it. > > - Escalations: First it would be interesting which escalations you have > defined. For example a first response escalation is 'cured' by simply > sending out a (manual) email to the customer. > > Mathias > > Am 28.03.14 15:32, schrieb Leah Kelly: > > The idea is that for certain clients that are managed by an specific > agent, we don't want other agents to touch > > those (since they are complicated set-ups or new clients that aren't > tickets that are easy to answer for anybody > > other than the managing agents). We're looking for a quick flag where we > can identify the ticket as 'don't touch, > > i've got this' - they are opposed to the 'locking' ticket solution as > (1) that involves opening a ticket and reviewing it > > (which is too much to expect when somebody is already behind) and (2) it > doesn't prevent escalation anyway. > > Is there such a flag, or such a solution? > > - > > OTRS mailing list: otrs - Webpage: http://otrs.org/ > > Archive: http://lists.otrs.org/pipermail/otrs > > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs > > - > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs > - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Prevent Escalation if ticket is locked
Hi, I think you are mixing up two things here: - Saying "I'm working on this ticket" is actually done by locking it. - Escalations: First it would be interesting which escalations you have defined. For example a first response escalation is 'cured' by simply sending out a (manual) email to the customer. Mathias Am 28.03.14 15:32, schrieb Leah Kelly: > The idea is that for certain clients that are managed by an specific agent, > we don’t want other agents to touch > those (since they are complicated set-ups or new clients that aren’t tickets > that are easy to answer for anybody > other than the managing agents). We’re looking for a quick flag where we can > identify the ticket as ‘don’t touch, > i’ve got this’ - they are opposed to the ‘locking’ ticket solution as (1) > that involves opening a ticket and reviewing it > (which is too much to expect when somebody is already behind) and (2) it > doesn’t prevent escalation anyway. > Is there such a flag, or such a solution? > - > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Prevent Escalation if ticket is locked
Thanks, Gerald - can you think of another way we might accomplish our goal? For example, we could make a certain type of action item and set it up so if this was in the ticket, it would prevent escalation. Any ideas? - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Prevent Escalation if ticket is locked
No. Whether the ticket is locked or not, escalation milestones still apply. Just because the ticket is locked doesn't mean that first response has been addressed until /unless the agent locks the ticket in conjunction with a reply to the customer. Neither does a lock comply with performing an update or solution. On Mar 27, 2014 9:59 PM, "Leah Kelly" wrote: > Hello, > > We just started using escalation rules to help us stay on top of client > emails. If one queue starts to get > behind, other agents can jump in and help. However, if an agent locks a > ticket, we don't want it to appear > in the list of escalated tickets. So my question - if a ticket is locked, > can I prevent it from being escalated? > > > - > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs > - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Process Management - Unconditionally jump when a transition link is pressed
What is with the 2 other transitions, have you tried to disable them maybe double succeed ? You are going to create new tickets after process change, my experience is that any process change does not evaluate existing tickets ? Just to be sure you have synchronized the process change Von: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] Im Auftrag von Gergely Polonkai Gesendet: Freitag, 28. März 2014 09:18 An: User questions and discussions about OTRS. Betreff: Re: [otrs] Process Management - Unconditionally jump when a transition link is pressed Hello, The ticket view shows that Process is Incident from 2nd line, and Activity is Validity of incident (the naming may be a bit misleading). Under Process information I can see 3 links for the possible transitions, one of them is named Invalid, which have the condition DynamicField_processtest String Invalid. That path contains only one transition action, Set queue, which has the Config parameter Queue NOC::1st Line. The processtest dynamic field has the value Invalid. I think we should call this a simple process. History doesnt show anything changed, it looks like if I never pressed the Invalid link in the Process Information box. Best, Gergely On 28 March 2014 08:25, Ohliger, Christoph wrote: Gergely, have you checked the history of that ticket, if there is anything changed within the process ? If you have the condition already set (normally you should set it within activity dialog) the ticket should be moved to the transition. If that didnt work there is something wrong within activity. Keep your process as simple as possible, I have some bad experience with regex and complex conditions, especially when using more AND/OR conditions in transition it didnt work ! regards Christoph Von: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] Im Auftrag von Gergely Polonkai Gesendet: Freitag, 28. März 2014 08:14 An: otrs@otrs.org Betreff: [otrs] Process Management - Unconditionally jump when a transition link is pressed Hello, We are currently trying to implement processes using the new (for us, at least) Process Management feature. We have created the first steps, now we want to do some transitions. The links in the ticket view show up as ekpected, but whenever I click it, nothing seem to happen. As transitions need a condition, we have added a Dynamic Field to the ticket with a static value (which is set correctly), and in the condition we check if DynamicField_processtest is set to that value (String testvalue). The next activity would putwthe ticket into a new queue, but that never happens. Could someone tell where we go wrong? Thanks in advance! Best, Gergely - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs smime.p7s Description: S/MIME cryptographic signature - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Process Management - Unconditionally jump when a transition link is pressed
Hello, The ticket view shows that Process is "Incident from 2nd line", and Activity is "Validity of incident" (the naming may be a bit misleading). Under "Process information" I can see 3 links for the possible transitions, one of them is named "Invalid", which have the condition "DynamicField_processtest - String - Invalid". That path contains only one transition action, "Set queue", which has the Config parameter "Queue - NOC::1st Line". The "processtest" dynamic field has the value "Invalid". I think we should call this a simple process. History doesn't show anything changed, it looks like if I never pressed the "Invalid" link in the Process Information box. Best, Gergely On 28 March 2014 08:25, Ohliger, Christoph < christoph.ohli...@fh-rosenheim.de> wrote: > Gergely, > > > > have you checked the history of that ticket, if there is anything changed > within the process ? If you have the condition already set (normally you > should set it within activity dialog) the ticket should be moved to the > transition. If that didn't work there is something wrong within activity. > Keep your process as simple as possible, I have some bad experience with > regex and complex conditions, especially when using more AND/OR conditions > in transition it didn't work ! > > > > regards > > Christoph > > > > *Von:* otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] *Im Auftrag > von *Gergely Polonkai > *Gesendet:* Freitag, 28. März 2014 08:14 > *An:* otrs@otrs.org > *Betreff:* [otrs] Process Management - Unconditionally jump when a > transition link is pressed > > > > Hello, > > We are currently trying to implement processes using the new (for us, at > least) Process Management feature. We have created the first steps, now we > want to do some transitions. The links in the ticket view show up as > ekpected, but whenever I click it, nothing seem to happen. > > As transitions need a condition, we have added a Dynamic Field to the > ticket with a static value (which is set correctly), and in the condition > we check if DynamicField_processtest is set to that value (String > testvalue). The next activity would putwthe ticket into a new queue, but > that never happens. Could someone tell where we go wrong? > > Thanks in advance! > > Best, > Gergely > > - > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs > - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Re: [otrs] Process Management - Unconditionally jump when a transition link is pressed
Gergely, have you checked the history of that ticket, if there is anything changed within the process ? If you have the condition already set (normally you should set it within activity dialog) the ticket should be moved to the transition. If that didn't work there is something wrong within activity. Keep your process as simple as possible, I have some bad experience with regex and complex conditions, especially when using more AND/OR conditions in transition it didn't work ! regards Christoph Von: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] Im Auftrag von Gergely Polonkai Gesendet: Freitag, 28. März 2014 08:14 An: otrs@otrs.org Betreff: [otrs] Process Management - Unconditionally jump when a transition link is pressed Hello, We are currently trying to implement processes using the new (for us, at least) Process Management feature. We have created the first steps, now we want to do some transitions. The links in the ticket view show up as ekpected, but whenever I click it, nothing seem to happen. As transitions need a condition, we have added a Dynamic Field to the ticket with a static value (which is set correctly), and in the condition we check if DynamicField_processtest is set to that value (String testvalue). The next activity would putwthe ticket into a new queue, but that never happens. Could someone tell where we go wrong? Thanks in advance! Best, Gergely - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
[otrs] Process Management - Unconditionally jump when a transition link is pressed
Hello, We are currently trying to implement processes using the new (for us, at least) Process Management feature. We have created the first steps, now we want to do some transitions. The links in the ticket view show up as ekpected, but whenever I click it, nothing seem to happen. As transitions need a condition, we have added a Dynamic Field to the ticket with a static value (which is set correctly), and in the condition we check if DynamicField_processtest is set to that value (String testvalue). The next activity would putwthe ticket into a new queue, but that never happens. Could someone tell where we go wrong? Thanks in advance! Best, Gergely - OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
