RT::Extension::SLA Question

I am try to use RT to replace our current help desk system but have been struggling with 2 points:

1.) We have an SLA with our customers and need to be able to incorporate that into our ticket system. I have installed and begun configuring the SLA extension but I am not really sure if it is set up correctly here is my config:

Set Business Hours

%RT::ServiceBusinessHours = (
    0 => { Name => 'Sunday',Start => 'undef', End => 'undef' },
    1 => { Name => 'Monday', Start => '07:30', End => '17:00' },
    2 => { Name => 'Tuesday', Start => '07:30', End => '17:00' },
    3 => { Name => 'Wednesday', Start => '07:30', End => '17:00' },
    4 => { Name => 'Thursday', Start => '07:30', End => '17:00' },
    5 => { Name => 'Friday', Start => '07:30', End => '17:00' },
    6 => { Name => 'Saturday', Start => 'undef', End => 'undef' },
    holidays => [qw(2009-02-16 2009-03-23 2009-03-24 2009-03-25 2009-03-26 2

009-03-27)],
);

RT:Extension::SLA Config

%RT::ServiceAgreements = (
    Default => 'Service Impaired',
    Levels => {
        'System Inoperable' => { Response => { BusinessMinutes => 60*2 } },
        'Service Impaired' => { Response => { BusinessMinutes => 60*9 } },
        'General Inquiry' => { Response=> { BusinessMinutes => 60*27 } },
    },
);

When I create a ticket I now see a user defined field called SLA, however there is just one field called ‘No Value’ so I think I might have missed something.

2.) Custom reports, I would need to be able to generate reports using the SLA data to tell us if we are meeting our SLA, etc.

TIA,
Steve

As far as I recall SLA extension supports multiple business hours, so
you have to define:
%RT::ServiceBusinessHours = (
‘Default’ => {
… your description description …
},
);

Such config allow you to define multiple business hours sets.

Values of the SLA custom field is not synced automatically with values
in the config. It’s your job to add values via web UI → Configuration
→ Custom Fields → SLA.

As well you should grant rights on this CFs if you want people to be
able to change level of service (escalate).On Tue, Feb 17, 2009 at 8:23 PM, Steve O’Brien steve.obrien@hdesd.org wrote:

I am try to use RT to replace our current help desk system but have been
struggling with 2 points:

1.) We have an SLA with our customers and need to be able to incorporate
that into our ticket system. I have installed and begun configuring the SLA
extension but I am not really sure if it is set up correctly here is my
config:

Set Business Hours

%RT::ServiceBusinessHours = (

    0 => { Name => 'Sunday',Start => 'undef', End => 'undef' },

    1 => { Name => 'Monday', Start => '07:30', End => '17:00' },

    2 => { Name => 'Tuesday', Start => '07:30', End => '17:00' },

    3 => { Name => 'Wednesday', Start => '07:30', End => '17:00' },

    4 => { Name => 'Thursday', Start => '07:30', End => '17:00' },

    5 => { Name => 'Friday', Start => '07:30', End => '17:00' },

    6 => { Name => 'Saturday', Start => 'undef', End => 'undef' },

    holidays => [qw(2009-02-16 2009-03-23 2009-03-24 2009-03-25

2009-03-26 2

009-03-27)],

);

RT:Extension::SLA Config

%RT::ServiceAgreements = (

    Default => 'Service Impaired',

    Levels => {

        'System Inoperable' => { Response => { BusinessMinutes => 60*2 }

},

        'Service Impaired' => { Response => { BusinessMinutes => 60*9 }

},

        'General Inquiry' => { Response=> { BusinessMinutes => 60*27 }

},

    },

);

When I create a ticket I now see a user defined field called SLA, however
there is just one field called ‘No Value’ so I think I might have missed
something.

2.) Custom reports, I would need to be able to generate reports using the
SLA data to tell us if we are meeting our SLA, etc.

TIA,

Steve


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Steve O’Brien wrote:

I am try to use RT to replace our current help desk system but have
been struggling with 2 points:

Yep. Same here.

1.) We have an SLA with our customers and need to be able to incorporate that into our ticket system. I have installed and begun configuring the SLA extension but I am not really sure if it is set up correctly here is my config:

Set Business Hours

%RT::ServiceBusinessHours = (
    0 => { Name => 'Sunday',Start => 'undef', End => 'undef' },
    1 => { Name => 'Monday', Start => '07:30', End => '17:00' },
    2 => { Name => 'Tuesday', Start => '07:30', End => '17:00' },
    3 => { Name => 'Wednesday', Start => '07:30', End => '17:00' },
    4 => { Name => 'Thursday', Start => '07:30', End => '17:00' },
    5 => { Name => 'Friday', Start => '07:30', End => '17:00' },
    6 => { Name => 'Saturday', Start => 'undef', End => 'undef' },
    holidays => [qw(2009-02-16 2009-03-23 2009-03-24 2009-03-25 2009-03-26 2

009-03-27)],
);

For rt-3.8.x I believe that should now be expressed like so:

Set( %ServiceBusinessHours, (
0 => { Name => ‘Sunday’,Start => ‘undef’, End => ‘undef’ },
1 => { Name => ‘Monday’, Start => ‘07:30’, End => ‘17:00’ },
2 => { Name => ‘Tuesday’, Start => ‘07:30’, End => ‘17:00’ },
3 => { Name => ‘Wednesday’, Start => ‘07:30’, End => ‘17:00’ },
4 => { Name => ‘Thursday’, Start => ‘07:30’, End => ‘17:00’ },
5 => { Name => ‘Friday’, Start => ‘07:30’, End => ‘17:00’ },
6 => { Name => ‘Saturday’, Start => ‘undef’, End => ‘undef’ },
holidays => [qw(2009-02-16 2009-03-23 2009-03-24 2009-03-25 2009-03-26 2
009-03-27)],
)
);

RT:Extension::SLA Config

%RT::ServiceAgreements = (
    Default => 'Service Impaired',
    Levels => {
        'System Inoperable' => { Response => { BusinessMinutes => 60*2 } },
        'Service Impaired' => { Response => { BusinessMinutes => 60*9 } },
        'General Inquiry' => { Response=> { BusinessMinutes => 60*27 } },
    },
);

Similarly:

Set( %ServiceAgreements, (
Default => ‘Service Impaired’,
Levels => {
‘System Inoperable’ => { Response => { BusinessMinutes => 602 } },
‘Service Impaired’ => { Response => { BusinessMinutes => 60
9 } },
‘General Inquiry’ => { Response=> { BusinessMinutes => 60*27 } },
},
)
);

When I create a ticket I now see a user defined field called SLA,
however there is just one field called ‘No Value’ so I think I might
have missed something.

You just need to configure the SLA custom field in the usual way – as a
‘Select one value’ and then add your service levels as the list of available
options. Now when you go to set the SLA on a ticket it should automatically
set the ‘Starts’ and ‘Due’ dates on the ticket. You’ll need to set up rt-crontool
to run at regular intervals – given your ‘System Inoperable’ SLA is two hours,
you’ll probably need to run it more frequently than hourly. You may want to Google
for ways of supressing the rt-crontool transactions from ticket histories lest they
swamp all other transactions.

There’s one feature I’d love to have added to RT::Extension::SLA – setting
initial and final ticket priorities automatically – exactly as ‘Starts’ and ‘Due’
dates are set. One of these days I’ll have enough spare time to have a go at
coding that up.

2.) Custom reports, I would need to be able to generate reports using
the SLA data to tell us if we are meeting our SLA, etc.

It’s not particularly difficult to do a ticket search to find tickets resolved
after due date and with the SLA custom field set to some value. You can produce
pie and bar charts from the search results, or you can export them as .tsv files
and you can use a spread sheet to produce whatever analyses you desire.

Cheers,

Matthew

Dr Matthew Seaman The Bunker, Ash Radar Station
PGP: 0x60AE908C on servers Marshborough Rd
Tel: +44 1304 814890 Sandwich
Fax: +44 1304 814899 Kent, CT13 0PL, UK

signature.asc (259 Bytes)

[snip]

There’s one feature I’d love to have added to RT::Extension::SLA – setting
initial and final ticket priorities automatically – exactly as ‘Starts’ and
‘Due’
dates are set. One of these days I’ll have enough spare time to have a go
at
coding that up.

In 3.8 there is LinearEscalate action that can be used within crontool
to set priority according to Starts and Due dates. It even can be
configured via argument, for example it can be silent absolutely and
only update priority and don’t touch transactions and LastUpdated
field.

2.) Custom reports, I would need to be able to generate reports using
the SLA data to tell us if we are meeting our SLA, etc.

It’s not particularly difficult to do a ticket search to find tickets
resolved
after due date and with the SLA custom field set to some value. You can
produce
pie and bar charts from the search results, or you can export them as .tsv
files
and you can use a spread sheet to produce whatever analyses you desire.

To get regular reports you can use dashboards in RT 3.8 and get them
in email every morning or watch online.

   Cheers,

   Matthew

Best regards, Ruslan.

[snip]

You just need to configure the SLA custom field in the usual way – as a
‘Select one value’ and then add your service levels as the list of available
options. Now when you go to set the SLA on a ticket it should automatically
set the ‘Starts’ and ‘Due’ dates on the ticket. You’ll need to set up
rt-crontool
to run at regular intervals – given your ‘System Inoperable’ SLA is two
hours,
you’ll probably need to run it more frequently than hourly. You may want to
Google
for ways of supressing the rt-crontool transactions from ticket histories
lest they
swamp all other transactions.

Matthew,

I don’t understand why you’re suggesting crontool here, can you describe?

RT::Extension::SLA shipped with pretty good scrips that can be
disabled and re-enabled to turn off or turn back on some
functionality. For example it has scrip that sets default value of the
SLA according to the config. Starts/Due dates are set by another scrip
which doesn’t care when and by whom SLA CF has be changed. Such setup
allows you to disable assigning of default service level for tickets
and set them manually for every ticket (some companies may like it).

[snip]

Best regards, Ruslan.

Ruslan Zakirov wrote:

[snip]

You just need to configure the SLA custom field in the usual way – as a
‘Select one value’ and then add your service levels as the list of available
options. Now when you go to set the SLA on a ticket it should automatically
set the ‘Starts’ and ‘Due’ dates on the ticket. You’ll need to set up
rt-crontool
to run at regular intervals – given your ‘System Inoperable’ SLA is two
hours,
you’ll probably need to run it more frequently than hourly. You may want to
Google
for ways of supressing the rt-crontool transactions from ticket histories
lest they
swamp all other transactions.

Matthew,

I don’t understand why you’re suggesting crontool here, can you describe?

RT::Extension::SLA shipped with pretty good scrips that can be
disabled and re-enabled to turn off or turn back on some
functionality. For example it has scrip that sets default value of the
SLA according to the config. Starts/Due dates are set by another scrip
which doesn’t care when and by whom SLA CF has be changed. Such setup
allows you to disable assigning of default service level for tickets
and set them manually for every ticket (some companies may like it).

[snip]

Apologies. I’m too much in the thick of things right now that I’m losing
track of what is local customisation and what is add-on module and what is
core functionality. I guess we will be using the SLA stuff a bit differently
to how it was initially conceived.

We’re in the process of replacing an ancient and distinctly unsatisfactory
ticketing system with RT. What we’ve done is set up a ‘[_1] Highest Priority
Tickets in the Support Queue’ search portlet on the At-a-Glance screen for
our Support team, displayed in descending order of priority. There will be
an on-duty Support person 24x7 one of whose tasks will be to watch for incoming
support requests and assign SLA values according to the nature of the problem:
these can vary from ‘10 business days’ for routine things like renewing SSL certificates down to 1 hour for a ‘Service Down’ incident.

We also use a modification of the ‘StatusInColour’ customization from the
Wiki to colour the items based on the value of the priority field (Well, we
will be. I upgraded from 3.6.7 to 3.8.2 yesterday and haven’t quite got round
to porting that bit over yet. Tomorrow probably) The idea is: if it’s at the
top of the priority list, then that’s the next thing to work on, and if it’s
coloured bright red, it really needs attention right now.

This works by using rt-crontool with LinearEscalate to raise ticket priorities
as they get closer to their due dates. We’re running rt-crontool for the
Support queue every 15 minutes – however as all the tickets default to using
the Queue’s default initial and final priorities (0 and 99 respectively) it
means an urgent problem with a SLA of an hour only gets 3 or 4 updates before
it’s overdue, and it would only tend to come to the top of the list on the last
update. Hence the desire to automatically set initial and final priorities based
on the manually chosen SLA value.

Cheers,

Matthew

Dr Matthew Seaman The Bunker, Ash Radar Station
PGP: 0x60AE908C on servers Marshborough Rd
Tel: +44 1304 814890 Sandwich
Fax: +44 1304 814899 Kent, CT13 0PL, UK

signature.asc (259 Bytes)

Thanks Matthew!
I am still a bit foggy on how to use this module and what it really
does. I configured the custom fields with a sort value, name and
description (I did not know what to put for category).

Care to share your ColorMap config with the SLA priorities?

TIA,
SteveOn Tue, 2009-02-17 at 11:42 -0800, Matthew Seaman wrote:

Ruslan Zakirov wrote:

[snip]

You just need to configure the SLA custom field in the usual way – as a
‘Select one value’ and then add your service levels as the list of available
options. Now when you go to set the SLA on a ticket it should automatically
set the ‘Starts’ and ‘Due’ dates on the ticket. You’ll need to set up
rt-crontool
to run at regular intervals – given your ‘System Inoperable’ SLA is two
hours,
you’ll probably need to run it more frequently than hourly. You may want to
Google
for ways of supressing the rt-crontool transactions from ticket histories
lest they
swamp all other transactions.

Matthew,

I don’t understand why you’re suggesting crontool here, can you describe?

RT::Extension::SLA shipped with pretty good scrips that can be
disabled and re-enabled to turn off or turn back on some
functionality. For example it has scrip that sets default value of the
SLA according to the config. Starts/Due dates are set by another scrip
which doesn’t care when and by whom SLA CF has be changed. Such setup
allows you to disable assigning of default service level for tickets
and set them manually for every ticket (some companies may like it).

[snip]

Apologies. I’m too much in the thick of things right now that I’m losing
track of what is local customisation and what is add-on module and what is
core functionality. I guess we will be using the SLA stuff a bit differently
to how it was initially conceived.

We’re in the process of replacing an ancient and distinctly unsatisfactory
ticketing system with RT. What we’ve done is set up a ‘[_1] Highest Priority
Tickets in the Support Queue’ search portlet on the At-a-Glance screen for
our Support team, displayed in descending order of priority. There will be
an on-duty Support person 24x7 one of whose tasks will be to watch for incoming
support requests and assign SLA values according to the nature of the problem:
these can vary from ‘10 business days’ for routine things like renewing SSL certificates down to 1 hour for a ‘Service Down’ incident.

We also use a modification of the ‘StatusInColour’ customization from the
Wiki to colour the items based on the value of the priority field (Well, we
will be. I upgraded from 3.6.7 to 3.8.2 yesterday and haven’t quite got round
to porting that bit over yet. Tomorrow probably) The idea is: if it’s at the
top of the priority list, then that’s the next thing to work on, and if it’s
coloured bright red, it really needs attention right now.

This works by using rt-crontool with LinearEscalate to raise ticket priorities
as they get closer to their due dates. We’re running rt-crontool for the
Support queue every 15 minutes – however as all the tickets default to using
the Queue’s default initial and final priorities (0 and 99 respectively) it
means an urgent problem with a SLA of an hour only gets 3 or 4 updates before
it’s overdue, and it would only tend to come to the top of the list on the last
update. Hence the desire to automatically set initial and final priorities based
on the manually chosen SLA value.

Cheers,

Matthew

[snip]

Ruslan Zakirov wrote:
RT::Extension::SLA shipped with pretty good scrips that can be
disabled and re-enabled to turn off or turn back on some
functionality. For example it has scrip that sets default value of the
SLA according to the config. Starts/Due dates are set by another scrip
which doesn’t care when and by whom SLA CF has be changed. Such setup
allows you to disable assigning of default service level for tickets
and set them manually for every ticket (some companies may like it).
[snip]

Ruslan,
Are these scrips or how to use them documented anywhere?

Thanks,
Steve