SLA Placeholder

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.

@scott17

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.

+1, to this request. It's helpful to have SLA information available as a placeholder so we can include the information in notifications to our agents, whether it's through e-mail/Slack/etc.

Thank you everyone for continuing to share your needs for this. Unfortunately, this is not on our roadmap for this year, so I will leave the status as Not Planned for now.

It's possible we'll prioritize this in the future, as it's really all down to customer demand. But the good news is this year we've prioritized a number of significant investments in SLAs. Next month we're launching Group SLAs at Relate, and then later the ability to apply SLAs to more interactions, with new SLA target types, and the ability to customize existing ones.

Thanks again for your continued feedback, it's really appreciated.

+1 Need to let clients know how long is left in the SLA.

+1  - We have multiple schedules and SLAs for customers on different support packages in different timezones. When they raise a ticket, I want to be able to include in the auto reply when they can expect a response by, taking into account holidays etc. The 'Next SLA Breach' datetime is already available as a datapoint in the ticket, we just need a way to add this as a variable into our trigger

+1 We are sending reminder notifications to groups stating a ticket has until xx amount of time until SLA breach. It would be helpful to have a placeholder with the actual time as automations do not fire the same time so it can be off

We need this to be able to include the SLA in automated responses.
That way we can inform the end-user the expected wait time on each interaction.

This is already doable using a third party API call to zendesk, so there should be no technical limitation to implement it as an internal feature.

+1 - Hello we need this to be able to include the SLA in automated responses.

We have an integration that needs to bring this information for better monitoring.

Thks.

+1 one for needing it internally. We have Slack notifications that are pushed if an SLA is nearing breach at certain intervals of 3 and 2 hours left. That's great, but the notification isn't accurate because there isn't a way to input a placeholder to display what the actual SLA breach date/time is. 

+1 , having the teams being notified of the ticket creation and it's SLA is something very useful. Hope this function is added soon!

+1 to everything everyone stated. This limitation will continue to be a hurdle for us, as we need the ability to dynamically communicate established SLAs to end-users. Having to rely on workaround methods is inefficient and reduces the overall value of the SLA feature. Enabling access to SLA policies within triggers, as well as introducing placeholders for SLA values (similar to other placeholders), would greatly enhance the usefulness of this feature and allow us to provide accurate, dynamic information to end-users.