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: h...@msxi-euro.com -----Ursprüngliche Nachricht----- Von: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] Im Auftrag von otrs-requ...@otrs.org Gesendet: Donnerstag, 28. Mai 2015 14:00 An: otrs@otrs.org Betreff: otrs Digest, Vol 80, Issue 18 Send otrs mailing list submissions to otrs@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-requ...@otrs.org You can reach the person managing the list at otrs-ow...@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 <linux4b...@telenet.be> Subject: [otrs] Reports for accounting and setup best practices for multiple customers To: otrs@otrs.org Message-ID: <mk6sf9$p03$1...@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 ************************************ --------------------------------------------------------------------- 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
