Chapter 13

Designing a Company Policy Processor

A well-designed company policy processor is essential for ensuring that customer interactions are handled according to specific business rules and service-level agreements. This processor can be thought of as a series of nodes, each responsible for performing a specific action or decision, to guide the chatbot's response.

The Flow of a Ticket

The process begins when the application receives a new ticket from the helpdesk. Here's how it typically unfolds:

  1. Receive the Ticket: The system retrieves the ticket from the helpdesk platform. This includes all messages in the thread, but we first check whether it’s the initial message to avoid disrupting an ongoing conversation with a human agent.
  2. Process the Message: We clean up the message, removing unnecessary characters, fixing common typos, and structuring it for easier processing.
  3. Classify the Intent: The clean message is passed to our AI classifier, which identifies the customer's intent. For this example, we assume the intent is classified as a "Tracking Order" request.
  4. Load the Policy Processor: Based on the identified intent, the relevant policy processor is loaded—in this case, the Tracking Order Policy Processor. This policy processor defines the rules for handling a tracking-related inquiry.

Node System for Policy Design

The policy processor is built using a node system, where each node represents a specific task or decision point in the flow. You can think of this system as a visual workflow, allowing you to create complex processes without writing code for each individual step.

Here are some of the key node types and their roles:

  • Get Order Number Node: This node retrieves the order number from the eCommerce integration using the customer’s information (e.g., email or order ID). This step is essential for ensuring that the correct order is being tracked.
  • Extract Tracking Number Node: Once the order information is retrieved, this node extracts the tracking number associated with the order. This tracking number is used in subsequent steps.
  • Tracking Information Node: This node utilizes the carrier integration to retrieve the latest tracking information. It pulls key data such as the current status, the last known location, and the estimated delivery date.
  • Reply Node: After gathering all the necessary information, this node generates a response message that is sent back to the customer. This message can vary depending on the information retrieved.
  • Condition Node: A condition node is used to make decisions based on the data. For example, if the package status is "In Transit," the chatbot sends a message with the estimated delivery date. If the status is "Delivered," a different response is generated. These decision-making nodes allow for dynamic responses based on real-time information.

Below is a simple example of how the flow might look:

Example: Tracking Order Policy

In the case of a Tracking Order Policy, here’s a sample scenario:

  1. Receive Ticket: A customer submits a query asking about the status of their order.
  2. Process Message & Classify Intent: The system identifies the query as a tracking request.
  3. Get Order Number: The policy processor retrieves the order number using the customer's email.
  4. Extract Tracking Number: The system fetches the tracking number associated with the order.
  5. Get Tracking Information: The carrier integration provides the tracking status, such as "In Transit."
  6. Condition Node: Depending on the tracking status:
    • If the status is "In Transit," respond with the estimated delivery date.
    • If the status is "Delivered," confirm the delivery and ask if the customer received the package.
  7. Reply Node: The system sends the appropriate response to the customer.

Visual Node Design Tools

Several open-source tools can be used to design and manage this node system visually. One popular choice is Rete.js on GitHub, which provides a graphical interface for building and connecting nodes. This approach allows you to visually map out complex decision trees and workflows, making it easier to adapt your policies as your business rules evolve.

Customizing the Experience with Company Policy

By using a node system to design your policy processors, you can cater specifically to your business’s unique needs. This customization ensures that customer inquiries are handled according to your specific rules, timelines, and priorities. Each node in the system represents a step that can be easily modified, expanded, or fine-tuned as your business grows and customer expectations evolve.

This architecture empowers your chatbot to function as an extension of your customer service team, adhering strictly to company policy while providing real-time responses based on dynamic data.

← CH12: Integrating a Carrier
Part Three: Beyond eCommerce →