New Plugin: Interactive Reporting

[jstanden]

This plugin is aimed at the requests of people who needed a way to see how many replies each worker was doing over a specific time period (for commission, etc.)

The Reporting plugin currently shows two sets of metrics:

New Tickets (by group, by range)
Worker Replies (by worker, by range)To enable the plugin:
Go to Configuration->Plugins and enable 'Reporting'
Click 'Reports' in the top navigation menuYou can change the date range of the charts by clicking the 'Range:' links below the image. This will also update the itemized breakdown below the image.

Note: Due to the way Cerb4 has been storing worker replies up to this point, your breakdown may not be accurate. It's possible to update these records from the database based on signatures unique to each worker -- we'll likely release a small tool to help with this. Cerb3 replies can be attributed more easily based on the sender addresses (Cerb4 physically sends all replies as the helpdesk to avoid exposing worker addresses in any functionality).

I'll post some information on the KB/wiki about synchronizing statistics if you have a long-established database.

Todo:

Create a simple, guided tool to rebuild database statistics for long-time Cerb customers.
Show the bucket breakdown per group on the 'New Tickets' report (this is already done, it just needs a clean UI).
Show the group breakdown on the 'Worker Replies' report (this is done also, it too just needs a clean UI)
Create a formal extension point for new interactive report plugins.
Updating from SVN:
http://wiki.cerberusdemo.com/index.p...s_Helpdesk_4.0 (http://wiki.cerberusdemo.com/index.php/Upgrading_to_Newer_Versions_of_Cerberus_Helpdesk_4 .0)

Enjoy!

[trafalger]

Am I to assume with the push of this to the SVN that custom reporting cannot be too far behind?

That and custom fields are keeping me from using cerb4 in production.

[neenach2002]

One solution to that reporting issue is changing cerb to use public_sender and actual_sender fields. For reporting, reference the actual_sender, but for actually sending out mail, use public_sender. Problem solved! :)

[jstanden]

One solution to that reporting issue is changing cerb to use public_sender and actual_sender fields. For reporting, reference the actual_sender, but for actually sending out mail, use public_sender. Problem solved! :)

Hey!

That's what we ended up doing (we link the message to a worker).

Realize, when I was talking about not showing the worker "From", I'm talking about the raw headers. Because raw headers on a reply are quoted as "worker@yourcompany wrote:" and such. If you leave the worker address in the headers then you're filtering it out of every piece of functionality that exists now and will exist in the future. That's a lot of room for things to go wrong because it requires proactivity.

So we can definitely have this second "message.worker_id" and "message.is_outgoing" level and everything is fine. The only problem becomes those things not having existed prior to the Reporting plugin -- so some of them can only be recovered through signatures. That's the point I was making.

[neenach2002]

Ahh I understand...but from anything added from now on, there's no longer an issue. :P It's just stuff that was added before you made the change.

[jstanden]

Am I to assume with the push of this to the SVN that custom reporting cannot be too far behind?

That and custom fields are keeping me from using cerb4 in production.

Yeah, the custom fields plugin is now at the top of my list. We've been knocking the top issues off really fast for the past couple weeks -- I wouldn't expect this to be any different.

Custom reporting is a trickier proposition. It just depends on how "custom" we're talking about. Which basically means how widely-useful a particular report is (not how many tweakable parameters it has).

I maintain my current position that too many good open-ended custom reporting tools exist for us to invest a ton of time in building another one. The keyword there is open-ended, because it implies you could develop a report for almost anything you can think of, without leaving the GUI.

Naturally, I wouldn't use that philosophy as a cop-out to avoid doing things which make perfect sense for most people's needs. For example, worker reply tracking is huge, because many reps get paid based on their number of replies or their average response times.

But if you want to make reports that are heavily-dependent on your company's own needs, I'm still going to say iReport and a well-documented database schema are the best tools I know of for the job. With those tools you can do almost any kind of aggregation, table, graph, chart, etc. The downside is that process isn't management-friendly (e.g., point & click).

Before I use up all the disk space on the server writing a reply to a totally tangential question on a thread nobody is going to read, I should probably ask the right question. ;)

What kind of reports would you want to make?

[jstanden]

Ahh I understand...but from anything added from now on, there's no longer an issue. :P It's just stuff that was added before you made the change.

That's exactly right! :)

I was also saying the stats for all Cerb 1.x, 2.x and 3.x replies are intact just fine. The only affected thing was the earlier Cerb4 builds when the new way wasn't established yet.

And I actually did come up with a way to attribute all our C4-beta replies to a worker, retroactively, in our live database. But it's not something that will make sense as a standard answer -- too many direct queries using MySQL-specific functionality, like sub-queries. MySQL 3.23 doesn't support those, but Cerb4 supports MySQL 3.23.

I could simplify the process a bit by not solving it in pure SQL -- that just makes it slower (like scripted languages vs. assembly). But if it was done in a disposable PHP script (like migrations) it could guide people to rebuild the metrics without them writing back-end SQL.

For some people it just won't matter. But our Cerb database has just shy of 6 years of statistics in it. I'd refuse to lose that information, even 3 months of it, and I know I'm not alone. ;)

[trafalger]

In the old Cerb3 I didn't use a single one of the integrated reports...instead I used Crystal Reports to create a report that simply shows all closed tickets with a Time Tracking entry, who worked the time, and what they did. It also shows the custom fields of "Parts Used" and "Trip Charge (YES/NO)"

We do not use our helpdesk for a call center. 80% of our tickets are for on-site work at customers. We use it for dispatching and tracking of time and parts.

There is also a custom field of "invoice Number" but this isn't used on my reports. The AR girls enter it on the ticket after they bill it so we in the field can see the invoice numbers in case the customer asks.

I really really don't want to have to use Crystal Reports again, not because it's hard but because it's very clunky to have to set up on each machine that needs to see the data. I have tried looking at the iReports and I can't make heads or tails of any of the webpages. I can't tell if it's a pay product, open source, community, web based or how to install it without borking up the whole server. Since we are going to roll out Cerb4 properly this time I don't want it all contained either inside of cerberus or at least on the web server.

[jstanden]

Hey trafalger,

If you have specific reports you want to build, I can help you get the right information out of Cerb4.

The custom fields feature is at the top of my list (barring any usability issues or bugs that come up along the way, which get precedence over new features).

We've made it incredibly easy to get information out of the database in an abstract way (meaning, it's not just to render to HTML or for a specific feature). The incredible flexibility of the codebase isn't able to be done justice in the UI.

The reporting area we committed is a placeholder for new report plugins that will be able to do almost anything. These could be written specifically for you (by you, by us, or by a third party familiar with PHP).

To the extent you just need lists, custom searches are getting really flexible when used in conjunction with private workspaces. But our lists/searches don't handle aggregation which you'll need on many reports. Report plugins, or anything done against the database directly, could do that no problem.

Again, until there is better documentation in place on our end, I'd be happy to answer HOW-TO questions concerning the code, DB, etc.

[todd999]

"What kind of reports would you want to make?"

the most basic report we need is to see staff productivity by mailbox"

Who is working/closing the most Tix in the sales mailbox? and what % are closed in X hrs..

we have a great report for this in v3:
Service Level Report - (by resolution time) which meets 90% of our needs...


While we are on reporting... Would it make sence to just build a plugin that would truly integrate iReports and come with some sample reports as a starting point?

[rlocke]

Hi,

We are using the hosted Cerberus 4 platform and are wondering if there is any way for us to generate custom reports? We are quite happy and capable of doing this "offline" assuming we can get our hands on the data, but I'm not sure if that's possible.

Any ideas/suggestions?

Best,

Rob

[jstanden]

"What kind of reports would you want to make?"

Good ideas! I'll link this to the feature request so we can review it when we're working on it.

While we are on reporting... Would it make sence to just build a plugin that would truly integrate iReports and come with some sample reports as a starting point?Absolutely! We can offer quite a bit in the GUI, but it's never going to be as infinitely flexible as iReport would be. I think some example queries and reports would go a long way.

[knetix]

With the new reporting system, are there any plans to re-introduce reporting for ticket response rates (the time between a ticket being opened and replied to) and ticket resolution rates (the time between the ticket being opened and closed)?

Cheers,

Michael

[mallen]

Having the ability to report ticket response rates and ticket resolution rates would be a HUGE advatage for us; PLEASE, PLEASE add this!

Also, we would love to see in the Reports section the ability to costomize the date range of reporting, like just having a start date box and an end date box for the range you want to report.

Thanks!

[jstanden]

With the new reporting system, are there any plans to re-introduce reporting for ticket response rates (the time between a ticket being opened and replied to) and ticket resolution rates (the time between the ticket being opened and closed)?

Absolutely! I'll have Joe@WGM add these ideas to the roadmap. I was just thinking the other day on how we can do the response time tracking a lot more efficiently with the new setup.

I'm also working on a quick iReport/Jasper (completely custom report) HOWTO for the wiki/blog. This will let people create and share reports in a variety of formats (list/tabular/matrix) with custom charts/graphs.

Also, we would love to see in the Reports section the ability to costomize the date range of reporting, like just having a start date box and an end date box for the range you want to report.

That should be no problem at all. That's essentially how those "24 hour" and "6 month" style quick links work behind-the-scenes. It would be easy to expose a "custom" option.

It was just waiting for somebody to ask! :)

Thanks for the feedback guys!

[edward.beny]

We would also welcome at least some guide how to use iReport (exaplme queries or table documentation - the current functionality of the frontend in v4 is good, but management wants always something special ;). Agreed, reporting is so complex that its hard to fulfill everyone needs.

Ondrej

[trax]

amen - bring on the custom reports.

[brianandrus]

I would like to at least see the same reports as Cerb3. I am not likely to upgrade without access to those, especially agent and group response times.

[rfarnell]

I would like to at least see the same reports as Cerb3. I am not likely to upgrade without access to those, especially agent and group response times.

This is also something that we are waiting for although we have already upgraded.

These also spring to mind:
http://www.wgmdev.com/jira/browse/CHD-397
http://www.wgmdev.com/jira/browse/CHD-440
and especially:
http://www.wgmdev.com/jira/browse/CHD-448

448 doesn't appear to be assigned to 4.0 or 4.1 which is a real shame.

Vote these up on JIRA if you want this functionality sooner rather than later.

Regards,

Rob