No More SLAs?

[samuch]

Why was the SLA option for companies taken out in this version? That's a huge feature for us and other companies providing managed services.

I see that I can add "Due" to the display in the mailbox but that's not going to work if there is nowhere to specify SLA. Any thoughts?

[jstanden]

Hey there!

The "Due" column in Cerb4 isn't used for the same purpose as Cerb3. In V4 it will automatically hide a ticket until a certain date (that's the option you see when replying and you can "this conversation is closed until ___".

We understand that the SLA functionality was important to some people. However, we're trying to not add anything back to Cerb4 impusively when our only ideas on the how/why would be "like we did it before" and "because we had it before".

A lot of things in Cerb3 were hacked together, and the major reason we did the full rewrite was to add coherence back to the system. When we're adding new things now we want them to fit in perfectly with the other concepts.

We're all for an SLA plug-in, but let's think about how it should work now that we have a clean slate and the ability to do a much better solution than before.

People seem to be of two-minds regarding SLA: That it should be tracking stats on average response times helpdesk-wide; or that it should auto-prioritize work based on paying users or specific contract overrides.

What are your specific needs for SLAs? It would be a good place for the convo to start.

Thanks!

[simonpt]

my basic requirements are time based escalations, and notification there of. I need to set different SLA's per email domain . . . I need to be able to run reports on this data to see if I'm hitting targets.

[bbillings]

"People seem to be of two-minds regarding SLA: That it should be tracking stats on average response times helpdesk-wide; or that it should auto-prioritize work based on paying users or specific contract overrides."

Any reason why both can't be applied? Really, we need a response time benchmark to set for agents, the ability to report on if that benchmark is being met, and optionally an action point (Escalation/Auto assignment) if that time frame has passed or is close to due. The utopian route would be a default group level response time, with the ability to override that on a per-customer basis.

Our problem comes in we often sell more than one product to a customer, each one with it's own support expiration date. We use the SLAs in 3.x to mark response due times, however only one expiration date isn't practical for us so we have a separate system to track if a customer's contract is expired or not. This is probably something I'll accommodate via a plug-in for 4.0, unless you beat us to it.

[cjbengtsson]

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

[jstanden]

Alright!

I committed the first phase of Service Levels to SVN.

This doesn't do everything we've talked about yet. At this point we've avoided doing SLA schedules or due dates, because neither of those solutions were very effective in Cerb3.

At the moment in Cerb4, you can define a simple 'Service Level', which acts as a contact group (for example: VIPs, Paid Support, Management, Friends, etc). You can prioritize these Service Levels so you know your workers are pulling work (through the new 'quick assign' feature) in 'service priority' order.

Since Service Levels aren't sharing the priority space of due dates with non-SLA tickets, it's a lot more effective now to know you're handling paid work (or internal management work) first. It's automatic.

The totals for any tickets associated with a Service Level are also shown on the new Mail->Overview screen. So, if you're like me and log in occasionally at night or on the weekend to make sure nothing critical has been sent in, you can tell at a glance based on service level.

I also run my personal webmail through a Cerb4 instance, and this Service Level concept has been a huge boon. I just added colleagues, friends and family to service levels and now I know I'm always reading their mail first.

Over time, we can explore how detailed service levels need to become. However, for due-date management and commitments I'd really opt to handle such things in a reminder/tasks system inside Cerb. Cerb could still automatically created those tasks by service level (using a mail rule). It gives you a lot of flexibility and it doesn't create a faux "best practice" by canonizing clutter in Cerb's core.

[badcaptain]

Hi - the lack of escalations within SLA definitely hurts. Even tho it wasn't particularly strong in v3, at least I could monitor the queues for timeliness.

So my recommendation would be the following - greatly enhance the email notifications with more conditions and filters. I would start out with at least the following (and the ability to stack them)

last response within (relative time period)
last response from (regex or simple filter for an email address)
sla level <,>,=
sender email regex/filter
comment added to string (versus a reply)

The main problem I had with email notifications in the previous version (and this version) was the inability for a manager to mandate them for staff. Sometimes, I don't want to give my guys an option (and I certainly don't want them to be able to turn it off) to get a notification. And even with the best of intentions, people forget to update them.

So perhaps it's best to make a standalone module so that it can be centrally controlled.

/k