Feature-Requests for "OTRS goes ITIL"
Hi all, I was very appreciated to read on the otrs.org-Website that "OTRS goes ITIL", meaning that OTRS aspires to reach an ITIL-certificate - whatever this means...? 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) Another weak point is the consideration/integration of SLA on ticket-work. Perhaps my posting helps efforts of the otrs-developers by initiating a discussion of this topic. Bye, Alex
Hello Alexander, I totally agree with you. Beside the SLA need I can also add the need for a powerful Reporting/Statistic (both historical and real time) module. I am not sure if the guys at OTRS are planing a new otrs version where to include all this things. Regards, Daniel Wednesday, March 8, 2006, 8:53:35 AM, you wrote: Alexander> Hi all, Alexander> I was very appreciated to read on the otrs.org-Website that "OTRS goes Alexander> ITIL", meaning that OTRS aspires to reach an ITIL-certificate - whatever Alexander> this means...? Alexander> I think that the current OTRS-implementation lacks the distinction of Alexander> incoming requests. Is it a Alexander> * incident Alexander> * service-request, especially Alexander> - change request Alexander> - request for information or education Alexander> (* problem) Alexander> (We currently bypass this missing feature by using priorities like Alexander> 1 - request for info, 2 - rfc/low, 3 - rfc/high, Alexander> 4 - incident/low, 5 - incident/normal. 6 - incident/high) Alexander> Another weak point is the consideration/integration of SLA on ticket-work. Alexander> Perhaps my posting helps efforts of the otrs-developers by initiating a Alexander> discussion of this topic. Alexander> Bye, Alex Alexander> _______________________________________________ Alexander> OTRS mailing list: otrs - Webpage: http://otrs.org/ Alexander> Archive: http://lists.otrs.org/pipermail/otrs Alexander> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Alexander> Support oder Consulting f?r Ihr OTRS System? =>> http://www.otrs.de/ -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://www.bitdefender.com/
Er Why? Simply putting graphs on a web page says very little unless one includes further information on what the graph actually is intended to say! The simple breakdown currently standard is an adequate snapshot of what is going on, but a more complex analysis from the OTRS data alone is probably inappropriate. SLAs tend to be as much organisational political objectives as numeric performance measures, and displaying numbers or pictures without an analysis of how those numbers and pictures reflect success (or failure) to meet a SLA in all of its aspects is not in itself very useful. Factors outside the information stored within OTRS may may also be an influence on the events that create that data, and OTRS statistical data may therefore be an incomplete view of the situation. (Information on factors affecting performance may also be within OTRS but not in form that can be used). I would think it much more appropriate to set up SQL queries to extract and import the relevant numbers and breakdowns for the organisations circumstances and place the data in your favourite spreadsheet or statistics application for more complex analysis and integration into management reports. Tools to assist such a process would probably be of more use than incorporating a statisical analysis module into OTRS (e.g. template javascript or perl scripts to create spreadsheets from SQL queries). Would otherwise be a bad case of "Re-inventing the wheel" methinks. BALAN, Daniel said: <Stuff deleted>
Reporting/Statistic (both historical and real time) module. <Stuff deleted>
whatever Alexander> this means...?
Alexander> I think that the current OTRS-implementation lacks the distinction of Alexander> incoming requests. Is it a Alexander> * incident Alexander> * service-request, especially Alexander> - change request Alexander> - request for information or education Alexander> (* problem)
Alexander> (We currently bypass this missing feature by using priorities like Alexander> 1 - request for info, 2 - rfc/low, 3 - rfc/high, Alexander> 4 - incident/low, 5 - incident/normal. 6 - incident/high)
Alexander> Another weak point is the consideration/integration of SLA on ticket-work.
Alexander> Perhaps my posting helps efforts of the otrs-developers by initiating a Alexander> discussion of this topic.
Alexander> Bye, Alex Alexander> _______________________________________________ Alexander> OTRS mailing list: otrs - Webpage: http://otrs.org/ Alexander> Archive: http://lists.otrs.org/pipermail/otrs Alexander> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Alexander> Support oder Consulting f?r Ihr OTRS System? =>> http://www.otrs.de/ _______________________________________________ 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/
Regards, Daniel
Wednesday, March 8, 2006, 8:53:35 AM, you wrote:
Alexander> Hi all,
Alexander> I was very appreciated to read on the otrs.org-Website that "OTRS goes Alexander> ITIL", meaning that OTRS aspires to reach an ITIL-certificate
I want to give my input to the OTRS developers. We have a 10000 customer base, 200 distinct locations (buildings), 150 system users (technical staff), a front office (5 members), interact with 5 different companies that use our OTRS installation. A little background about our users: 90% don't know English or the distinction between a hard drive space and memory space. They don't understand what a 1 Mega Email is, or that their quota on the server is only of 30M. We've been in a centralization, merging process, but still have around 90 different domains, etc... 90% of our tickets arrive by phone. We receive around 3000 calls per month, with a average of 1000 new tickets per month. We're in the public sector, so there are lots of work that needs to have written approvals from directors, etc. What I "added" to otrs and what I can't add: Queues: based on major subjects, corporate applications, Maintenance, PC/Printers support, Phones. Inside each of there are several subqueues, and sub sub queues. We've worked primarily on the key/value pairs, adding the following drop down options: - Generic classification:Incident, Problem, Provisioning, change, etc - Solved by: Front Office, Front Office + BackOffice, Backoffice, Reporting, External Companny - Received by: Phone, Fax, Email, paper, Intranet, Cad Portal, and so on - Specific Calssification: Application Autodesk, App SAP, Active Directory Password, AD Permissions, Ad Profiles, AD Shares, AD Printers - Number of objects (meaning the number of actions solved in one ticket, for example one ticket that asks you to create 5 new emails will have a 5 in this field. What can I get with this: 1) I can find out the ticket close rate of each involved team (specially my team: the front office). 2) I can script checks to see if a ticket that is open for 3 days is a incident, a problem, etc, and act on it. 3) The roles tab has come handy now, and its easy to add a new user, or remove it from a specific queue. Users have access to several queues, ranging from one or to, to 30 or more. What I can't get: 1) Workflow... all the workflow is done in the heads of our system users. You need to create a ticket with some user info, send it to the team that creates email addresses; after that is done, we send it to the AD team to create the respective user; after that, we (or other team) configure the outlook remotely (or locally in some places we don't have access). All this rules are in our heads and sometimes we fail. 2) Distinguish front office creating a ticket, and front office working on a ticket. Its still difficult to find out. Because when I create a phone ticket, my user "works" on the ticket. I needed another user level... I think (for example, I can't use escalation, because our frontend team needs to have access RW to every queue, but some tickets can't be solved by us, and if a ticket escalates and we can't solve it, just messes up with everyone). 3) the customer front end is too complex (believe me) to be used by our customers. 4) I need a way to pin point a ticket to a specific system user (like a welcome page, instead of "my queues", where a user sees "messages" like: take a better look to this ticket) 5) Also, there is need to another type of workflows: escalation workflows... for some critical processes. Contact person A, if it fails, Contact B, etc... after 15 min if problem is not solved, Warn Director X, after 60minuts, warn Director Y... a timed workflow Sorry if some of these needs are already solved in otrs, but I didn't found out how. Don't get me wrong. OTRS is a good tool, and we use it for the last 3 years. We're planning to change to a NNM solution but I think OTRS is in the correct path. Talking about customer users, I don't know where the developers are aiming to, but if they intend to have a large audience, think that we can't tell users that they need to choose a email, a queue, or something different than helpdesk@yourcompanny.com to get their request going. Hope it helps guiding the otrs future. Duarte Cordeiro
Hello Duarte, A nice overview of your system, from where we also can inspire in order to improve ours. I have to tell you that I also use drop down menus for free field texts and also I really need a work flow system ( What I can't get: 5). I think there is a solution for your: ( What I can't get: 4): For any queue you can set: Escalation time (minutes): If any of the tickets will exceed the time limit (no reply from the technicians) the technicians will be forced to see and work only on that ticket(s). Take a closer look in there and see if it is what you are looking for. Enjoy, Daniel Wednesday, March 8, 2006, 6:40:44 PM, you wrote: Duarte> I want to give my input to the OTRS developers. Duarte> We have a 10000 customer base, 200 distinct locations Duarte> (buildings), 150 system users (technical staff), a front Duarte> office (5 members), interact with 5 different companies that use our OTRS installation. Duarte> A little background about our users: 90% don't know English Duarte> or the distinction between a hard drive space and memory Duarte> space. They don't understand what a 1 Mega Email is, or that Duarte> their quota on the server is only of 30M. Duarte> We've been in a centralization, merging process, but still Duarte> have around 90 different domains, etc... Duarte> 90% of our tickets arrive by phone. Duarte> We receive around 3000 calls per month, with a average of 1000 new tickets per month. Duarte> We're in the public sector, so there are lots of work that Duarte> needs to have written approvals from directors, etc. Duarte> What I "added" to otrs and what I can't add: Duarte> Queues: based on major subjects, corporate applications, Duarte> Maintenance, PC/Printers support, Phones. Inside each of there Duarte> are several subqueues, and sub sub queues. Duarte> We've worked primarily on the key/value pairs, adding the following drop down options: Duarte> - Generic classification:Incident, Problem, Provisioning, change, etc Duarte> - Solved by: Front Office, Front Office + BackOffice, Duarte> Backoffice, Reporting, External Companny Duarte> - Received by: Phone, Fax, Email, paper, Intranet, Cad Portal, and so on Duarte> - Specific Calssification: Application Autodesk, App SAP, Duarte> Active Directory Password, AD Permissions, Ad Profiles, AD Shares, AD Printers Duarte> - Number of objects (meaning the number of actions solved Duarte> in one ticket, for example one ticket that asks you to create Duarte> 5 new emails will have a 5 in this field. Duarte> What can I get with this: Duarte> 1) I can find out the ticket close rate of each involved Duarte> team (specially my team: the front office). Duarte> 2) I can script checks to see if a ticket that is open for 3 Duarte> days is a incident, a problem, etc, and act on it. Duarte> 3) The roles tab has come handy now, and its easy to add a Duarte> new user, or remove it from a specific queue. Users have Duarte> access to several queues, ranging from one or to, to 30 or more. Duarte> Duarte> What I can't get: Duarte> 1) Workflow... all the workflow is done in the heads of our Duarte> system users. You need to create a ticket with some user info, Duarte> send it to the team that creates email addresses; after that Duarte> is done, we send it to the AD team to create the respective Duarte> user; after that, we (or other team) configure the outlook Duarte> remotely (or locally in some places we don't have access). Duarte> All this rules are in our heads and sometimes we fail. Duarte> 2) Distinguish front office creating a ticket, and front Duarte> office working on a ticket. Its still difficult to find out. Duarte> Because when I create a phone ticket, my user "works" on the Duarte> ticket. I needed another user level... I think (for example, I Duarte> can't use escalation, because our frontend team needs to have Duarte> access RW to every queue, but some tickets can't be solved by Duarte> us, and if a ticket escalates and we can't solve it, just messes up with everyone). Duarte> 3) the customer front end is too complex (believe me) to be used by our customers. Duarte> 4) I need a way to pin point a ticket to a specific system Duarte> user (like a welcome page, instead of "my queues", where a Duarte> user sees "messages" like: take a better look to this ticket) Duarte> 5) Also, there is need to another type of workflows: Duarte> escalation workflows... for some critical processes. Contact Duarte> person A, if it fails, Contact B, etc... after 15 min if Duarte> problem is not solved, Warn Director X, after 60minuts, warn Director Y... a timed workflow Duarte> Sorry if some of these needs are already solved in otrs, but I didn't found out how. Duarte> Don't get me wrong. OTRS is a good tool, and we use it for the last 3 years. Duarte> We're planning to change to a NNM solution but I think OTRS Duarte> is in the correct path. Talking about customer users, I don't Duarte> know where the developers are aiming to, but if they intend to Duarte> have a large audience, think that we can't tell users that Duarte> they need to choose a email, a queue, or something different Duarte> than helpdesk@yourcompanny.com to get their request going. Duarte> Hope it helps guiding the otrs future. Duarte> Duarte Cordeiro Duarte> _______________________________________________ Duarte> OTRS mailing list: otrs - Webpage: http://otrs.org/ Duarte> Archive: http://lists.otrs.org/pipermail/otrs Duarte> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Duarte> Support oder Consulting für Ihr OTRS System? Duarte> http://www.otrs.de/ -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://www.bitdefender.com/
Thanks for your help, but if I escalate a ticket, everyone that can work on that ticket will see it escalate. I just want to say to tec A or B.. "take a look to that thing over there", not necessary forcing him to work on it. Thanks, Duarte ________________________________________ From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of BALAN, Daniel Sent: quinta-feira, 9 de Março de 2006 7:19 To: User questions and discussions about OTRS.org Subject: Re[2]: [otrs] Feature-Requests for 'OTRS goes ITIL' Hello Duarte, A nice overview of your system, from where we also can inspire in order to improve ours. I have to tell you that I also use drop down menus for free field texts and also I really need a work flow system ( What I can't get: 5). I think there is a solution for your: ( What I can't get: 4): For any queue you can set: Escalation time (minutes): If any of the tickets will exceed the time limit (no reply from the technicians) the technicians will be forced to see and work only on that ticket(s). Take a closer look in there and see if it is what you are looking for. Enjoy, Daniel Wednesday, March 8, 2006, 6:40:44 PM, you wrote: Duarte> I want to give my input to the OTRS developers. Duarte> We have a 10000 customer base, 200 distinct locations Duarte> (buildings), 150 system users (technical staff), a front Duarte> office (5 members), interact with 5 different companies that use our OTRS installation. Duarte> A little background about our users: 90% don't know English Duarte> or the distinction between a hard drive space and memory Duarte> space. They don't understand what a 1 Mega Email is, or that Duarte> their quota on the server is only of 30M. Duarte> We've been in a centralization, merging process, but still Duarte> have around 90 different domains, etc... Duarte> 90% of our tickets arrive by phone. Duarte> We receive around 3000 calls per month, with a average of 1000 new tickets per month. Duarte> We're in the public sector, so there are lots of work that Duarte> needs to have written approvals from directors, etc. Duarte> What I "added" to otrs and what I can't add: Duarte> Queues: based on major subjects, corporate applications, Duarte> Maintenance, PC/Printers support, Phones. Inside each of there Duarte> are several subqueues, and sub sub queues. Duarte> We've worked primarily on the key/value pairs, adding the following drop down options: Duarte> - Generic classification:Incident, Problem, Provisioning, change, etc Duarte> - Solved by: Front Office, Front Office + BackOffice, Duarte> Backoffice, Reporting, External Companny Duarte> - Received by: Phone, Fax, Email, paper, Intranet, Cad Portal, and so on Duarte> - Specific Calssification: Application Autodesk, App SAP, Duarte> Active Directory Password, AD Permissions, Ad Profiles, AD Shares, AD Printers Duarte> - Number of objects (meaning the number of actions solved Duarte> in one ticket, for example one ticket that asks you to create Duarte> 5 new emails will have a 5 in this field. Duarte> What can I get with this: Duarte> 1) I can find out the ticket close rate of each involved Duarte> team (specially my team: the front office). Duarte> 2) I can script checks to see if a ticket that is open for 3 Duarte> days is a incident, a problem, etc, and act on it. Duarte> 3) The roles tab has come handy now, and its easy to add a Duarte> new user, or remove it from a specific queue. Users have Duarte> access to several queues, ranging from one or to, to 30 or more. Duarte> Duarte> What I can't get: Duarte> 1) Workflow... all the workflow is done in the heads of our Duarte> system users. You need to create a ticket with some user info, Duarte> send it to the team that creates email addresses; after that Duarte> is done, we send it to the AD team to create the respective Duarte> user; after that, we (or other team) configure the outlook Duarte> remotely (or locally in some places we don't have access). Duarte> All this rules are in our heads and sometimes we fail. Duarte> 2) Distinguish front office creating a ticket, and front Duarte> office working on a ticket. Its still difficult to find out. Duarte> Because when I create a phone ticket, my user "works" on the Duarte> ticket. I needed another user level... I think (for example, I Duarte> can't use escalation, because our frontend team needs to have Duarte> access RW to every queue, but some tickets can't be solved by Duarte> us, and if a ticket escalates and we can't solve it, just messes up with everyone). Duarte> 3) the customer front end is too complex (believe me) to be used by our customers. Duarte> 4) I need a way to pin point a ticket to a specific system Duarte> user (like a welcome page, instead of "my queues", where a Duarte> user sees "messages" like: take a better look to this ticket) Duarte> 5) Also, there is need to another type of workflows: Duarte> escalation workflows... for some critical processes. Contact Duarte> person A, if it fails, Contact B, etc... after 15 min if Duarte> problem is not solved, Warn Director X, after 60minuts, warn Director Y... a timed workflow Duarte> Sorry if some of these needs are already solved in otrs, but I didn't found out how. Duarte> Don't get me wrong. OTRS is a good tool, and we use it for the last 3 years. Duarte> We're planning to change to a NNM solution but I think OTRS Duarte> is in the correct path. Talking about customer users, I don't Duarte> know where the developers are aiming to, but if they intend to Duarte> have a large audience, think that we can't tell users that Duarte> they need to choose a email, a queue, or something different Duarte> than helpdesk@yourcompanny.com to get their request going. Duarte> Hope it helps guiding the otrs future. Duarte> Duarte Cordeiro Duarte> _______________________________________________ Duarte> OTRS mailing list: otrs - Webpage: http://otrs.org/ Duarte> Archive: http://lists.otrs.org/pipermail/otrs Duarte> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Duarte> Support oder Consulting für Ihr OTRS System? Duarte> http://www.otrs.de/
Hi Duarte Cordeiro
We have a 10000 customer base, 200 distinct locations (buildings), 150 system users (technical staff), a front office (5 members), interact with 5 different companies that use our OTRS installation.
thank you for posting your experience with your really big otrs-installation - very interesting.
2) Distinguish front office creating a ticket, and front office working on a ticket. Its still difficult to find out. Because when I create a phone ticket, my user "works" on the ticket. I needed another user level... I think (for example, I can't use escalation, because our frontend team needs to have access RW to every queue, but some tickets can't be solved by us, and if a ticket escalates and we can't solve it, just messes up with everyone).
I don't know if I got you right on this point: you can't use escalation because other non-escalated tickets would be hidden? That's the default setup, but you can use Ticket::Frontend::NoEscalationGroup to disable the escalation-view for a group of agents.
3) the customer front end is too complex (believe me) to be used by our customers.
I really believe you!
We're planning to change to a NNM solution but I think OTRS is in the correct path. Talking about customer users, I don't know where the developers are aiming to, but if they intend to have a large audience, think that we can't tell users that they need to choose a email, a queue, or something different than helpdesk@yourcompanny.com to get their request going.
What are the reasons for changing. The missing features you mentioned? Bye, Alex
-----Original Message----- From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Alexander Scholler Sent: quinta-feira, 9 de Março de 2006 8:00 To: User questions and discussions about OTRS.org Subject: Re: [otrs] Feature-Requests for 'OTRS goes ITIL'
Hi Duarte Cordeiro
We have a 10000 customer base, 200 distinct locations (buildings), 150 system users (technical staff), a front office (5 members), interact with 5 different companies that use our OTRS installation.
thank you for posting your experience with your really big otrs-installation - very interesting.
2) Distinguish front office creating a ticket, and front office working on a ticket. Its still difficult to find out. Because when I create a phone ticket, my user "works" on the ticket. I needed another user level... I think (for example, I can't use escalation, because our frontend team needs to have access RW to every queue, but some tickets can't be solved by us, and if a ticket escalates and we can't solve it, just messes up with everyone).
I don't know if I got you right on this point: you can't use escalation because other non-escalated tickets would be hidden? That's the default setup, but you can use Ticket::Frontend::NoEscalationGroup to disable the escalation-view for a group of agents.
Thanks, I'll take a look at that.
3) the customer front end is too complex (believe me) to be used by our customers.
I really believe you!
We're planning to change to a NNM solution but I think OTRS is in the correct path. Talking about customer users, I don't know where the developers are aiming to, but if they intend to have a large audience, think that we can't tell users that they need to choose a email, a queue, or something different than helpdesk@yourcompanny.com to get their request going.
What are the reasons for changing. The missing features you mentioned?
Well, I think its not fare for OTRS no compare it with very expensive software, mainly because they're on different mature levels. For example, NNM has voice integration with Cisco IP Telephony (IPCC) which will allows us to get some info automatically to the application (customer called at time X, customer data, etc); Also, integration with enventory software like Microsoft SMS, will allow us to see on the fly the software and hardware the customer uses, change software from within NNM, etc. Meaning, that NNM is not only a trouble ticketing system, but a system that integrates with a multitude of platforms that work together to allow us to have a better view of our network and customers. I believe that OTRS is in the right track. And allowed me to understand what a ticketing system must have, to get me on the right track and look for specific needs when analysing broader products. Duarte Cordeiro
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/
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. You could add priorities to the mix, but I'd start by using separate queues. Since everyone will have a different setup there isn't any default queue setup that differentiates between queues, but just a single queue. Just remember that OTRS is used by more people than just people that run a business that is like the one you run. Nils Breunese.
Would tend agree with Nils view. Using addresses for specific classes of incoming message to automatically place those messages in class related queue is a very flexible approach and there is more than one way to implement this for otrs. The simplest would to create virtual addresses for the otrs account and configure otrs to associate queues with addresses. More complex checks can be implemented using procmail (e.g. Subject or body text pattern matching). Of course people will send to an inappropriate address that will have to be corrected by the agent, but this approach reduces the need of agent to set priorities for incoming requests and allow for the proper use of priorities to handle call escalation. Nils Breunese (Lemonbit Internet) said:
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. You could add priorities to the mix, but I'd start by using separate queues. Since everyone will have a different setup there isn't any default queue setup that differentiates between queues, but just a single queue. Just remember that OTRS is used by more people than just people that run a business that is like the one you run.
Nils Breunese. _______________________________________________ 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/
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
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.
Hello Nils, Let's take your scenario and say we have the following queues: A, B and C corresponding to three levels of response time 8h, 12h and 24h. How can I as manager: - measure the SLA; - enforce the operators to first work on the messages in queue A but also make sure there are some tickets in the queue B that are reaching their response time; - set notifications/alarms in case one of the tickets is not answered in the right time. I am not sure if all of the OTRS users need these, but I think they are a must for any small/medium tech service dept. Regards, Daniel Wednesday, March 8, 2006, 12:53:31 PM, you wrote: Nils> 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)
Nils> I don't think OTRS is lacking anything in this respect. Just create Nils> different mail adresses for your different types of requests (who Nils> says everyone has the same types you would use?) and put the incoming Nils> tickets in different queues depending on to which mail address they Nils> were sent. You could add priorities to the mix, but I'd start by Nils> using separate queues. Since everyone will have a different setup Nils> there isn't any default queue setup that differentiates between Nils> queues, but just a single queue. Just remember that OTRS is used by Nils> more people than just people that run a business that is like the one Nils> you run. Nils> Nils Breunese. Nils> _______________________________________________ Nils> OTRS mailing list: otrs - Webpage: http://otrs.org/ Nils> Archive: http://lists.otrs.org/pipermail/otrs Nils> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Nils> Support oder Consulting für Ihr OTRS System? =>> http://www.otrs.de/ -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://www.bitdefender.com/
BALAN, Daniel wrote:
Let's take your scenario and say we have the following queues: A, B and C corresponding to three levels of response time 8h, 12h and 24h.
I don't think I would create queues based on levels of response time. But then I again I don't use OTRS to differentiate between different levels of response time at all, so maybe someone else can better share their experience with you.
How can I as manager:
- measure the SLA; I don't know how you measure your SLA, but it might be that you need some custom code for that, yes. I don't use any myself, but there's talk on this list about SLAs from time to time. Someone might have a solution for you. - enforce the operators to first work on the messages in queue A but also make sure there are some tickets in the queue B that are reaching their response time;
This is a pretty vague description of what you want. I wouldn't know what to work on if I had to work on queue A tickets first but also had to make sure some tickets in queue B reach their response time.
- set notifications/alarms in case one of the tickets is not answered in the right time.
It's in the manual: http://doc.otrs.org/2.0/en/html/x1375.html Nils Breunese.
participants (5)
-
Alexander Scholler -
BALAN, Daniel -
Duarte Cordeiro -
grahamsmith＠gandalfsemporium.co.uk -
Nils Breunese (Lemonbit Internet)