Service Level with attributed Priority and Response time targets

[rfarnell]

This should probably belong in the Feature requests section, but I feel it is of sufficient importance to place it here.

I am being leaned on heavily by management to provide service level agreements to our clients and back up our performance with reports (see http://www.cerb4.com/forums/showthread.php?p=4903#post4903 ).

I am also finding it very hard to design a way in the system to constantly patrol the response time targets using customised workspaces.

Currently there are two ways to attribute priority of a ticket on Cerberus via the service levels and via the group buckets (Response Time Targets). It would be nice to have an overriding setting via the service level page (one per service level) that superceded any value set for the group buckets if the value is less. It would also be nice to have a baseline response time for the group for tickets that haven't been assigned to a ticket.

At the moment, I have been forced into creating a custom field called Due Date and manually fill in the value to try and keep a heads up of when a ticket is due by (based on the Response Time Targets). What I would have much preferred was for the default "Due" field to automatically display a date and time and turned a different colour e.g. red when the attributed response time has not been achieved based on the response time targets for that bucket/top level group. This will then allow me to order my tasks efficiently rather than by the current "service level" which on most occasions is not useful to our requirements in terms of prioritisation.

In reference to the paragraph above, it is not viable to use the tasks page unless it became an automatic setting.

In summary I am looking for a way to display tickets in a Response Time Target order with a flagging system showing a ticket is almost due or is overdue. With that I want reports to prove we are meeting agreed response times and help managers make necessary changes to our process.

Regards,

Rob

[samuch]

I second this. Would be extremely useful to have SLAs back.

[rfarnell]

I second this. Would be extremely useful to have SLAs back.

Is the lack of response by the Cerberus team intentional?

I thought I put my argument across reasonably. Is this something that can be implemented in the near or far future?

Thanks in advance for your reply.

Rob

[Hildy]

Sorry, Rob. No, it's not intentional. I'd started composing a reply in a text editor, and it got lost in the clutter on my desktop...

============
Rob,

SLAs are something we don't personally have a high use / demand for, so it's something where we may not be the best people to design this. I was going to point out http://www.wgmdev.com/jira/browse/CHD-537 'til I realized you've already seen it and voted for it. That and http://www.wgmdev.com/jira/browse/CHD-538 have both been marked as 4.1 issues because they're not terribly popular ones (at least based on votes: 537 has 2, and 538 has only 1). I've added a link to this thread to the comments on 537, but you may want to add additional clarification there as well.

The SLA-type stuff we currently have is:

The Response Target on the Bucket is used, in the code, for exactly one thing: coloring the last updated date red on ticket lists where the time elapsed since the last updated date is greater than the response time target (see plugins/cerberusweb.core/templates/tickets/ticket_view.tpl.php, lines 112-121). It could be easily expanded to do different things based on just how overdue it is, but the list isn't going to be able to be sorted by overdue-ness (if that makes any sense).

SLAs are:
a) added to the ticket object if present during parsing
b) available as search terms / columns on addresses, orgs, & tickets
c) used in auto-assigning to assign the most important work first
d) the default sort order in the mobile plugin (and I think in the main ticket lists, too)


The Due field on tickets is a bit confusing... it's the reopen on date (When you reply and close a ticket, and mark it to reopen at a later date). It's not a "this ticket must be done by" date. If you're referring to the due date on task lists, it does turn red when overdue, and the task list can be sorted by priority or by due date. It may be not-too-difficult (I haven't looked into this specifically) to add something that automatically creates tasks for incoming tickets, but it would be an artificial step that I suspect would break down with usage.

Whatever gets done to improve SLAs, the reporting won't be difficult (even if it's not included in the default package, iReports can be used to do almost anything you want). You could probably even generate some reports using the current bucket response time targets.

[rfarnell]

Thanks for your detailed response I realise that it wasn't the run of the mill question I was raising.

I also realise that a ticket helpdesk can be used in an infinite amount of ways, but really it boils down to only a few distinctions on how a groups system works:

Order of resolving tickets
Prioritising important clients/tickets
Allocation/Delegation of tickets


One group will work on a first come first serve basis which is fine when everything coming in is on the same playing field. We however work as an internal ticketing system from trivial tasks to all hands on deck situations. It can become incredibly difficult to keep every juggling ball in the air to know what to do first when the system does not supply useful information.

Looking back at old tickets displays values larger than a year for last updated and created which is technically true. However, for closed tickets I would be much more interested in knowing how long the ticket was open for. I could use this information to identify issues in our process, but it is currently hidden from me in the action logs.

How difficult would it be to simply have a date entered into the due column through the parser determined by the Response Target on the bucket?

I am keen to get to grips with iReports, but it has seemed daunting when I have tried to get it to work in the past. It would be useful if you could create some simple tutorials on how to interact with the database and report design e.g. key tables etc. I would be happy to share some of my templates on the forum if others would as well.

Regards,

Rob

[rfarnell]

I was looking at a demo of one of your competitors products and liked the look of some of the settings that were adjustable in the admin configuration panel:

SLA plans (based on work schedules) can be assigned to users, tickets and departments. SLA plans and escalation rules allow for advanced workflow implementation, enabling you to offer different levels of support and response time across different departments and users.

SLA Schedule
Specify the work schedule that this SLA plan will use to calculate overdue times (i.e. the overdue clock will not be running outside of open hours).

Ticket Status Association
SLA plans can be assigned to a specific status. For example: It is possible to ensure that tickets with the status "Open" are handled within a timeframe of 24 hours, while any ticket with the status "Escalated" is handled within a timeframe of 1 hour.

The reports that were available were:
Work Summary - An outlook style timeline of all tasks a user has done on the system. Other users can be reviewed if the user is a manager.
Department Summary - Shows how many tickets are currently open, closed or on hold for each internal department each day (and overall).
Service Level Report - Shows whether each ticket was within SLA or not.
Response Time Report - Shows average response and Time worked colourised based on whether Response time SLA achieved or not.

I'm not suggesting that you simply lift these designs and put them in your own solution, but I do feel that they are basic management tools for a ticketing system and I'm sure others would agree.

Regards,

Rob

[DBowsky]

SLA plans (based on work schedules) can be assigned to users, tickets and departments. SLA plans and escalation rules allow for advanced workflow implementation, enabling you to offer different levels of support and response time across different departments and users.


I certainly agree that something like this needs to be implimented. Setting response time and due date to individual tickets or to ticket categories (custom fields) or to buckets.

The current response time setting on Buckets doesn't do much, the current "Due_Date" field is actually a ticket re-open date, if the ticket is closed. There needs to be real Due Date functionality which can be assigned either manually from within a ticket, as a bulk action, as a list action, or programmatically through an SLA structure linked to either a requestor, an organization, a ticket type, a bucket, or an individual ticket.

[joegeck]

However, for closed tickets I would be much more interested in knowing how long the ticket was open for. I could use this information to identify issues in our process, but it is currently hidden from me in the action logs.


Let's start with this one. I went ahead and filed this improvement request for the developers to look into.

[SLA/Reports] Display how long closed tickets stayed open
http://www.wgmdev.com/jira/browse/CHD-767


How difficult would it be to simply have a date entered into the due column through the parser determined by the Response Target on the bucket?



The Due field on tickets is a bit confusing... it's the reopen on date (When you reply and close a ticket, and mark it to reopen at a later date). It's not a "this ticket must be done by" date. If you're referring to the due date on task lists, it does turn red when overdue, and the task list can be sorted by priority or by due date. It may be not-too-difficult (I haven't looked into this specifically) to add something that automatically creates tasks for incoming tickets, but it would be an artificial step that I suspect would break down with usage.


OK there's two quotes here, let me explain...First your quote Rob, that request is definitely reasonable and I filed it into JIRA:

[SLA] Automatically give tickets a pre-set due date based on their buckets response time target
http://www.wgmdev.com/jira/browse/CHD-768

As far as that second quote from Hildy, one of our developers. Ironically it wasn't addressing your request directly but if you 2 & 2 together, hmmm, does that sound like a possible workaround for you or is it just me?

If so awesome, I added a comment to the filed request in JIRA so hopefully these two disjointed thoughts compliment each other.


I am keen to get to grips with iReports, but it has seemed daunting when I have tried to get it to work in the past. It would be useful if you could create some simple tutorials on how to interact with the database and report design e.g. key tables etc. I would be happy to share some of my templates on the forum if others would as well.


Reports are coming very soon. We will provide examples on how to create your own with custom data. So please be a little more patient :)


I'm heading out of the office now, but I took a lot of notes on this entire thread and will attempt to address them shortly. A lot of the things I haven't discussed I'm going to throw into our tracking portal, just like the ones already. I just need another working day to go through all the little nuggets of idea, transcribe them and cross-reference them here in the thread. Stay tuned!

[joegeck]

Here we go again,


I was looking at a demo of one of your competitors products and liked the look of some of the settings that were adjustable in the admin configuration panel:


This is the first of many features Rob points out that our competitor's products have. The rest of this post is in response to each of those individual ideas :) Enjoy!


SLA Schedule
Specify the work schedule that this SLA plan will use to calculate overdue times (i.e. the overdue clock will not be running outside of open hours).


Interesting idea that I hopefully summarized well in the JIRA feature request:

[SLA] Scheduler option to set office work hours that can be used in conjunction with overdue times
http://www.wgmdev.com/jira/browse/CHD-810


Ticket Status Association
SLA plans can be assigned to a specific status. For example: It is possible to ensure that tickets with the status "Open" are handled within a timeframe of 24 hours, while any ticket with the status "Escalated" is handled within a timeframe of 1 hour.


This one's a little tricky because we technically have response time targets attached to buckets and not to service levels, which have priorities instead. Hmmm maybe the developers will consider merging the two concepts. There's already an open JIRA issue for implementing automated ticket escalation. I take it this would go hand-in-hand with the revamped system, so I'm going to add this in the comments section.

Implement Service Levels (SLA) Ticket Escalation
http://www.wgmdev.com/jira/browse/CHD-537


The reports that were available were:


I'm happy to say that reports have been recently revamped and are currently being finalized in the dev branch. In a couple of days these should be in stable for your using pleasure! There will be a formal announcement coming, but here's a sneak peak.


Work Summary - An outlook style timeline of all tasks a user has done on the system. Other users can be reviewed if the user is a manager.


There is a new report for tracking "Worker History", letting you zero in on a particular worker over specified dates. I think this will at the very least cover the basics of what you want. Let us know when you get a chance to play with it if there's anything we need to improve on.


Department Summary - Shows how many tickets are currently open, closed or on hold for each internal department each day (and overall).


I think this will cover you, new reports include:
* Open Tickets By Group
* Closed Tickets By Group
* Waiting Tickets By Group


Service Level Report - Shows whether each ticket was within SLA or not.


As I'm sure you've guessed, SLAs are something everyone in this thread believes is limited. And perhaps you guys are right as service level reports are something we are indeed missing. I filed a request here:

http://www.wgmdev.com/jira/browse/CHD-811


Response Time Report - Shows average response and Time worked colourised based on whether Response time SLA achieved or not.


We have an "Average Response Time" report currently in the final stages of development, but I don't believe it's perfect at the moment. And of course as hinted above SLA & reports aren't the best of friends yet. I added another report request to show whether response time SLA was achieved or not:

http://www.wgmdev.com/jira/browse/CHD-812


SLA plans (based on work schedules) can be assigned to users, tickets and departments. SLA plans and escalation rules allow for advanced workflow implementation, enabling you to offer different levels of support and response time across different departments and users.


I certainly agree that something like this needs to be implimented. Setting response time and due date to individual tickets or to ticket categories (custom fields) or to buckets.




Valuable suggestions! I copied your comments directly into a new feature request:

[SLA] Add service level plans that can be assigned to workers, tickets, groups/buckets and custom fields
http://www.wgmdev.com/jira/browse/CHD-802


Due Date functionality which can be assigned either manually from within a ticket, as a bulk action, as a list action, or programmatically through an SLA structure linked to either a requestor, an organization, a ticket type, a bucket, or an individual ticket.


Even though you were expanding on the options you'd like to see added to improved SLA plans, "due dates" themselves are a new request in my opinion. I filed this separately with a link to CHD-802 mentioned above.

[Tickets] Add option to add real "due dates" throughout the Helpdesk
http://www.wgmdev.com/jira/browse/CHD-803


It would be nice to have an overriding setting via the service level page (one per service level) that superceded any value set for the group buckets if the value is less.



It would also be nice to have a baseline response time for the group for tickets that haven't been assigned to a ticket.



What I would have much preferred was for the default "Due" field to automatically display a date and time and turned a different colour e.g. red when the attributed response time has not been achieved based on the response time targets for that bucket/top level group.


Actually Dan/Hildy [WGM] already linked the entire post to this feature request:

Implement Service Levels (SLA) Ticket Escalation
http://www.wgmdev.com/jira/browse/CHD-537

I tried to improve the JIRA issue by transcribing the above quotes directly in the comments section. To me these particular snippets were relevant and extractable ideas that could be implemented. The comment in JIRA still includes a linkback to that post so the developers can read the whole thing in context.


This concludes Day 2 of my feature request hunt. Just a reminder, please hit up those URLs and give any feedback as well as vote.

Thanks and now I'm going to go take a nap! ZZZzzzz :)

[rfarnell]

Joe,

Thank you for the awesome reply. I woke up thinking I wanted to do an SVN update on the dev branch but I didn't know why!

Really impressed so far with my preliminary testing. Will update in the next week or so any comments I may have, but I'm pretty sure they will be positive.

If you are reading this, then make sure you read the post above and vote for any JIRA tickets you want implemented.

Rob