This sounds great. If this could be integrated with rules to move the ticket to a different bucket depending on SLA or ticket age that would be fantastic.

...and http://www.cerb4.com/forums/showpost.php?p=5622&postcount=1

Customer suggestion for ticket SLA:

Let users login to the support center to check on the Due Date once ticket sla is implemented.

http://www.cerb4.com/forums/showpost.php?p=5860&postcount=1

Dan [WGM] commented already with a link a while back for comments from Rob. I was doing my forums->JIRA scrub and didn't realize Dan made a linkback. I already had extracted all the "feature requests" type responses from that post and am going to bug them separately. I'm posting the relevant pieces here and create new issues for the rest.

Since I can't edit the original comment in JIRA, to avoid confusion I'm going to delete Dan's comment and re-package it here:
_______________________

Comments from Rob at http://www.cerb4.com/forums/showpost.php?p=4930&postcount=1


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.

More details from Rob:
http://www.cerb4.com/forums/showpost.php?p=5501&postcount=6

[[quote]]
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.
[[/quote]]

Joe [WGM]:
As I posted in the forums, 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. But I assume this would fit well with a revamped ticket escalation system.

From a comment in the blog post:
http://www.cerb4.com/blog/2008/09/25/setting-response-target-times-for-your-tickets/#comment-1220

[[quote]]
What about email notifications about reponse times?
lets say you want to elevate a ticket and just send emails first to group if it hasn't been handled within a certain timeframe, then elevate it to team leader later on etc.
[[/quote]]

SLA's based on domain could be part of an entire SLA escalation system if we decide to do so.

Note for Joe@WGM: Update the "My Cerb4 Wishlist" thread when completed.

http://www.cerb4.com/forums/showthread.php?p=7185#post7185

Update this thread when completed.

http://www.cerb4.com/forums/showthread.php?p=10257#post10257

Update this thread when completed.
http://www.cerb4.com/forums/showpost.php?p=594&postcount=4

http://www.cerb4.com/forums/showpost.php?p=881&postcount=5

Already posted this in Beta tester section, then I found this.
Here are my needs for SLA.
I am currently working in 2.7 so I might have missed some but this is what I need.
This can't be done in 2.7 for sure for several reasons.
Will this be possible in 4.x?

Possible to have one general SLA for all queues.
Example settings:
Priority 1 | 24x7 | time to solution 24h | 7 days per week
Priority 2 | office hours | time to solution 7 workdays | 7 days per week
Priority 3 | office hours | time to solution 1 month | 5 days per week
Priority 4 | office hours | time to solution infinite | 5 days per week
Priority 5 | office hours | time to solution 10 workdays from specific date
(priority 5 starts counting when hardware is received at factory)

Escalation mails sent:
When opening priority 1
When priority 2 is 50%
When priority 3 is old
When downgrading priority 1 to 2 (and the other way around) When downgrading priority 2 to 3 (and the other way around) When downgrading priority 3 to 4 (and the other way around) When priority 5 is 4 days from end

At this point, SLA functionality of more of a training issue than a development issue. SLA can be modeled using custom fields and mail filters. There are a couple things the toolset could do better for this; which is why I'm moving it to 'Cryostasis' opposed to rejecting it. Cerb4 is about more than just customer support, so SLA functionality will probably never be a part of the core project. That doesn't mean we won't make it possible to do, it will just require some assembly.

+1
http://www.cerb4.com/forums/showpost.php?p=13932&postcount=1

Implemented in 5.5-dev:

* [Virtual Attendants/Scheduled Behavior] [CHD-846] [CHD-1123] Virtual Attendants can now schedule behavior to happen at a future date. This provides an incredibly flexible way to build reminders and automated followups. For example, if an incoming message is from an organization with a service level agreement (SLA), your Virtual Attendant could schedule behavior in 2 hours to check the status of the ticket and react appropriately (e.g. escalate). Scheduled behavior can also reschedule itself, providing the ability to create loops of behavior that repeat until certain conditions are met. For example, if the duration since the last worker reply is too long according to the SLA, a reminder could be sent to the record's watchers every hour until rectified. Each new reply from a customer could initiate the behavior loop over again. Scheduled behavior is managed by a queue that runs as part of a scheduled job from /cron, which is more efficient than holding up the email parser or worker UI during long-running tasks.

See:
http://cerberusweb.com/support/kb/article/63-Enforcing_Service_Level_Agreements_(SLAs)_with_Virtual_Attendants_and_scheduled_behavior