Why does the first response time SLA start on a thread I created?
When a support agent creates a thread and messages the customer first, Plain still starts the first response time SLA clock when the customer replies. The agent's original message does not count as the first response, and the SLA does not switch to next response time instead.
Why this happens
Plain has no concept of a support-initiated thread. The first response time SLA measures the time from thread creation to the first reply a human agent sends after a customer message. A message sent before the customer has written in does not qualify, and neither does a reply from a machine user. So once the customer replies, the thread behaves like any new inbound thread and the clock starts.
What you will see
- An agent creates a thread and messages or CCs the customer.
- The customer replies.
- The first response time SLA starts, and the thread stays in Needs first response until the agent replies again.
No workaround
There is no setting to mark a thread as support-initiated or to skip first response time tracking on it. You also cannot disable SLAs on individual threads. Teams affected by this usually filter proactive threads out of their first response time reporting manually, or accept the skew.