I would like to ask for your support and ideas to help resolve an issue I have been facing for some time regarding our service SLAs.
We currently work with different SLAs depending on the type of request. In many cases, a ticket that starts as a general inquiry ends up becoming an error or incident, so I need to change the SLA to the one applied to errors, since it allows more time for resolution.
However, in the SLA configuration, I set the system to disregard the time when the ticket is snoozed or waiting for the customer. The issue arises at the moment I change the SLA to another one: the period that was previously disregarded while the ticket was paused is no longer excluded in the new SLA. Instead, the system starts counting from the original opening date without applying any discount for the paused time.
This has a direct impact on our reports, as it makes the SLA appear much more delayed than it actually is. It also reduces the available time to handle the ticket properly when the customer initially opens it under a different category.
If you have any ideas or suggestions on how to solve or at least minimize this issue, I would really appreciate it. I have already tried several approaches, but so far I have not been able to resolve it.
Thank you in advance for your support.
Best regards, Caroline Cardona
Best answer by Karla T
Hi @Caroline Cardona 👋🏽 Karla here from the Community team! 🙋🏽♀️ I hope all is well with you today! 😄
Thank you for explaining this so clearly. I completely understand how this would impact both your reporting accuracy and the time your team has available to resolve tickets properly.
What you’re seeing is expected behavior in Intercom when an SLA is changed on an existing ticket. When a new SLA overrides a previous one:
First and Next response timers restart from the most recent customer message.
Time to resolve and Time to close timers do not reset. Instead, they continue counting from the original ticket creation time.
Even if the ticket was previously paused, for example in “Waiting on customer” or Snoozed, applying a new SLA does not retroactively recalculate that historical timing. The resolution clock resumes based on the original anchor, which can make the ticket appear more delayed than expected after reclassification.
I understand how this can be frustrating, especially when a general inquiry later becomes an incident and needs a different SLA target.
Here are a few approaches that may help minimize the impact:
Apply a baseline resolution SLA from the start. If all new tickets begin with an SLA that includes Time to resolve or close, with pausing enabled, then overriding to a longer incident SLA later will extend the target without creating as much reporting distortion.
Create a new incident ticket when reclassifying. If you need a clean incident clock that excludes the earlier inquiry time, closing the original ticket and creating a new linked incident ticket ensures the SLA starts fresh.
Track incidents separately using a linked ticket approach. Some teams keep the original ticket for customer communication and create a linked internal or incident ticket with its own SLA. This keeps incident reporting clean while preserving the full customer timeline.
Adjust reporting logic where possible. Custom reporting can help account for time spent in “Waiting on customer” so dashboards better reflect effective handling time.
If you would like more hands-on support, just let me know and I can create a conversation with our team so they can review your setup directly and help you find the best solution.
I hope this helps clarify what is happening, and I’m happy to continue supporting you.
Hi @Caroline Cardona 👋🏽 Karla here from the Community team! 🙋🏽♀️ I hope all is well with you today! 😄
Thank you for explaining this so clearly. I completely understand how this would impact both your reporting accuracy and the time your team has available to resolve tickets properly.
What you’re seeing is expected behavior in Intercom when an SLA is changed on an existing ticket. When a new SLA overrides a previous one:
First and Next response timers restart from the most recent customer message.
Time to resolve and Time to close timers do not reset. Instead, they continue counting from the original ticket creation time.
Even if the ticket was previously paused, for example in “Waiting on customer” or Snoozed, applying a new SLA does not retroactively recalculate that historical timing. The resolution clock resumes based on the original anchor, which can make the ticket appear more delayed than expected after reclassification.
I understand how this can be frustrating, especially when a general inquiry later becomes an incident and needs a different SLA target.
Here are a few approaches that may help minimize the impact:
Apply a baseline resolution SLA from the start. If all new tickets begin with an SLA that includes Time to resolve or close, with pausing enabled, then overriding to a longer incident SLA later will extend the target without creating as much reporting distortion.
Create a new incident ticket when reclassifying. If you need a clean incident clock that excludes the earlier inquiry time, closing the original ticket and creating a new linked incident ticket ensures the SLA starts fresh.
Track incidents separately using a linked ticket approach. Some teams keep the original ticket for customer communication and create a linked internal or incident ticket with its own SLA. This keeps incident reporting clean while preserving the full customer timeline.
Adjust reporting logic where possible. Custom reporting can help account for time spent in “Waiting on customer” so dashboards better reflect effective handling time.
If you would like more hands-on support, just let me know and I can create a conversation with our team so they can review your setup directly and help you find the best solution.
I hope this helps clarify what is happening, and I’m happy to continue supporting you.
