Bots in charge of pre-qualifying your visitors' requests and transferring the conversation to a human respondent make up a large part of iAdvize's bot population. In the case of transfers to human respondents, these are important parts of iAdvize's engagement mechanics, where they occupy a particularly delicate position: your visitors have been engaged by your notifications, have already entered into a dialogue and are now waiting to speak to an agent. It is therefore crucial not to disappoint them!
1. A few reminders
-
if its scenario provides for a transfer to a routing rule, the bot’s availability depends on the Bot availability setting (Identity tab of the bot):
-
Available when at least one transfer is possible (default setting): the bot only shows up on your site and engages the conversation if at least one of its transfer rules has an available respondent or a free slot in its conversation queue;
-
Available when all transfers are possible: the bot only shows up if all its transfer rules meet this condition;
-
Always available: the bot shows up even if no transfer is possible.
-
with the default setting, if your bot is associated with multiple routing rules, it may continue to engage visitors as long as respondents are available for rule 1... even though the majority of visitors need respondents associated with rule 2 and will therefore be disappointed when their transfer fails!
2. Why do transfers fail?
Transfer failures (when a bot cannot route the conversation to a human respondent) are the main cause of visitor dissatisfaction. Here is why these failures can happen:
- In the case mentioned above, where a bot relies on 2 unequally available routing rules, visitors who have chatted with the bot and are sent to rule 2 may never be put in touch with their respondent, if the bot appeared to them thanks to the respondents of rule 1.
- If your settings allow it, a bot can also chat simultaneously with a very large number of people, even if few respondents are present for a transfer. The risk of failure is therefore high if your bot chats with 50 people, for example, but there are only 2 respondents behind the relevant routing rule.
- Even without this, by the time your bot has qualified the visitor's request, there may be no respondent available and no remaining slot in the conversation queue, which also makes the transfer fail.
3. Prevent failures
Several levers allow you to balance the hyper-availability of your bot with the actual availability of your teams, while ensuring a quality experience for your visitors:
-
moderate the scale of your bot: small team, small bot! If you don't have a large number of respondents, it's better to reduce the scale of your bot to reasonable proportions. For example, if you have a team of 15 agents, each capable of maintaining 2 simultaneous conversations, limit the simultaneous conversations of your bot to 10, and then increase it gradually if you don't see any failure errors.
-
associate a bot with a single routing rule: by simplifying the connection between bot and respondent as much as possible, you limit the risk of your bot appearing while all respondents associated with a rule are already busy!
-
use conversation queues to gain flexibility - even if you want to focus on live chat, adding a conversation queue, even one with just one slot, to your transfer's routing rule will allow the bot to “store” conversations rather than block them, until your respondents retrieve them within a reasonable time period!
-
balance your teams: your bot can of course redirect to multiple routing rules, which is especially useful in pre-qualification scenarios. In this case, make sure that the number and availability of respondents associated with each rule are roughly equivalent… but also that their schedules are similar.
- if your bot transfers to several routing rules, choose Available when all transfers are possible: the bot stops engaging visitors as soon as one of its rules can no longer receive a transfer.
-
“clone” your bots: if you get good results by associating a bot with a single routing rule, but for example you want to transfer your questions to respondents with different areas of expertise, you can certainly copy a bot that welcomes your visitors to a category on your site, then install its clone on another category of the site and associate it with another routing rule.
-
organize bot “shifts”: when your respondents are reaching the end of their day, they gradually become unavailable, but your bot can continue to engage as many people as possible… until there is no-one left, and its transfers fail! To prevent this situation, you can arrange a handover between two bots by adjusting your engagement rules by time of day and replacing your “day” bot with a smaller-scale “closing” bot for the last hour of your shift.
-
Switch between synchronous and asynchronous: you can favor live conversations by prioritizing transfers to available human respondents. But if none of them are available at that moment, as a second choice you can arrange a transfer to a bot associated with asynchronous routing rules, equipped with a conversation queue, and thus capture all conversation opportunities.
This bot can also explain the situation to your visitors with a sentence like “I'm sorry, all our agents are busy at the moment! One of them will be in touch as soon as possible, and if you tell us your email address, we can also get back to you automatically”. So your visitors will know exactly what to expect for the next stage of their conversation!
-
Never put a queue directly on a bot