Automatic Customer reminders

[Jeremy Wood]

Hello,

I know this question has been asked before but I'm struggling to find any answers that fit my needs. I am looking for a way to send customers a reminder when their ticket is in status "Waiting for customer" for 1, 2, and 3 business days. On day 4, i want the ticket to close automatically. 

I have tried to build out separate automations for each day but the problem is that i am sending the reminder by adding comments, that way the reminder shows up in the ticket logs. Each comment counts as an update to the ticket. So on day 1 when it adds the first comment it reset the timer, and then day 2 automation wont trigger until 2 days after that (day 3) and this repeats for each automation making it day 1, 3, 6, and 10 before the ticket closes. 

I could just send the e-mail via automations but then it doesn't show up on the ticket logs and users try to pull the "I didn't get a notice" card. I want to avoid that if possible. 

I've seen some recommendations around setting an SLA and then triggering when the SLA breaches but i worry this would skew SLA reports and show a bunch of violations caused by users not responding instead of showing tickets that actually need addressed by the team. 

I've also seen the recommendation of creating three different status's and moving it from one to the next at each stage. This could work but just feels really clunky and adds extra work to update filters and dashboards to now account for the extra status's. 

Are these the only options or is there a better way I'm missing? Or are there ways to address my concerns with the ways suggested? 

[Arkadiusz Wroblewski]

Hello @Alan Bruce 

Atlassian have official KB Article about that.

Please take a look Here 🤠😉

https://support.atlassian.com/jira/kb/implement-automated-issue-inactivity-follow-ups-and-closure-in-jira-service-management-cloud/

[Jeremy Wood]

Reading through this KB, i can understand the concepts but I'm confused by the specific automations they recommend. 

For their IF statements they use the below smart value. But wouldn't this value be true every single Wednesday, Thursday, and Friday? 

Condition: {{smart values}} condition: {{#=}}{{now.diff(now.minusDays(3)).businessDays.abs.gte(3)}}{{/}} equals 1

[Arkadiusz Wroblewski]

@Jeremy Wood 

This rule is more complex than only that. Read entire, then you will probably understand context.

[Trudy Claspill]

Hello @Jeremy Wood 

I wonder if there is something missing from your scenario description.

Your first paragraph talks about activity based on how long the item has been in the Waiting for Customer status. But then the rules are based on Last Updated.

Is there something that the customer can do that causes the status to change?

Assuming there is, here is another option.

Have a custom date field that is set to now by the transition to the Waiting for Customer status.

In every transition to any other status, clear that same field.

Create an automation that runs daily and selects issues based on JQL:

{your custom date field} is not empty

In the automation create a variable to get the days difference between the current date and that date field.

Create an IF/ELSE block:

If {your date difference variable} is greater than or equal to 4

Then Transition Work Item to your "closed" staus

Else If {your date difference variable} is greater than 0 and less than or equal to 3

Then Comment on Work Item with comment to remind the user to respond

Else

Do nothing

[Jeremy Wood]

You are correct, a customer adding a comment will transition the ticket. 

It sounds like creating a custom field is the way to go for what I'm trying to do. 

Is there a way to create a custom field for this automation, but not actually have it show on the ticket? Our tickets already feel overloaded with custom fields that I'm trying to clean up so ideally i would like to have this data saves and viewable from a filter and automations but not be visible on the ticket itself. Is that possible? 

[Arkadiusz Wroblewski]

@Jeremy Wood 

If the field is only there for automation or filtering, you can keep it off the customer request form and also hide it from the work item view. In Jira Cloud, the work item layout has a Hidden fields section for exactly that, and in JSM request types you can also preset a field and hide it from the portal if needed.

It will store information, even hidden.

[Alan Bruce]

1st automation:

• I send daily reminders when the status = "Waiting for customer" 

2nd Automation: Else-If

• IF -> For Incidents:  Status = 'Resolved' or 'Waiting for Customer' and the initiator is the Work item Reporter -> change the status to 'Customer responded' 
• ELSE -> For Requests: Status = "Waiting for Customer" AND Initiator is Work Item Reporter - -> Change status to "Waiting for Support"

3rd Automation - Closing ticket due to No customer response

• Scheduled Trigger w/JQL condition -> status ="Waiting for customer" and !(status changed after -14d)
  • Send email to Reporter letting them know the ticket is closing
  • Add Internal Comment -> 

    Email sent to 'Reporter':

    {{issue.key}} will now be closed due to no response for the last 10 business days. Closed issues/requests can not be re-opened. A new issue/request will need to be submitted if this is still needed.

    Thank you,
    The Helpdesk

  • Transition ticket to 'Closed'

Maybe that will help you out.

[Carla Ann Rowland]

write a scheduled filter to check once a day filter against timeinstatus = timelapsed() and when that time lapse = 4 days close the ticket. The automation rule need a create a comment on issue step when the e-mail is sent out.

[Jeremy Wood]

Based on the feedback from others i assume you are using a custom field for status changed date that gets set when the ticket is moved to "Waiting for customer". Is that correct? 

Or do you have some other way of lookup up when the status changed? 

[Gunjan Kumar]

Hi @Jeremy Wood 

In Jira Service Management, the issue is that adding a comment counts as an update, which resets any “time in status” automation. That’s why the reminders end up drifting.

A simpler and more reliable way to handle this is to track when the ticket first enters Waiting for customer.

You can do this by creating a custom date field (for example, “Waiting since”) and setting it when the ticket moves into that status. Then clear it when the ticket moves out of that status.

From there, use a single scheduled automation (run daily) to check how many days have passed:

• After 1-3 days -> add a reminder comment
• After 4 days -> automatically close the ticket

This approach avoids the reset issue, keeps all reminders visible in the ticket history, and doesn’t require adding extra statuses or impacting your SLA reporting.