Hi Damir and all, Never mind, got it working now... back to the analysis...
Edgar -----Oorspronkelijk bericht----- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Edgar Meij Verzonden: maandag 29 november 2004 13:53 Aan: 'User questions and discussions about OTRS.' Onderwerp: RE: [otrs] Statistics Hi Damir, I've finished work on the queue-changes thing. My app now splits up the ticket history of a particular ticket into intervals, each associated with the particular queue. It determines, for each interval, the time it spent there (minus the time the ticket was with the customer) and the 1st response time, if applicable. The time per ticket spent per queue is significantly more detailed. My guess is the same thing can be done with owner changes. I'm now trying to implement business time calculations to put further detail into my analysis, but I'm having a hard time coping with the timezone settings in Manip.pm. For example, the unix_timestamp created by timegm for '2004-11-3 17:40:02' is 1079026802. Looked this up with &DateCalc("Jan 1, 1970 0:00:00",1079026802) and it returns the correct time. However, if I calculate epoch seconds for the same date with &UnixDate(2004-11-3 17:40:02,"%s") I get 1079023202 seconds (&DateCalc returns for this value '2004-11-3 16:40:02'), thus missing one hour. I've tried various timezones and other settings, but nothing seems to work out. Perhaps you know what I'm not seeing? Kind regards, Edgar -----Oorspronkelijk bericht----- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Damir Dzeko Verzonden: woensdag 24 november 2004 18:35 Aan: [EMAIL PROTECTED] Onderwerp: Re: [otrs] Statistics Hi Edgar and all, (I'm returning this discussion to where it belongs) :) Edgar Meij wrote: > Good morning Damir, > > "for time calculations I've used Date::Manip which knows of business > time calculation" > Good point, I'll take this up with my manager. Our helpdesk however, is open > till 9pm and during weekends as well, so It'll still need adjustments. The > customer probably doesn't live only in business time, so I think 1st > response times would still have to be calculated in 'normal' time. We rely on auto-response system to tell customers that their ticket is being processed. Auto-response message tells them not to expect much if they posted a ticket in off hours. > " In my program/module I've used Perl module Statistics::Descriptive to do > all the hard stuff" > Can it also do hard stuff like "what's the probability the 1st response time > for a new ticket would be say, >1 hour, based on the tickets collected so > far"? Well, first, it would be needed to understand the nature of the process, or to study the distribution (exploratory data analysis) to achieve that. I'd expect that the solving time follows log-normal or gamma distribution (the bell is skewed toward smaller values but with fair possibility of extremes - tickets that are solved in a few days). But for some things approximating it with plain old Gaussian normal function, especially around middle point (maximum of the probability density function) would do just fine. So, basically, I would iterate it few times and extract out the extremes (they would spoil the average, like it's not mean already :), and then use what's left like it fits normal distribution (average, st. dev.) You have to cheat if you wan't to reduce it to single-dimensional value which still holds some mean-ing. ;) :) (IMHO) > " Basically, our manager wants to know how long has the customer waited for > first response, and later how much he waited for our agent to process his > case." > In your case, the agent sends a reply first saying "I've started work"? And > then sends the actual answer later on? Since we don't have this step (we > just send an auto-reply, saying we got their e-mail) our models are > otherwise the same I'd say. That's the same thing we do. Auto-response tells our customer that it's ticket reached our system and will require some attention right away (or, the next morning ...). Also, that first auto-response should be left out from stat. analysis. > " I think it will be more efficient if I write the skeleton to link the > module with OTRS web-interface" > Indeed :-). Looking forward to seeing it... I'll prefer to start a new page and not bloat the existing one in Stats Area. Query-builder for that module could have many options: date-ranges, days, months, time in day when the ticket was created, ... type of first article (email/phone-call), queue, ... And for the results, there could be many parameters describing output: CSV/HTML, which fields, grouped, sorted, ... > " > This 'total > > resolution time' minus the time the ticket was 'with the customer'. > That's another thing. :) I like this approach. May I use it?" > Of course :-). Thanks. Also thanks to developers of OTRS for sorting out things with ticket history types. In previous version (1.1.3) that thing gave me headaches :) > In the version I made yesterday I've also integrated the day, month and time > of day the ticket was created. It's now possible to do queries like 'how > many new tickets were created on Monday morning over the past year?' or > 'What's the busiest day of the week in terms of either calls/e-mails (and > act accordingly, ie. assign more staff that day). I already see it becoming real data-mining sub-system :) There sure are LOTS of interesting things which can be analyzed from already gathered data. But think what will happen when maybe some new release of OTRS gives customers the possibility to rate effectiveness of individual agents (enables for stimulative measures to improve quality of service) and answers found in FAQ sections as well (enables value assessment of the whole system in it's task to produce knowledge). Good system could easily outgrow itself and become a moderated community lead by experts which guarantee for quality of final answers but who are helped by senior customers who can take the challenge to answer open questions themselves. (That would be appropriate for academical or some other collaborative environment.) Now, measuring effectiveness of such system would be quite a challenge. > I've also looked into the whole queue-changes thing and come to the > conclusion it makes a significant difference in resolution time. Meaning, > that IF a ticket has been moved once or more, the resolution time rises > dramatically (and reply times as well btw). Now I just have to find a way to > enumerate this. I'll probably go ahead with determining something like the > total-time-per-ticket per queue. Interesting case. I guess that in that case analysis should be divided into two perspectives: customer's (as ticket never moved) and agent's (queue's, group's, ...) -- determine whose liability was to answer the ticket (or move it) and put the time passed on their account. Kind 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/ _______________________________________________ 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/ _______________________________________________ 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/
