Conversations | Transfers
This article applies to version 4.7.8 and higher.
Please refer to Glossary or Data Protection Guide for definitions of users and roles.
The article Conversations | Visitor journey contains related information about handling conversations.
Two cases for conversation transfers
1/ Transfer of an ongoing conversation, initiated by the member
During a conversation between a member and a visitor, the member might want to transfer the conversation to another member.
The possible reasons for this transfer are :
needing to be handled by customer service because the member does not have access to certain information, such as order tracking,
transfer to another member, because the member will no longer be available (e.g.: new customers arriving in the shop, end of working day, etc.),
need to transfer to another member for a specific expertise on a subject.
When a member transfers a conversation, and if the visitor accepts, a new conversation request is created in the Waiting List, with additional information (reason, conversation history …).
2/ Transfer of a direct conversation that has not been handled by the member
When a visitor clicks to chat with a specific member of his/her choice, the member might be absent or occupied, and he is not going to respond quickly to the message.
In that case, the customer will be invited to request a conversation with another member.
Conversation transfer processes
Case 1 : Transfert triggered by the member
Process
The member can click at any time on the action menu of the conversation, and select the option “Transfer the conversation”. It then displays a popup window to get required information.
Required information
Purpose of the transfer(drop down list). Elements displayed in this list are the existing Topics as configured specifically for the brand. Examples:Order follow-up
Product Advice
Specific expertise
Comments: The member can leave a short description explaining why he needs to transfer the conversation to another Member
Depending on the Topic selected (purpose of the transfer), a restriction may be applied in the Waiting, so that only specific Members can handle it.
[Feature available on 4.7.8]
Information displayed in the Waiting List
Topic(as selected by the Member who initiated the transfer)Content(text only):
“Conversation transfered by” [Member name] “at” [Date/time]
[Comment of the Member]
“Conversation history:”
[History of the conversation : user/time/message appended]
Note : in future versions, a summary of the conversation (made by a Generative IA) could also be appended to the Content.
Client side behaviour
When a Member transfers the conversation, an automatic message is displayed:
“Do you agree that this conversation be transferred to another member?”Two buttons are displayed [No] [Yes]
“No” → nothing happens and the visitor remains in the current conversation
“Yes” → the current conversation is replaced by the window with the usual waiting message.
The first conversation will still be available in the conversation history of the visitor, and can be resumed at any time.
Case 2 : Transfer triggered by the visitor (conversation not handled)
Process
Please refer to Conversations | Handling availability, absences and unanswered requests
Under certain conditions, an absence message is displayed:
The conditions and rules for displaying this message need to be reviewed
When the message is displayed, the Call To Action button invites the visitor to contact a member through the Waiting List. Clicking on the button will automaticaly create a new request in the Waiting list, with specific informations.
Information displayed in the Waiting List
Topic: if the previous conversation had a Topic, it is kept.
Content:
“New request created by the visitor because “ [Member name] “ was not available to handle the conversation quickly.”
Sales attribution
No changes in version 4.7.8. The order is assigned to the last Member who made had an active dialogue prior to the order.
Please refer to Conversations | Tracking and attribution rules
It is not possible to split the attribution of an order between two members, as the data model does not allow this.
We recommend to implement the changes described above for the transfer of a conversation initiated by a member (Case 1). Depending on the number of transfers actually carried out, if this number is significant, we could then consider the following allocation rule:
if the last established dialogue prior to the order was held by a member whose role is “Manager” and another dialogue was established beforehand (but still within the required deadline), then the order is attributed to the previous member.
Note: This rule will also apply if the visitor switches by himself to another conversation, e.g. by moving to the home page, and clicking to re-create a new conversation request in the waiting list.