Hi Nils,
I can't agree with you.
Nils Breunese (Lemonbit Internet) schrieb:
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.
Consider also that a incident often results in a problem resulting in a
change request => this is another feature request for an ITIL-conform
OTRS. E.g. making a change-request-ticket out of an incident-ticket with
automatically linking these tickets.
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)
Continuing your argumentation results e.g. in the following queues:
* server
- rfc
- incindet
* client
- rfc
- incident
If I use these queues, I also can forget the implemented
priority-feature and use instead:
* server
- rfc
. high
. low
- incident
. high
. low
* client
[...]
This example shall prove that another ticket-property, beside
* Queue
* Priority
* Customer
etc. is useful - this ticket-property is "classification" with thinkable
values
* rfc
* incident
* request for information
Surely, I can use ticketkey/value for that, but this information is too
important to be "hidden" at this place, because
Ticket-classification is, in my opinion, the first work that has to be
done on a incoming ticket.
Bye, Alex
_______________________________________________
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
Support oder Consulting für Ihr OTRS System?
=> http://www.otrs.de/
