Visit Freshworks.com Visit Freshworks
Question

Response due not needed for Agent opened tickets

  • 12 July 2023
  • 6 replies
  • 41 views
S
Rank
Userlevel 4
Badge +10

I have looked through the Community and haven’t found answers on this yet.

 

Has anyone created a rule/process where if the ticket is opened by an Agent, the response SLA is met?  Basically, if my IT staff opens the tickets via a phone call, then the ticket still requires a response via email or public note.  That seems redundant since they talked to the customer to open the ticket.  

 

Thoughts?

6 replies

J
Rank
Badge +1

Would be nice, I do the same thing here. I have a custom field in my ticket creation that’s a checkbox for “Agent Created Ticket” that I check when creating a phoned in ticket while I’m talking to the user. Would be nice that if that’s checked I could set the response need to be skipped. I could use that to set the trigger for bypassing the response in the SLAs.

Leighanne
Rank
Badge +2

I would like to know the same.

I would really like both the response time to be ‘reached’ when an agent adds any note to a ticket and for agents claiming a ticket in the system to not receive an email that the ticket was assigned to them -- of course they know it was assigned to them, they did the action. :) 

eeha0120
Rank
Userlevel 6
Badge +11

I have looked through the Community and haven’t found answers on this yet.

 

Has anyone created a rule/process where if the ticket is opened by an Agent, the response SLA is met?  Basically, if my IT staff opens the tickets via a phone call, then the ticket still requires a response via email or public note.  That seems redundant since they talked to the customer to open the ticket.  

 

Thoughts?

Hi Shannon.

This two-stages approach may be helpful:

  1. Create a workflow when the ticket is raised to have a variable set when the creator is the Agent:

     

  2. Create a SLA Policy that checks for that variable and value, and if true/enabled/set, use this SLA policy, in which Response Due is the highest possible value:

 

Regards,

Elvis Henriquez
eeha0120
Rank
Userlevel 6
Badge +11

Would be nice, I do the same thing here. I have a custom field in my ticket creation that’s a checkbox for “Agent Created Ticket” that I check when creating a phoned in ticket while I’m talking to the user. Would be nice that if that’s checked I could set the response need to be skipped. I could use that to set the trigger for bypassing the response in the SLAs.

Hi. You have gone half way with the proposed approach I have just given. You could give a try to the step 2 of it.

 

Sincerely,

Elvis Henriquez
eeha0120
Rank
Userlevel 6
Badge +11

I would like to know the same.

I would really like both the response time to be ‘reached’ when an agent adds any note to a ticket and for agents claiming a ticket in the system to not receive an email that the ticket was assigned to them -- of course they know it was assigned to them, they did the action. :) 

Hi. I’m not sure to follow on this. Would you please elaborate your cases (I think there are two cases in your statement)?

 

Cheers.

Elvis Henriquez
S
Rank
Userlevel 4
Badge +10

I have looked through the Community and haven’t found answers on this yet.

 

Has anyone created a rule/process where if the ticket is opened by an Agent, the response SLA is met?  Basically, if my IT staff opens the tickets via a phone call, then the ticket still requires a response via email or public note.  That seems redundant since they talked to the customer to open the ticket.  

 

Thoughts?

Hi Shannon.

This two-stages approach may be helpful:

  1. Create a workflow when the ticket is raised to have a variable set when the creator is the Agent:

     

  2. Create a SLA Policy that checks for that variable and value, and if true/enabled/set, use this SLA policy, in which Response Due is the highest possible value:

 

Regards,

If the response due is the longest needed, won’t it still show a response due?  it won’t go late, but the response due will still be there, right?

Reply


Terms of UseCookie settings