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?
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
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.otrsmailinglists@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
participants (3)
-
Gerald Young -
Leah Kelly -
Mathias Braeunling