We are looking into implementing RT for our organization. For this to
work we need to have SLA support. I found an extension for this and as I
understand it an SLA is assigned based on a queue. This behavior is
slightly confusing to me and I don’t see how this would work.
SLAs are linked to customers and when an employee from company X sends
us an e-mail (where company X has a Bronze SLA) we would like RT to
assign that particular SLA to the ticket. For this to work I think SLAs
need to be linked to requestors or maybe groups. We then link the
contact for that company to the group as requestors.
We are looking into implementing RT for our organization. For this
to work we need to have SLA support. I found an extension for this
and as I understand it an SLA is assigned based on a queue. This
behavior is slightly confusing to me and I don’t see how this would
work.
SLAs are linked to customers and when an employee from company X
sends us an e-mail (where company X has a Bronze SLA) we would like
RT to assign that particular SLA to the ticket. For this to work I
think SLAs need to be linked to requestors or maybe groups. We then
link the contact for that company to the group as requestors.
In this case, you have a Bronze queue that people email (that’s how we
do it).
However, I’ve implemented user specific overrides by creating a User
custom field and on ticket creation, if the user has the custom field
set, overriding the queue default SLA value. You could do similar things by
checking the requestor’s groups for CFs rather than checking the
Requestor for CFs.
Thank you for your reply. I am not very happy with a solution where
people should send e-mail to different addresses depending on which SLA
they have. I just want to have our regular support@… address and not
support-bronze@… for example. This is not very customer-friendly.
So, this means that I can live with a solution where we make a group for
a particular company and a custom field for the SLA of that company.
Then assign users to that group which are the people we communicate
with. When a ticket has been created from a requestor in that group it
must be assigned the correct SLA.
I am not really sure that the SLA plugin does exactly in RT as far as I
can tell it only assigned the correct due date depending on the SLA. Am
I correct in this? Does anybody have an idea how we could implement the
assignment of SLA based on a group and a custom field for that group?
Kind regards,
Hans Vos
Op 27-9-2012 17:43, Kevin Falcone schreef:> On Wed, Sep 26, 2012 at 04:49:43PM +0200, Hans Vos | Drecomm wrote:
We are looking into implementing RT for our organization. For this
to work we need to have SLA support. I found an extension for this
and as I understand it an SLA is assigned based on a queue. This
behavior is slightly confusing to me and I don’t see how this would
work.
SLAs are linked to customers and when an employee from company X
sends us an e-mail (where company X has a Bronze SLA) we would like
RT to assign that particular SLA to the ticket. For this to work I
think SLAs need to be linked to requestors or maybe groups. We then
link the contact for that company to the group as requestors.
In this case, you have a Bronze queue that people email (that’s how we
do it).
However, I’ve implemented user specific overrides by creating a User
custom field and on ticket creation, if the user has the custom field
set, overriding the queue default SLA value. You could do similar things by
checking the requestor’s groups for CFs rather than checking the
Requestor for CFs.
Thank you for your reply. I am not very happy with a solution where
people should send e-mail to different addresses depending on which
SLA they have. I just want to have our regular support@… address and
not support-bronze@… for example. This is not very customer-friendly.
So, this means that I can live with a solution where we make a group
for a particular company and a custom field for the SLA of that
company. Then assign users to that group which are the people we
communicate with. When a ticket has been created from a requestor in
that group it must be assigned the correct SLA.
I am not really sure that the SLA plugin does exactly in RT as far as
I can tell it only assigned the correct due date depending on the SLA.
Am I correct in this? Does anybody have an idea how we could implement
the assignment of SLA based on a group and a custom field for that group?
The way I want to tackle this problem is the use Assets. Define an
AssetType SLA and define a couple of SLA attributes such as how fast to
respond to which priority problem and couple that to a script. I need to
work this out but think it will give us a better SLA support then the
plugin currently can give us.
