Why does the first response time SLA start on a thread I created?

When a team member creates a thread and messages the customer first, the customer's reply still starts the first response time SLA if the thread has a first response time target. There is no setting that skips it only on threads your team starts. If your workspace uses SLA policies, you can get the same result by choosing which policy each thread is on.

Why this happens

Plain has no concept of a thread started by your team. The first response time SLA measures the time from thread creation to the first reply a team member 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

A team member 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 a team member replies again.

How to avoid it with SLA policies

SLA policies are available on the Horizon and Frontier plans. A thread has one SLA policy at a time, or none, and a thread with no policy has no SLA. A policy can contain any of the four SLA targets, so you can create one that leaves out first response time.

Create a policy with only a next response time target in Settings, under SLA policies. On a thread a team member creates, apply it from the SLA policy row in the thread sidebar, or press Cmd+K and choose Change SLA policy on thread. The customer's first reply then starts no timer, and next response time starts on their next message after your team has replied.
Remove the policy from the thread if you don't want any SLA targets tracked on it. See the next section.

Threads that customers open themselves keep the policy your workflows already give them, so SLAs work as usual there.

Turn off SLAs on a single thread

Removing the SLA policy from a thread turns off every SLA target on it. Any target still counting down is canceled, and the change is recorded on the thread's Timeline. Other threads are not affected.

Open the thread.
Click the SLA policy row in the thread sidebar and choose No SLA policy. Or press Cmd+K and search for Remove SLA policy from thread.

To bring SLAs back, pick a policy from the same row. The new policy's targets measure from the same point the old ones did, so a thread that has waited 3 hours already has 3 hours counted against it.

A workflow can do the same with the Set SLA policy action by picking no policy. If you use the API, pass a null SLA policy ID when you apply the policy to the thread.

Automating it

A workflow can apply or remove a policy with the Set SLA policy action. Workflows have no condition for who started a thread, so test any workflow on a few threads before relying on it. Setting the policy by hand when a team member creates a thread works reliably today. You can also set it through the API when your own integration creates the thread.

If you are still on tier SLAs

SLAs set on a tier cannot be removed from a single thread. Teams on tier SLAs usually filter proactive threads out of their first response time reporting manually, or move to SLA policies.