Alexander Scholler wrote-
Alexander Scholler wrote:
I think that the current OTRS-implementation lacks the distinction of incoming requests. Is it a * incident * service-request, especially - change request - request for information or education (* problem)
(We currently bypass this missing feature by using priorities like 1 - request for info, 2 - rfc/low, 3 - rfc/high, 4 - incident/low, 5 - incident/normal. 6 - incident/high) I don't think OTRS is lacking anything in this respect. Just create different mail adresses for your different types of requests (who says everyone has the same types you would use?) and put the incoming tickets in different queues depending on to which mail address they were sent.
This means that the customer has to decide whether he has a change request or incident. I think a "normal customer" definitely can't do that - often it's difficult for agents to classify an incoming ticket.
Then just use one incoming queue (and mail address) and let agents move tickets into the correct 'internal' queues.
You could add priorities to the mix, but I'd start by using separate queues.
My opinion is that queues should be used to categorize the tickets e.g. Server, Client, Printing so that these queues can be used * to analyze where requests appear * to let experts work on their queue(s) * to define ACLs on queues (if a big OTRS-installation is in place)
In my setup I have queues for Sales, Support, etc. which lets the right people work on the right tickets and sends out notifications to only the right people etcetera.
Continuing your argumentation results e.g. in the following queues: * server - rfc - incindet * client - rfc - incident
No, I would create an RFC and an incdident queue, not a toplevel Server and Client queue. But hey, it's all up to you. OTRS is pretty flexible. Nils.