Sending Request status updates
Notify Requesters about a status change and send a follow-up through linked Support conversations.
Written By Markus Palm
Last updated 37 minutes ago
Overview
Status updates tell customers what changed on a Request. After you change a status, you can follow up in one of three ways:
Default update: Sends the standard status notification to the Request's portal Requesters. It sends nothing to linked Support conversations
Drafted update: Sends your own message to the portal, to linked Support conversations, or to both
Internal note: Every status change adds an internal note to linked Support conversations. The note is for your team and is never a customer reply
Changing a status and messaging customers are separate actions. Review the follow-up options after each status change.
Change the status and choose a follow-up
Open the Request
Choose its new status
Open the follow-up control beside the status
Choose 'Send default update' or 'Draft update'
Use Configuring Request statuses to change the statuses available in your Workspace.
Send the default update
Choose 'Send default update' to send the standard status notification to the Request's portal Requesters without writing a message. It does not reply in linked Support conversations and does not change linked customer ticket statuses.
Note: If the Request is not available on your portal, for example because its category is private or the Request is hidden or held for review, the default update sends no customer message. Choose 'Draft update' and select Conversations to reply through Support instead.
Draft an update
Choose 'Draft update' to explain the change in your own words. State what changed and what the customer needs to know or do next.
In the dashboard composer, open the audience selector, which reads Select audience until you choose, and select the destinations:
Portal: Publish the update on the Request and email its portal Requesters
Conversations: Send a reply in the linked customer conversations
You can select both when both are available. If you draft the update from the customer-facing portal instead of the dashboard, it opens as a status-update comment on the Request, and the Conversations destination is available only in the dashboard composer. The same applies to a Macro that changes the status.
You can insert variables into the message. Customer variables use their fallback text in the portal version, because a public update has no single customer identity. Request and Workspace variables, such as the Request title, still resolve.
To send the update:
Review the message and the selected destinations
Check any conversation actions and customer ticket status changes
Click 'Send update'
Tip: Review the audience counts before sending. A person who is a Requester on the portal and has a linked conversation can be reached through both paths.
Follow up in linked Support conversations
Linked conversations hold the customer context behind the Request. Every status change adds an internal note there so your Support team can see the progress.
To message those customers, select Conversations in a drafted update. Review any additional conversation actions, such as closing or assigning conversations, before sending.
If linked customer tickets have suggested status changes, open Customer tickets in the composer. Check the proposed status for each ticket and choose No change where needed. These changes apply when you send the update.
Important: An internal note is not a customer reply. The customer hears from you only when you send an update with Conversations selected.
Check the result
Open the Request to check its published update, and open linked conversations to check the replies.
If part of the update fails, review the error before retrying. The open composer tracks the destinations it has already accepted, so you can retry the remaining part without sending twice.
Note: Audience counts describe the selected recipients. They are not email delivery confirmations.