Contact usRequest a demo

Broadcasts

This is a preview feature. It may be subject to change or removal with no further notice.

To enable preview features, set com.unblu.platform.enablePreview to true.

For more information on preview features, refer to the Unblu release policy.

While each customer relationship is unique, there are occasions where your employees will want to send the same chat message to a large number of recipients. Information about a period of absence, for example, or a new product needn’t always be tailored individually.

Broadcasts are a convenient way for agents to send the same message to multiple recipients. The recipients needn’t be participants in the same conversation. They also aren’t informed that the same message was sent to other people.

Types of broadcast

Agents can select who should receive a broadcast in one of two ways:

  • For customer broadcasts, the agent selects the recipients of the broadcast from the customer view. Unblu creates a new conversation with each customer and sends the broadcast message to each of those conversations.

  • For conversation broadcasts, the agent selects the conversations that the message should be broadcast to from their inbox. Unblu sends the message of the broadcast to each of the selected conversations.

Configuration

To configure broadcasts for your organization’s needs, review the following configuration properties:

There are three different timeouts and one sleep time related to broadcasts:

  • com.unblu.broadcast.deliveryTotalTimeout limits the time it takes to complete the entire broadcast.

  • com.unblu.broadcast.deliveryBatchTimeout limits the time it takes to complete a single delivery.

    The countdown starts as soon as Unblu takes the first step to execute the delivery. For conversation broadcasts, this includes creating the conversation.

  • com.unblu.broadcast.conversationCreationReadyTimeout limits the time it may take to prepare a new conversation for the delivery of a customer broadcast. This process includes creating the conversation, setting its state to ACTIVE, and adding the agent to the conversation session as a participant.

    The time to prepare a new conversation is also taken into account by com.unblu.broadcast.deliveryBatchTimeout. You could say that for customer broadcasts, conversationCreationReadyTimeout is part of deliveryBatchTimeout.

  • Lastly, com.unblu.broadcast.broadcastDeliverySleepTime specifies how long Unblu should wait after completing a delivery before it starts a new delivery. This ensures the conversation session has ended before Unblu starts the next one.

Conversation templates for customer broadcasts

For customer broadcasts, you must specify which conversation templates the agent can select from in the configuration property com.unblu.conversation.template.newPersonBroadcastConversationTemplateIds.

You can only add conversation templates with com.unblu.conversation.outbound.enableOutboundConversation set to true.

Furthermore, the templates mustn’t use any external messenger channels, that is, com.unblu.conversation.outbound.outboundChannel must be empty.

Make sure that agent onboarding is NOT enabled in the conversation template used for customer broadcasts. When the agent starts the broadcast, they don’t go through the agent onboarding process, so all the deliveries time out.

You should also enable the agent roles in com.unblu.conversation.message.chatMessageAsMarkdownEnabled. This determines whether broadcast messages are formatted using Markdown. For more information, see below.

Creating broadcasts

For information on creating broadcasts, refer to Customer broadcast and Conversation broadcast in the Agent Desk guide.

Limitations

At present, broadcasts are first and foremost a convenience feature for agents. They’re meant for situations where an agent wants to send multiple clients the same targeted message. They aren’t intended for marketing campaigns where your organization reaches out to a large number of customers with an impersonal message.

Because of their intended purpose, broadcasts have several limitations:

  • The number of recipients of a broadcast is limited to 200.

  • Broadcasts aren’t persisted in any way. This has two important consequences:

    • Broadcasts only exist in the context of an agent’s session in the Agent Desk. The broadcast no longer exists once the agent’s session ends. As a result, agents can’t prepare a broadcast to be sent at a later date, for example.

    • There’s no history of previous broadcasts, nor is there a straightforward way of finding out who received a broadcast after it’s been delivered.

  • Broadcasts are only available in the Agent Desk. It isn’t possible to initiate broadcasts with the Unblu web API.

  • For customer broadcasts that time out, there’s no dedicated mechanism in place to clean up unused conversations.

  • The broadcast forms where users craft messages always use the WYSIWYG editor, which produces Markdown. If com.unblu.conversation.message.chatMessageAsMarkdownEnabled doesn’t include the role of the agent sending the message, the message is converted to plain text, characters used for Markdown formatting appearing as is, for example, *italic* rather than italic.

See also