
Hello, What would be the best way to generate detailed timing statistics for the history of each ticket? I need to track efficiency in solving tickets per ticket, per queue and per agent. I'm fluent in Perl and if the needed functionality is not there yet, maybe, with a few guidelines, I can do it myself. Regards, Damir

I'm working on that right now actually... Apart from some general information (# of new tickets, calls, e-mails) I think most stats are implementation-specific. Right about everything you need is put in the ticket_history table, so take a peek in there first. Things depend on how the ticket_history_id's are defined in the ticket_history_type table. If you would like more information, dont hesitate to ask! Hth, Edgar -----Oorspronkelijk bericht----- Van: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] Namens Damir Dzeko Verzonden: woensdag 17 november 2004 9:08 Aan: otrs@otrs.org Onderwerp: [otrs] Statistics Hello, What would be the best way to generate detailed timing statistics for the history of each ticket? I need to track efficiency in solving tickets per ticket, per queue and per agent. I'm fluent in Perl and if the needed functionality is not there yet, maybe, with a few guidelines, I can do it myself. Regards, Damir _______________________________________________ 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 Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/

Edgar Meij wrote:
I'm working on that right now actually... Apart from some general information (# of new tickets, calls, e-mails) I think most stats are implementation-specific. Right about everything you need is put in the ticket_history table, so take a peek in there first. Things depend on how the ticket_history_id's are defined in the ticket_history_type table.
If you would like more information, don’t hesitate to ask!
Hi! I've created two tables in OTRS data-scheme: ticket_history_stats and interval_descr_stats. Both are populated by my "ticket history stats" perl-script called via the cron this way: # generate summary for previous month 02 00 1 * * $HOME/bin/thStats.pl -m `date --date="1 month ago" "+%Y/%m"` First table: ticket_history_stats is keyed by ticket_id and contains timestamps when that particular ticket was created, opened, answered and closed, as well as cumulative times (in seconds) how many times each ticket spent in state "new", "open" but not answered (requiring action on agent's side). Second table: interval_descr_stats contains grouped statistics for some interval/queue (...) and it's functional columns contain values calculated with Statistics::Descriptive (count, mean, median, stdev). Beside that, I also needed snap-in module that could be used as query tool for the two statistical tables. I'm finding hard to predict all the possible state transitions to correctly cover all cases (like for example agent makes additional followup to already answered ticket, or when customer replies on already closed ticket). Can I send you my patches so you can make use of them. The patches were written for version 1.1.3, and now I'm doing an upgrade to 1.3.2. Are your patches available somewhere? -- echo $organization | rot13 | tac -rs. | mmencode -u

My patches are not available (yet :) ). OTRS has been used for roughly over a year now in the company I work for. I'm doing these statistics for them as my graduate internship. First off, I'm writing some scripts to poll the databases for a grand overview over the last year. Stats I'm collecting are e.g. resolution times, (1st) response times, probabilities and some data mining regarding products/customers and their problems. During the next stage it's my intention to implement these scripts as to integrate them into OTRS. "Beside that, I also needed snap-in module that could be used as query tool for the two statistical tables." OTRS 1.3.2 provides a stats-framework to do just this. You'd only need to code it :). " I'm finding hard to predict all the possible state transitions to correctly cover all cases (like for example agent makes additional followup to already answered ticket, or when customer replies on already closed ticket)." I know, it's a b&^%£. Just today I've managed to get my head (and Perl with it) around the whole follow-up/reply issue. I'd be happy to share what I've got (so far) with you and I'm very interested in your patches. You can send yours to this e-mail address. Where do I send mine? Kind regards, Edgar -----Oorspronkelijk bericht----- Van: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] Namens Damir Dzeko Verzonden: woensdag 17 november 2004 17:22 Aan: OTRS Onderwerp: Re: [otrs] Statistics Edgar Meij wrote:
I'm working on that right now actually... Apart from some general information (# of new tickets, calls, e-mails) I think most stats are implementation-specific. Right about everything you need is put in the ticket_history table, so take a peek in there first. Things depend on how the ticket_history_id's are defined in the ticket_history_type table.
If you would like more information, dont hesitate to ask!
Hi! I've created two tables in OTRS data-scheme: ticket_history_stats and interval_descr_stats. Both are populated by my "ticket history stats" perl-script called via the cron this way: # generate summary for previous month 02 00 1 * * $HOME/bin/thStats.pl -m `date --date="1 month ago" "+%Y/%m"` First table: ticket_history_stats is keyed by ticket_id and contains timestamps when that particular ticket was created, opened, answered and closed, as well as cumulative times (in seconds) how many times each ticket spent in state "new", "open" but not answered (requiring action on agent's side). Second table: interval_descr_stats contains grouped statistics for some interval/queue (...) and it's functional columns contain values calculated with Statistics::Descriptive (count, mean, median, stdev). Beside that, I also needed snap-in module that could be used as query tool for the two statistical tables. I'm finding hard to predict all the possible state transitions to correctly cover all cases (like for example agent makes additional followup to already answered ticket, or when customer replies on already closed ticket). Can I send you my patches so you can make use of them. The patches were written for version 1.1.3, and now I'm doing an upgrade to 1.3.2. Are your patches available somewhere? -- echo $organization | rot13 | tac -rs. | mmencode -u _______________________________________________ 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 Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/

Hi, in my mail to you are my additions to OTRS for handling statistics. There are quite a few things which require more work: - query tool; queue selection (single or many queues), date range, ticket status, ... - query results; selection of output mode: - tabular HTML - or CSV (for import into spreadsheets, etc.) - or XML (integration with other apps) - improvements in data-model (support for more than one queue), automatical refresh of records for which data changed (tickets were updated) - enbale alterations of business logic (calculating times and such) - enable customizations and localizations (for example for the local holidays table) It all requires a fair amount of work. That definitely is something which OTRS needs to be complete from the manager's point of view. I'd like to make it good and useful to community but it's just that it requires in depth knowledge of ticket state transitions. Regards, Damir
participants (2)
-
Damir Dzeko
-
Edgar Meij