In this case I’d recommend to go with different queues for internal
requests. You might want the internal inquirers to get informed about
progression of their tasks and maybe even have them use the customer interface –
but maybe not for the external customers.
The ‘move back in just one queue’ is possible with a ticket ACL
in the config.pm.
If not a simple work instruction perhaps gets you further than a
system restriction. Depending on how many people work in 2nd level,
it could be done by just telling them not to send emails to external customers?!
Greets
Daniel
Von:
otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] Im Auftrag von Christian
Weiß
Gesendet: Freitag, 16. Januar 2009 10:05
An: 'User questions and discussions about OTRS.'
Betreff: Re: [otrs] how to handle internal tickets? 2nd level may not
communicate with end customers?
Hello,
Thank you very much for this tip!
Unfortunately, I think that’s not an option. We also have a workflow
wherein internal employees (which are not otrs agents) can send emails directly
to the 2nd level queue, so we need the “answers”-possibility.
I could add a queue “Websites::From Helpdesk” wherein I remove
the “answers”, but that seems a little bit weird for me too, because I need to
create another queue for every 2nd level main queue. And I also have
to restrict this queues in a way that they can only move the tickets back to
the 1st level queue and not to any other queue, where we again have
the “answers” problem.
Isn’t my scenario a common workflow? I really like OTRS in terms
of end user communication, but we are some experiencing problems in terms of
internal communications. (this scenario, internal tickets from agents, …)
Any other suggestions?
Thanks in advance,
Christian
Von:
otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] Im Auftrag von Obee,
Daniel
Gesendet: Freitag, 16. Jänner 2009 09:38
An: User questions and discussions about OTRS.
Betreff: Re: [otrs] how to handle internal tickets? 2nd level may not
communicate with end customers?
If you don’t want to have the agents answer out of a queue,
simply remove the empty answer off that queue. No answer – no mail. You could as
well fiddle around with ACLs and stuff, but I guess this would be the simplest
opion. Move them into 2nd level queues and back when solved.
I had a system running where we used the split option. This was practical
for a scenario where the customer never had to be informed about the outcome of
a 2nd level task. 1st level took care about the customer
– 2nd level solved the reported bug/error.
Greets
Daniel
Von:
otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] Im Auftrag von Christian
Weiß
Gesendet: Freitag, 16. Januar 2009 09:13
An: otrs@otrs.org
Betreff: [otrs] how to handle internal tickets? 2nd level may not
communicate with end customers?
Hello,
we are using OTRS for the
communication with our end
customers (Helpdesk = 1st Level
Support) as well as for our internal communications (“Accounting”, “Websites”, … = 2nd Level Support).
Consider the
following scenario:
-
An end customer sends a
request to our „Helpdesk“.
(Example: “I get an
error XYZ on the web page”)
-
The helpdesk agent cannot
answer this request and has to pass
this problem to the 2nd Level Queue “Websites”.
-
The “Websites” agent is not allowed to
communicate directly to the end customer! He may only answer back to the
“Helpdesk” agent.
-
So the “Websites” agent reports to the
helpdesk agent when the problem is marked as solved
-
The helpdesk agent sends an
info to the end customer
So this is my question:
How can I setup the OTRS
system in a way, that only 1st level support agents are allowed to
communicate with end customers. If
there’s a need for escalation
to 2nd level support, the agent from this queue must not communicate
directly with the end customer. He may only communicate with the 1st
level support agent.
I tried following
approaches:
1.) Move tickets
=========================
The helpdesk agent “moves” the ticket to the 2nd
level queue and attaches a note with additional infos. The 2nd level agent answers to the 1st
level by moving the ticket back to the 1st level queue and attaching
a note.
Positive:
all the communication is in
one ticket.
Negative:
if the 2nd level
agent (unintentionally) clicks on “Answer”,
he communicates with the end customer. But
this must not happen!
Also, you can’t clearly see
in the ticket, which notes were written by 1st level and which by 2nd level.
2.) Split tickets
=========================
The helpdesk agent “splits” the ticket and sets his own
personal email address as “sender”. he selects the 2nd
level queue as target queue and modifies the body. The 2nd level now
gets a new ticket and communicate only with the helpdesk agent.
Positive:
2nd level is not able to
communicate with end customers.
Negative:
The 1st level
agent sees the ticket as a child ticket in his 1st level ticket.
But he is not allowed to see
the details of the ticket, unless I
give the helpdesk complete read access to the 2nd level.
The 1st level
agent has to communicate with the 2nd level through his mail client
because he set his own email address as sender. So the helpdesk has to use two
different systems (otrs and personal mail account)
1st level agent
has to manually change the sender-address in the “split ticket view”. If he forgets this, the end customer is set as the
sender of the new ticket.
And some other annoying
problems.
I’m not happy with both
approaches. (neither is
my boss *g*) How
do you handle this scenario? Thanks for any hints and tricks!
With best regards,
Christian Weiss