SLA do not work when ticket is created via email | Community
Skip to main content

SLA do not work when ticket is created via email

  • December 17, 2020
  • 14 replies
  • 0 views
O

We wanted our end users to open tickets by sending an email. Of course with an email the user does not have a "priority" field as exists in a form. The agent receiving this ticket would then define a priority, and the SLA policies will start to kick in.

When the SLA counter didn't work, I contacted support , and was very disappointed to hear that if an agent fills in the priority in the received ticket, the SLA will not work. For SLAs to work the user must fill the ticket priority which basically means this forces us to have our end users open tickets through a Zendesk form and leaves out the email option. I really wish Zendesk will change that , SLAs should work when an agent fills in the priority himself.

Has anyone encountered this problem as well?

 

    14 replies

    Jacob20
    • Jacob20
    • December 17, 2020

    Hi Ofer,
    There is a lot of flexibility available in regard to SLA's.
    In your case I would recommend having a trigger set a default priority at ticket creation.

    For example:
    Conditions (all)
    Ticket is created
    Priority is -

    Action:
    Priority is normal.

    You could add a channel condition as well if you only want this to apply for the email channel, but I would recommend it as is.

    I hope this helps.

    Jacob20
    • Jacob20
    • December 17, 2020

    ☝️ with this, SLA's should kick in from ticket creation.

    O
    • Ofer12
    • Author
    • December 17, 2020

    Thanks Jacob.

    So the trigger is:

    Condition: Ticker is created

    Action: Priority is normal

    This means that a ticket will always be created with Priority normal, and so the normal SLA counter will apply.

    But what if the issue for which the ticket has been created is of higher (or lower) severity?

    Jacob20
    • Jacob20
    • December 17, 2020

    With these two conditions

    • Ticket is created
    • Priority is -

    Any tickets that already have a priority set will not be changed. You could also start with something other than "Normal", of course, agents can always change the priority if they have more information.

    O
    • Ofer12
    • Author
    • December 17, 2020

    Hi Jacob, 

    I'm not sure I understand the comment "Any tickets that already have a priority set" will not be changed. I did a test and a ticket that opened with normal priority using the trigger I was able to change its priority to high.

    Can you clarify what you meant?

     

    Jacob20
    • Jacob20
    • December 17, 2020

    Hi Ofer,

    The trigger conditions (see below) will fire the action for all new tickets unless there already is a priority set.

    O
    • Ofer12
    • Author
    • December 17, 2020

    Hi Jacob, 

    I created per your recommendation ( see screenshot) and the tests were successful. 

    Thank you for your help.

    L
    • Lester13
    • December 20, 2020

    I'm creating a First Reply Time SLA and it appears to be firing on applicable tickets in the view, but I set the time to be 10mins, and it is showing on the view as 2 days from now. I'm new to here, can anybody give me some insight as to what's going wrong?? Thanks!

    Jacob20
    • Jacob20
    • December 23, 2020

    Hi @Lester Gaddy

    I suspect that what you're seeing is that you have defined your target in business hours, but the Next breach value is always displayed (as I recall) in calendar hours. 

    This article explains this better than I do here. Does that sound like what you're experiencing?

    H
    • Haaji
    • January 14, 2021

    Hi @jacob I'm not sure I understand the comment "Any tickets that already have a priority set" will not be changed. I did a test and a ticket that opened with normal priority using the trigger I was able to change its priority to high.

    Jacob20
    • Jacob20
    • January 14, 2021

    Hi 1261880649449

    That comment was explaining how this trigger works (at ticket creation):

    You can use the same condition (Priority is -) to have the trigger skip any tickets that already have a priority set. I hope that helps.

    J
    • Jonh
    • September 2, 2021

    I'm creating a First Reply Time SLA and it appears to be firing on applicable tickets in the view, but I set the time to be 10mins, and it is showing on the view as 2 days from now. I'm new to here, can anybody give me some insight as to what's going wrong?? Thanks!

    Cheeny
    • Cheeny
    • September 8, 2021

    Hi Jonh,

    The Zendesk first reply time metric measures the time between ticket creation and the first public agent comment after that.

    After the first public reply, Support calculates the first reply time in calendar hours and business hours. Both metrics are stored with the ticket data, so you can use either (or both) to build reports.

    First reply time works the same regardless of the channel from which the ticket originates. For example:

    1.A customer email creates a ticket. Timing starts when the ticket is created and ends at the first public agent comment.
    2. An agent creates a ticket. Timing starts when the ticket is created and ends at the agent's next public comment.
    3. An agent takes a phone call that creates a ticket and solves the ticket with no new comment. The customer later re-opens the ticket, and the agent then responds with a public comment. First reply time ends when that comment is posted.
    4. When an agent adds a public comment from another account using ticket sharing, this does not count toward your account's first reply time.

    To know more about ticket reply time, you may check Understanding ticket reply time and When is first reply time recorded in reporting?

     

    T

    I'm creating a First Reply Time SLA and it appears to be firing on applicable tickets in the view, but I set the time to be 10mins, and it is showing on the view as 2 days from now. I'm new to here, can anybody give me some insight as to what's going wrong?? Thanks!

    Terms & ConditionsCookie settingsAccessibility statement