[rt-users] RT::Extension::SLA Question

[Matthew Seaman]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20090217/75aedc53/attachment.sig>