June 2015 - otrs - OTRS mailing lists

Re: [otrs] Reporting for accounting and setup best practices
by Holger Erb 01 Jun '15

01 Jun '15

Hi Benedict, we have a global IT helpdesk structure, here an overview 1st line support: 1 queue per country for the local/national 1st line Helpdesk: DE (Germany), FR (France), IT (Italy), ES (Spain), etc.... 1 separate e-mail address per country/queue. We handle here all local/national support-requests. We differentiate the requests between Incident Requests (problems on existing infrastructure/application) and Service Requests (service request for changes, setups, new users, etc...) via the Ticket-TYPE. We assign the according SERVICE and SLA level to the different requests/tickets during the analyze phase of the ticket. All services are available for all queues/countries. SLAs are per country configured to reflect the right time zone and working hours. All those 1st line queues are configured with the according calendar to match the right time zone and working hours. 2nd line helpdesk and further support queues: This is our escalation queue if 1st line cannot help further and need support from a specialist in the different technical areas. Here we solve all infrastructure/application related escalations based. >From here we can escalate further to other support teams like Software Development etc. We have in all countries / in all queues / at any time of a ticket-life-cycle all TYPES/SERVICES/SLAs available to update if needed. MIT FREUNDLICHEN GRUESSEN / WITH KIND REGARDS HOLGER ERB ------------------------- From: Linux4Bene <linux4bene(a)telenet.be> Subject: Re: [otrs] Reporting for accounting and setup best practices for multiple customers To: otrs(a)otrs.org Message-ID: <mkh0ph$bej$1(a)ger.gmane.org> Content-Type: text/plain; charset=UTF-8 Hi Holger, thanks for the info. The setup you describe is very close to the setup I would want to implement here. For the moment, I only have the following queues: Junk, Misc, Postmaster and Department 1. To get to your setup, I would need to add services (I have most already), and add SLA's (don't have those yet). Do you use different queue's for each department/customer or do you use a queue per type of SLA? As for part 2 of my message regarding the reporting, I constructed 2 SQL statements to run on my Postgresql db. It might be helpful to others so I'll post it here: /* List tickets and sum of time spent on the ticket in date period sorted by title, and create_time */ select t.tn Ticketnumber, u.first_name as Firstname, u.last_name as Lastname, t.title Title, sum(ta.time_unit) Time_unit, q.name Queue, t.customer_user_id Customer_user, t.customer_id Customer, t.create_time Ticket_created, min(a.create_time) First_action, max(a.create_time) Last_action from ticket t left join time_accounting ta on ta.ticket_id=t.id left join queue q on t.queue_id = q.id left join article a on a.id=ta.article_id left join users u on u.id = a.create_by where ta.time_unit is not null and ta.create_time between '2015-05-01' and '2014-05-31' group by t.tn, t.title, u.first_name, u.last_name, queue, customer_user, customer, t.create_time order by t.title /* List total time per Agent in a give period*/ select u.first_name as Firstname, u.last_name as Lastname, sum(ta.time_unit) from time_accounting ta left join users u on u.id = ta.create_by where u.id = ta.create_by and ta.create_time between '2015-05-01' and '2015-05-31' group by u.id Regards, Benedict

1 0

Change ticket state to open if another ticket is merged to it
by Rick Heisterhagen 01 Jun '15

01 Jun '15

Hi, I am looking for a way to let the state automatically change to open of the ticket that you merge another ticket into. The reason is that often customers do not care about the ticket number in the subject and open a new ticket and when merged to the "main" ticket it disappears because the "main" ticket is still in pending or close state. Is there a way to achieve this? Thanks!

1 0

PendingDiffTime per queue
by Rick Heisterhagen 01 Jun '15

01 Jun '15

Hey there, Does anyone know how to set the global value PendingDiffTime queue based in OTRS 3.3? I had the idea to maybe add a new MenuModule in the TicketZoomView present that to specific groups and add the custom DiffTime behind "<Item Key="Link">" but I don't know what. Any help is appreciated. Thanks!

1 0

Will there be a Windows Installer for OTRS 3.3.14?
by Rick Heisterhagen 01 Jun '15

01 Jun '15

Hi, I would like to install the latest minor patch but there is still a Windows Installer missing. http://ftp.otrs.org/pub/otrs/ Anyone an idea when it's released? Thanks!

1 0

Re: [otrs] Reporting for accounting and setup best practices for multiple customers
by Holger Erb 01 Jun '15

01 Jun '15

Hi, you can setup SLA on two different ways: QUEUE-based and SLA-based If you setup it queue-based you will have only one SLA for this queue, which means all your request within this queue are based on the same accounting etc. If you use SLA-based setup then you can define different SLAs for different Services and you will have different accounting possibilities. We have done it SLA-based and we collect all request for a country/department in one queue but we have the possibility to assign 1 out of 5 SLA-levels for a specific request. In practical it means, here three examples: - we assign SLA Prio 5 (highest) for server-related issues (here we have a first response within 30 min, a follow up within 2 h and a total solution of 4 hours). - we assign SLA Prio 3 (middle) for PC or Workgroup printer requests (here we have a first response within 3 hours, a follow up within 5 h and a total solution of 1 working day). - we assign SLA Prio 1 (lowest) for setup of new equipment/accounts/VPN access etc (here we have a first response within 1 working day, follow up within 8 hours, total solution of 1 week). You can use services as well and you can link them with all of your SLAs or with just one SLA, per example it makes no sense to enable SLA Prio 1 for a SERVER-related servcie (as no server in production can wait for a total repair time of 1 week, so we have disabled SLA Prio 1 and 3 for server-related services, only 5 is possible). You can run reports based on those timers (SLA violations etc., KPIs like first response time, Mean-Time-To-Repair, etc....) You can calculate as well for invoicing: (number of tickets per SLA level * by needed Time-Units * costs per Time-Units) - different SLA-levels have different pricing etc. Different customers are as well possible and different customers can be linked to all or totally different services etc. Several ways are possible to implement all of this and a deeper analyze of your individual specifications and requirements is needed and important to get the right things at the end of the day. I would recommend to test it on a test-system first before you configure (misconfigure) your production system. Hope it helps a bit and good luck. With best regards, HOLGER ERB | IT TEAM LEADER CLIENT SERVICES & COMPLIANCE (GTS) | MSX INTERNATIONAL OFFICE: +4922194700141 | MOBILE: +491638471062 | MAILTO: HERB(a)MSXI-EURO.COM -----Ursprüngliche Nachricht----- Von: otrs-bounces(a)otrs.org [mailto:otrs-bounces@otrs.org] Im Auftrag von otrs-request(a)otrs.org Gesendet: Donnerstag, 28. Mai 2015 14:00 An: otrs(a)otrs.org Betreff: otrs Digest, Vol 80, Issue 18 Send otrs mailing list submissions to otrs(a)otrs.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.otrs.org/cgi-bin/listinfo/otrs or, via email, send a message with subject or body 'help' to otrs-request(a)otrs.org You can reach the person managing the list at otrs-owner(a)otrs.org When replying, please edit your Subject line so it is more specific than "Re: Contents of otrs digest..." Today's Topics: 1. Reports for accounting and setup best practices for multiple customers (Linux4Bene) ---------------------------------------------------------------------- Message: 1 Date: Thu, 28 May 2015 10:59:53 +0000 (UTC) From: Linux4Bene <linux4bene(a)telenet.be> Subject: [otrs] Reports for accounting and setup best practices for multiple customers To: otrs(a)otrs.org Message-ID: <mk6sf9$p03$1(a)ger.gmane.org> Content-Type: text/plain; charset=UTF-8 Hi, I use otrs for almost 1.5 years and I like it a lot. I recently upgrade my 3.3.12 installation to 4.0.8. We now only have 1 queue for 1 internal department. This will change as we will now support more departments. This means there will be a need to report on the time spent on tickets per department. It will be used for time accounting and invoicing. A have a couple of questions regarding this: - The way we would implement it, is by using 1 queue per department. It would allows us to put SLA on a queue and so on. Is this good practice? I could go further and couple a specific e-mail address for every department so everything is neatly split per department. - In order to use the input of the tickets as base for accounting, we need some reports. I have looked through the reports but I can't seem to find the correct report. For instance, following situation: we have worked 300 minutes in april for department x, and 100 minutes in may for the same department. Management would like a couple of reports: - The tickets (title), time spent per ticket, and total time per given period for a given department. For april it would report all tickets and total time (300 minutes in our example). If a ticket is open for several months, then only the time spent in the given period should be reported to allow correct invoicing. The next month only 100 minutes should be reported. The time reported shouldn't depend on wether a ticket is open or closed. - Total ticket time per department (queue?) for a given period - Total ticket time per department (queue?), and per operator who worked on the ticket for a given period Any info or help with the reports and organisation of the queues would be helpful. Thanks, Benedict ------------------------------ --------------------------------------------------------------------- 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 End of otrs Digest, Vol 80, Issue 18 ************************************

2 1