SLA Placeholder
We need to have a placeholder with the SLA date, it is very important for personalized emails to the customer, today we only get a placeholder for the task date, but it is not functional, due to the amount of tickets generated
-
Thanks for the suggestion Bruno! Can you explain a little more about what you're trying to do here?
-
Scoot, of course.
Today we have the need to send various ticket information to our customers, and third parties, to facilitate the understanding of the service that will be performed, we created a trigger that sends a standardized email of this information, and the information we need is the expiration date of the ticket SLA, and today there is only one placeholder in the system, which would bring this information, if the ticket was a task and the due date field, but it is a process that needs to be done manually, and we have a demand of more than 100 tickets per day, moreover, this information is already available in the ticket itself, and what I want would be a placeholder with this information.
-
Good day!
I am also keen on this enhancement. For the same reason as Bruno - keeping the interested party up to date (via emails) and at the same time set expectations on tickets resolution time.
-
Thank you for your feedback on this idea. We don't currently have anything planned to address this in the roadmap but we continually reevaluate based on priorities and resources. We do have some big enhancements planned though for SLAs starting with Group SLAs planned for Q3. This will allow you to apply targets internally for teams. Useful to keep everyone aligned when tickets are reassigned to different groups as part of the ticket workflow.
-
+1 on this idea. It would be interesting to have a placeholder object with properties related to SLA events and SLA targets.
Imagining that if applied, one could obtain the currently applied SLA Policy and its Targets, each with attributes like name, ID, created_at, updated_at, breach_at.
We could from those provide periodic updates setting user expectations.The alternative right now would imply having an external service being called by an automation, retrieving the ticket info, parsing it, and calling the API to update the ticket with info to notify them.
I'd be happy with a simpler version of this, to give us callable placholder to highlight breached vs non-breached, or breached_in brackets (default intervals), conditioning the language used for those notifications.
-
Scott, the issue at this point is that I need this improvement for my end user, I understand that product evolution is always necessary, but they are targeting their user a lot, and not the end user within this process, which would be the customer of their customers.
Please sign in to leave a comment.
6 Comments