Send Message Without conversation being set to "Waiting on Customer" state | Community
Skip to main content
Answered

Send Message Without conversation being set to "Waiting on Customer" state

  • January 12, 2026
  • 3 replies
  • 307 views
W

We are sending messages using Intercom’s REST API and after completing a task on our platform side, we would like to inform the customer that:

“The team will get back to you on this. Our usual reply time is 1 day. You'll get replies here and to [email protected].” (sent from William’s Admin ID)

However, this causes an unintended side-effect with our auto-assignment rules:

Because Intercom treats this as a teammate reply, when the auto-assignment occurs (balanced assignment). We auto-assign conversations based on “waiting longest”, so this causes these conversations to be de-prioritised and skipped, and they will only be picked up again if the customer replies.

As a workaround, we currently:

  • Do not send a message to the customer, and instead

  • Use the API to unassign the conversation and move it into a manually monitored inbox where it auto-assigned and picked up.

This avoids breaking the assignment logic, but it leaves the customer confused because they receive no acknowledgement that we are working on their request.

What we have tried:

We have tried sending it on behalf of Intercom’s bot (FIN) but this is confusing to the customer who receives a message first from a teammate (i.e. William), then from FIN, then from another teammate - a poor user experience.

What we would like to achieve is:

  • Send an acknowledgement to the customer, without making Intercom treat the conversation as “waiting on customer” or removing it from the assignment queue.

Do you have any recommendations on how to mitigate this, either:

  • via the Intercom API  or

  • via workflows?

Any guidance would be appreciated.


Kind regards,
William

Best answer by William Powell

Best Solution We Currently Have: Relay via an Automation Workflow triggered by unassignment

 

We “solved” this by combining a conversation unassignment with an Intercom Automation workflow that listens for a webhook  payload and relays the message to the customer — avoiding the waiting_since / admin_last_reply_at issue entirely. 

The problem recap: Any admin reply sent via the REST API sets waiting_since to null, which breaks balanced assignment. Bot replies don't deliver email notifications properly. There's no API option to send a customer-visible message without affecting conversation state.

How we got around it:

  1. Create an Automation workflow with the trigger "If teammate changes the conversation team assignment." Set the audience filter (i.e. Teammate assigned is None AND Team assigned is None) - this ensures it only fires on full unassignment, not normal reassignments.
  2. Add a "Wait for webhook" step as the first (and only) action in the workflow. Configure it to receive a message_to_send field, and use that field as the reply content to the customer.
  3. In your code, when you need to send a transfer/acknowledgment message:
    - Unassign the conversation (assignee_id: "0") — this triggers the workflow
    - Wait ~2 seconds for the workflow to start listening
    - POST to the workflow's webhook URL with {"data": {"message_to_send": "Your message here"}}
    - The workflow delivers it as a system/bot message that does not affect waiting_since
    - Then reassign to the target inbox

 

The message is sent by the workflow (not an admin reply), so it doesn't touch assignment state. The unassignment is temporary — you reassign to the target inbox immediately after. The ~2s delay is needed because the workflow needs time to activate and start listening for the webhook payload.

Caveats:

  - During the 2 second webhook wait, the composer does disappear to the customer - this is inconvenient but not as unusable as the webhook constantly listening.  
  - The timing is sensitive — if you send the webhook payload before the workflow is listening, the message won't be  delivered (non-blocking failure, customer just doesn't get notified)
 - If you do other Intercom actions (like tagging) between the unassignment and the webhook call, those events can cause the workflow to exit early — so the relay must happen first
  - Works across all channels (Web, iOS, Android, WhatsApp, Email)

It's a workaround rather than a proper API feature and we’d really appreciate a proper solution - i.e. sending a conversation using the REST API without resetting “waiting_since” / “admin_last_reply_at”.

3 replies

D
Intercom Team
Forum|alt.badge.img+5
  • Dara KIntercom Team
  • Intercom Team
  • January 30, 2026

Hey ​​​​​@William Powell. 

A direct admin reply via the REST API sets the conversation’s waiting_since to null (the user is no longer “waiting”), so Balanced assignment deprioritizes it when you sort by Waiting since. This is why these get skipped until the customer replies again.

To acknowledge customers without breaking assignment priority, send the acknowledgement as a bot/automation message via a Workflow. Bot replies do not affect Waiting since, so the conversation stays in the queue and remains eligible for auto‑assignment based on your prioritization rules.

  • Admin replies reset Waiting since (waiting_since becomes null), which means “the last reply is from a teammate (not waiting).” Those conversations are sorted last when your prioritization includes Waiting since, so Balanced assignment assigns others first.
  • By contrast, bot/automation replies do not change Waiting since, so the customer is still considered to be waiting for a teammate reply and the conversation remains high in the queue if you sort by Waiting since.

 

Ways to get around this:

1) Use Workflows to send the acknowledgement (recommended)

  • Send the acknowledgement as an automation/bot message from a Workflow, not as an admin reply. Bot replies don’t affect Waiting since, so the conversation stays prioritized for assignment as intended.
  • How to wire it up:
    • Trigger immediately when your platform signals “task complete.” You can do this by building a Workflow path that waits for your signal (e.g., a Wait for webhook step), then “Send a message” to the customer with your acknowledgement text. This produces a single bot message, avoids switching authors (no teammate → FIN → teammate), and preserves Waiting since.
    • Optional: Also “Mark conversation as Priority” in the same Workflow so these acknowledgements rise even higher if your Balanced assignment sorting puts Priority above Waiting since.

  • If you want a safety‑net instead of an immediate signal, you can use the “Prioritize conversations waiting for a teammate reply” template to automatically apologize and boost priority when a teammate hasn’t replied after X time (e.g., 1 day). This also sends an automated message and marks the conversation as Priority, improving assignment order without changing Waiting since.

  • Copy suggestion you can use in the Workflow’s “Send a message” step: “Thanks for your message — our team is on it. Our usual reply time is about 1 day. You’ll see our replies here and at your email on file.”

2) If you must send via the REST API

  • Be aware a teammate/admin reply will clear Waiting since and push the conversation to the back when you sort by Waiting since, that is expected system behaviour.
  • To mitigate the deprioritization:
    • Pair the admin reply with a Priority flag (via Workflow action or your process) and configure Balanced assignment so Priority is ranked ahead of Waiting since. Priority conversations are assigned first, regardless of Waiting since, which offsets the side‑effect of an admin reply.
W
  • William Powell
  • Author
  • New Participant
  • April 8, 2026

Hi ​@Dara K ,

Thank you very much for your thorough reply! I have since been on a mission to get this working robustly and have sadly failed. 

To formulate the core issue: it will not route / assign to agents following the transfer message and essentially show as replied to, not awaiting a reply.

1. WEBHOOKS
Whilst your “Wait for webhook step” does work, it unfortunately causes a side-effect: the chat composer (input for customers to type their message into) disappears when this workflow is triggered. 

Intercom support gave the explanation below:

Here's the sequence:

1. End user sends a message

2. Workflow processes and reaches the "Wait for webhook" workflow

3. The workflow pauses — it's waiting for the external bot to call back via the webhook URL

4. Because the active step is wait_for_callback (not expecting user input), the composer becomes disabled or hidden

5. The external bot processes and eventually calls the webhook URL with the message to send

6. Workflow receives the callback, processes it, and advances to the next step which sends the message to the customer

7. Composer reappears

According to our codebase, this waiting for callback step is set to disable the messenger composer because it is not expecting a response from the end user. The system intentionally suppresses the composer because typing during this phase would have no effect on the workflow.


2. PRIORITY FLAG
Unfortunately your other suggestion of sending conversations with a priority flag would cause issues where some customers conversations that did not have this flag would likely get de-prioritised and may even prevent a response. Given our numerous channels, it’s too much of a risk to take.


3. SENDING CONVERSATIONS WITH BOT ID
I have also tried sending conversations on behalf of Fin (using REST API with the bot admin id), these customer email replies were not delivered to customers emails, despite appearing as sent within Intercom. Intercom then confirmed that sending email replies via API from the bot teammate ID is not supported:

When this method is used, no email headers (To/From fields) are added. As a result, replies appear within Intercom but are not actually delivered to the customer.


Could you please look into a solution on Intercom’s side i.e. change to REST API or fixing the webhook composer issue? I have raised a ticket with intercom on the latter but it’s been over a month. This is rather crucial for customer experience and would appreciate help as soon as possible.

Kind regards,
William

W
  • William Powell
  • Author
  • New Participant
  • Answer
  • April 13, 2026

Best Solution We Currently Have: Relay via an Automation Workflow triggered by unassignment

 

We “solved” this by combining a conversation unassignment with an Intercom Automation workflow that listens for a webhook  payload and relays the message to the customer — avoiding the waiting_since / admin_last_reply_at issue entirely. 

The problem recap: Any admin reply sent via the REST API sets waiting_since to null, which breaks balanced assignment. Bot replies don't deliver email notifications properly. There's no API option to send a customer-visible message without affecting conversation state.

How we got around it:

  1. Create an Automation workflow with the trigger "If teammate changes the conversation team assignment." Set the audience filter (i.e. Teammate assigned is None AND Team assigned is None) - this ensures it only fires on full unassignment, not normal reassignments.
  2. Add a "Wait for webhook" step as the first (and only) action in the workflow. Configure it to receive a message_to_send field, and use that field as the reply content to the customer.
  3. In your code, when you need to send a transfer/acknowledgment message:
    - Unassign the conversation (assignee_id: "0") — this triggers the workflow
    - Wait ~2 seconds for the workflow to start listening
    - POST to the workflow's webhook URL with {"data": {"message_to_send": "Your message here"}}
    - The workflow delivers it as a system/bot message that does not affect waiting_since
    - Then reassign to the target inbox

 

The message is sent by the workflow (not an admin reply), so it doesn't touch assignment state. The unassignment is temporary — you reassign to the target inbox immediately after. The ~2s delay is needed because the workflow needs time to activate and start listening for the webhook payload.

Caveats:

  - During the 2 second webhook wait, the composer does disappear to the customer - this is inconvenient but not as unusable as the webhook constantly listening.  
  - The timing is sensitive — if you send the webhook payload before the workflow is listening, the message won't be  delivered (non-blocking failure, customer just doesn't get notified)
 - If you do other Intercom actions (like tagging) between the unassignment and the webhook call, those events can cause the workflow to exit early — so the relay must happen first
  - Works across all channels (Web, iOS, Android, WhatsApp, Email)

It's a workaround rather than a proper API feature and we’d really appreciate a proper solution - i.e. sending a conversation using the REST API without resetting “waiting_since” / “admin_last_reply_at”.

Terms & ConditionsAccessibility statement