Bot availability

1. At the level of the Bot's commitment (following a notification)

The availability check for a Bot that needs to start a conversation will look to see if at least one of the transfers it will have to make during the scenario is available.

  • Case 1: the scenario only contains transfers to synchronous routing rules

At least one of the transfers to one of the routing rules must be with availability.

  • Case 2: The scenario contains only transfers to asynchronous routing rules.

The availability of an asynchronous rule is based on the threshold, and not on the availability of an agent, so the bot will not be available as soon as all the rules have reached their maximum conversations threshold.

  • Case 3: the scenario contains a mix of synchronous and asynchronous rules

At least one of the transfers to one of the routing rules must have availability, so in this case, the availability will be calculated both by taking into account the number of available agents and the maximum conversation queuing thresholds.

 

⚠️ It is not recommended to add two bots to the same distribution group. Otherwise, they will no longer be proactive.

Similarly, it is not recommended to add a second distribution group in a distribution rule that contains a bot. Otherwise, the bot will no longer be proactive.

 

NB: For a bot to be proactive, there must be:
- Only one bot per language in the routing rule
(the bots will always be proactive if there is an EN bot and an FR bot).
- At least one multiple choice question or open-ended question anywhere in the bot scenario
A bot available for third-party channels cannot start a conversation in proactive mode.


2. At the level of transfers during a Bot scenario

  • Case 1: transfer to a synchronous routing rule

The availability check for a Bot that has to transfer to a synchronous routing rule, will try for 30s to get an agent availability by default. If no availability is detected after the 30s, a check of the availability of the alternate path is made, if it is configured, otherwise the transfer fails.

  • Case 2: transfer to an asynchronous routing rule

The availability check for a bot that has to transfer to an asynchronous routing rule, will try for 30s by default to get an available agent or a spot in the waiting queue of the routing rule. If no availability is detected after the 30s, a check of the availability of the alternate path is made, if it is configured, otherwise the transfer fails.


You can configure the delay of the availability check in the bot identity section.

transfer_time_EN.png

3. End of conversations

The bot will automatically close the conversation after 5 minutes of inactivity (no response from the visitor) for the chat channel and for third-party channels this time limit is 30 minutes.


For more information about the bot :
- Steps to launch your bot

- Bot builder