Redefining SLA Management in Service Desk Manager

[Anon Anon]

We are currently in the process of revamping our SLA's so that the violation occurrence is based on the category and notification escalation is based on the priority. We want to use five different bands for our SLA Management. I have attached a PDF depicting what we hope to achieve. Any suggestions would be greatly appreciated.

Attachment(s)

SLA Definitions_Proposed.pdf   83 KB 1 version

[Kyle_R]

Hello,

Nice requirements spreadsheet!

1) What version of Service Desk Manager are you using?
The most recent ones allow greater control over allocating to different conditions such as Priority and Category.

2) Can you expand on "SLA's so that the violation occurrence is based on the category"?

The spreadsheet seems to indicate that "everything" is triggered off these distinctions:
* Priority
* Ticket Type - Incident or Request
* Time (days/hours)

I wasn't sure how the "SLA Violation" column linked into "category." Is this via Service Type to Category link?

3) Which single part are you most "stuck" on?
My impression is that most of what you wish to achieve can be done by Service Types and Events, much as you've outlined.

4) What specifically does "Escalate to Manager" entail? Would it involve changing the "Assignee" or "Group" or just a Notification?

Put some more details here, and we'll see what the Message Board comes up with.
Formal engagement method, if required, would be to CA Technologies Services or Business Partner, if more detailed design work is required.

Thanks, Kyle_R.

[Anon Anon]

Hi Kyle_R,

1) We are currently using SDM v12.5
2) Currently violations are set by priority in our environment. For instance a priority one ticket will violate within one day. We now want the priority to drive the notification to management and the category to determine the sla violation. The violation is different per ticket type and we would like to the priority to determine how fast management is notified
4) Escalation to management would be driven by priority alone.

Pleae let me know if you require any further details. Thanks.

[Kyle_R]

Hi rspringer,

The Service Desk Manager 12.5 PDF documentation is where to start. Use "Cntrl F" within a document, and then choose the search to go against the whole Service Desk documentation folder. Eg "Service Type."

See p141 on "Service Level Agreements" and review that whole section. The functionality that you want can be handled: See SLA Usage for the overview of what is possible.

The basic "feature" that you need to use to address the business need is that of having "multiple Service Types" run against the tickets.

Set up a Service Type against Priority and one against Category.
(Note the distinction on "public" - available to all clients, and "private" which confines the setup - which requires implementing Service Contracts.)


We may only be able to provide general pointers in this forum, rather than get right down into design detail. There are avenues such as Chat (for quick questions), log a Support issue (to discuss out-of-the-box functionality with an engineer) or a CAT Services or Business Partner engagement to review the whole process and implementation from start to finish if desired. Although by all means post further here, and others may wish to chip in their 2c.


Thanks, Kyle_R.

[Anon Anon]

Thank you Kyle_R. Do you know of a way to determine the service type of an category from within a macro?

[System]

Hi Kyle,

Did you have an answer for the last question asked?

Thanks for all your help!
Chris

[Anon Anon]

You can do one of the following tests in Spell Macros - assume the cr object:

// test for the persistent_id
if ( category == "pcat:400001") {
// your code here
}

// test for the code attribute
if ( category.code == "MYCODE") {
// your code here
}

// test for the sym attribute
if ( category.sym == "My custom category sym") {
// your code here
}

Hope this hepls.

[Anon Anon]

I have been working on this with David Vaughn from CA and it was determined that the approach I implemented in our development environment seems to be best suited approach. We will have to attach 31 events to each ticket in order to facilitate the need to have our users select how fast or how slow management is notified.