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/