Re: [otrs] Reporting for accounting and setup best practices for multiple customers
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@MSXI-EURO.COM
-----Ursprüngliche Nachricht-----
Von: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] Im Auftrag von otrs-request@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-request@otrs.org
You can reach the person managing the list at
otrs-owner@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
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
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@MSXI-EURO.COM
<snip>
participants (2)
-
Holger Erb -
Linux4Bene