Re: [otrs] Reporting for accounting and setup best practices for multiple customers
Holger Erb
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: HE...@MSXI-EURO.COM
-----Ursprüngliche Nachricht-----
Von: otrs-b...@otrs.org [mailto:otrs-b...@otrs.org] Im Auftrag von otrs-r...@otrs.org
Gesendet: Donnerstag, 28. Mai 2015 14:00
An: ot...@otrs.org
Betreff: otrs Digest, Vol 80, Issue 18
Send otrs mailing list submissions to
ot...@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-r...@otrs.org
You can reach the person managing the list at
otrs-...@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 <linux...@telenet.be>
Subject: [otrs] Reports for accounting and setup best practices for
multiple customers
To: ot...@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
Linux4Bene
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
<snip>