Additional Resources Agent Efficiency Solutions

Abusive Consumers

Business Requirements

The brand wants to block abusive customers by leveraging Routing rules and Bot
Channels - Web Messaging
The approach is to identify a client for unauthenticated web messaging by one of the available fields and by customer Id for Authenticated Web Messaging, ABC, WA, SMS etc, and ban them. :

java:

         "userAgentDetails": {
               "type": "Browser",
               "family": "CHROME",
               "name": "Chrome",
               "version": "108.0.0.0",
               "icon": "chrome.png"
           },
           "ipv4": "23145",
           "geo": {
               "country": "Ukraine",
               "countryCode": "UA",
               "state": "Cherkas'ka Oblast'",
               "city": "Cherkasy",
               "isp": "LLC McLaut-Invest",
               "org": "LLC McLaut-Invest",
               "zipCode": "18000"
           },
           "deviceOS": "MAC_OSX"
           "deviceFamily": "DESKTOP"

The optional path is implementing bot or agent flow that includes questions to provide your name, email, phone number
- Bocker BOT needs to be assigned a separate dedicated skill “banned-users” skill Where Agents can transfer manually to this skill and Blocker BOT picks up the conversation
- Bot marks the user as an Abusive user with a time stamp into Conversation Context Service
  - unauthenticated - based on the IP address
  - auth - customerId
- Bot closes conversation without sending PCS
  Note: For the unAuth Web the IP address of the user and for ABC and GBM the consumer id will be used to identify the user
Add Agent Assist to identify bad intent from consumer language and alert/advise the agent to transfer this conversation

Router BOT is in front of all conversations and the below flow triggers when and if the conversation escalates to live Agent and users start using Abusive language, etc

Router bot

User Starts the conversation with the Router Bot
Bot will collect Session Id and Visitor ID and will set them to Context warehouse
The bot will Make an API request to ASK MAVEN for the next action
Orchestrator will evaluate rules and will return the next skill, if the next skill is not “banned-user”, bot will work with the conversation.

UnAuth Web User Flow:

The user starts an Abusive conversation with the Agent
Agents transfer the Conversation to the “banned-user“and then the “Blocker BOT” picks up the conversation.
Note: The “Blocker BOT” is a Bot where the blocking/banning of the user logic will be present
The “Blocker BOT” calls the Visit API to get the user's IP Address
The “Blocker BOT” calls the Context Service API to store this user(IP address) in the “Banned Users” Namespace
- This user(IPAddress) that is stored in the context service has an expiration date. The user(IP Address) will be deleted after 30 days.
Then Conversation will be closed without sending the PCS
If the same user from the same IP address initiates the conversation again, the Router bot will identify the User’s IP by checking the Context service repository and transfer the conversation to the “returned-banned-user” skill, and “Blocker BOT” picks up and closes the conversation without sending PCS.

Auth Web, ABC, and WhatsApp flow

User Starts an Abusive conversation with the Agent
Agents transfer the Conversation to “Blocker BOT”
Blocker BOT collects the Consumer ID from the Bot context
Blocker BOT calls the Context Service API to store this user( Consumer ID) in “BlockedUser” Namespace
1. This user(Consumer ID) that is stored in the context service has an expiration date. The user(ConsumerID) will be deleted after 30 days.
Then Conversation will be closed without sending the PCS

If the same user initiates the conversation again, the Router bot will identify the User’s ConsumerID by checking the Context service repository and transfer the conversation to “Returning Abusive Skill” and “Blocker BOT” picks up and closes the conversation without sending PCS.

Configuration Details:

Each rule will call Faas to evaluate the field, for example, IP address, and customer id will be a field for evaluation.

Screenshot 2023-06-07 at 12.53.08 PM.png

Faas for UnAuth web messaging (1 rule):

Faas function will accept conversation ID as parameter and will try to get session Id and Visitor ID I from context warehouse:

if empty:

Faas will return false - user is not in the ban list for this condition or no shark session ( WA/ABC/SMS)

if present:

Faas will call Visitor API and will get the current attribute IP address
Faas will call Context warehouse by Session attribute as IP address to get attributes for given conversation to compare with Visitor API results.
if evaluation logic is true, return true and the user is in the ban list
Cache Visit API response at context warehouse by using conversation id as a session.

Faas for Auth web messaging or WA/ABC/SMS (2 rules):

Faas function will accept the consumer ID as a parameter and will try to get the session Id from Context warehouse by consumer ID

if empty:

Faas will return false - the user is not in the ban list ( WA/ABC/SMS)

if present:

Faas will return true - the user is in the ban list.

Context Warehouse configuration:

Create a namespace called “BlockedUsers” or “BannedUsers”
Set the TTL to Property to release the user from the Banned users list.
Conversation Context Service(CCS) API documentation:
CCS API V2 will be leveraged for this solution
Context service Session property example:

java:

"accountId": "81021622",
 "nameSpace": "Blockusers",
 "sessionId": "12342", //userid or IPAddress
 "ttlSeconds": 2000,
 "payload": {
   "conversationId": 12342,
   "blockdate": "08/02/2022"
 }
}