In recent weeks, I’ve been discussing the concept of “intent-less” architecture, which might seem unfamiliar to those who haven’t built a bot. This blog post is the first in a series exploring this innovative approach, aimed at simplifying bot development and scaling solutions without the complexity of traditional intent-based systems.
Traditional bot development involves intricate processes like creating entities, utterances, and intents, often requiring specialized and expensive developers. This complexity can be a significant barrier, especially for organizations looking to implement effective virtual agents without a large team.
In this series, we’ll delve into how our new strategy at Espressive addresses these challenges, eliminating the need for complex intent creation and offering a more streamlined, scalable solution. Stay tuned as we explore various use cases and the transformative impact of our intent-less virtual agent architecture.
Traditional Bot Building
If you’re familiar with traditional NLP/NLU bot development, you’ve likely encountered the complexities of building “entities,” “utterances,” and “intents.” If this is your area of expertise, you can skip ahead. For those who aren’t as familiar, here’s a quick overview:
- Entities: These are the key terms your bot needs to recognize, such as “Windows,” “Outlook,” etc.
- Intents: An intent comprises several components:
- Utterances: Sample phrases that include the entities, guiding the NLP/NLU engine in directing interactions to the appropriate intent.
- Workflow: The logic for handling interactions, which could involve automating a function, providing a series of options, submitting a request, or delivering a knowledge article or catalog item.
Let’s illustrate this with an example: ordering ice cream. Suppose we have the following rules:
- Flavors: Vanilla, Chocolate, Strawberry, Mint Chocolate Chip, Cookies and Cream.
- Serving Style: Chocolate is available only in a cone, while other flavors can be served in a cone or cup.
- Toppings: Sprinkles, chocolate chips, and caramel drizzle are only available for cups.
- Serving Location: Customers need to specify whether they want their ice cream to stay or go.
Here’s how you’d traditionally handle this:
1. Create Entities: For instance, a “flavors” entity with instances for each flavor.
2. Build Intents: An intent for “ordering ice cream” with sample utterances like “I want ice cream” or “I’d like a fudge sundae.” You’d need to account for variations in phrasing, such as “sundae,” which might require additional entities to capture all permutations.
3. Design Workflow:
- If the flavor is provided, use “slot filling” to avoid asking for it again.
- Build out additional questions and conditions based on the rules. For example, if chocolate is selected, skip the serving style question since it’s only available in a cone.
The Evolution of Virtual Agents
To understand our current innovation in intent-less virtual agents, it’s helpful to look at the motivations behind this shift. Essentially, our goal was to scale effectively without the need for an extensive team.
Since the virtual agent market began in 2017, vendors have explored various approaches, largely influenced by their backgrounds and expertise:
- ITSM Vendors: Offered a toolkit for customers to build their own solutions, provided they had the necessary resources and expertise. While ITSM developers often claim they can create their own bots, we’ve found that very few customers have the resources to develop solutions that not only deliver a return on investment but also satisfy users.
- Search-Based Solutions: These typically function as “black box” knowledge base (KB) search tools. Administrators are left to improve performance by optimizing knowledge articles. This approach is akin to “Google” for work, requiring reverse engineering to understand why certain searches succeed or fail.
- Espressive: We took a different route by offering a fully managed service. This approach meant we were accountable for the outcomes and ROI of the virtual agent solutions we provided.
As a managed service provider, it was our responsibility to ensure customer success with their solutions. This commitment led us to generate a substantial amount of content and continually refine our offerings.
The Costs and Complexities of Traditional Bot Building
The complexity of this approach often necessitates skilled developers, particularly when using platforms like ServiceNow. These developers are not only expensive but also challenging to find, adding to the overall cost and effort required.
You might be thinking: is all this work necessary for just “one” use case? And how many use cases are required before the bot delivers real value? The scale of effort needed for designing and deploying a virtual agent can be substantial, even for basic interactions.
To provide an example of the process you would employ using a traditional platform, I am outlining the process based on ServiceNow’s platform. Designing a topic in ServiceNow for a virtual agent involves several intricate steps, each with its own set of challenges. Here’s a closer look at what’s involved:
1. Creating a New Topic:
- Overview: To start, you must create a new topic in the Virtual Agent Designer. This involves defining the topic's purpose and the initial setup, which includes selecting a name and providing a description.
- Challenge: Ensuring that the topic name and description accurately reflect its intended use can be challenging, especially when dealing with complex workflows or multiple use cases.
2. Defining the Conversation Flow:
- Overview: Next, you need to design the conversation flow. This involves mapping out the interactions between the user and the virtual agent, including defining user inputs and agent responses.
- Challenge: Crafting a seamless and intuitive conversation flow requires a deep understanding of user behavior and potential decision points, making it difficult to anticipate all possible user inputs and scenarios.
3. Setting Up Trigger Conditions:
- Overview: Triggers are essential for directing the conversation to the appropriate topic. You must configure conditions that determine when a topic should be activated based on user input.
- Challenge: Designing effective trigger conditions involves identifying the right keywords and phrases, which can be complex and time-consuming, particularly for dynamic or varied user interactions.
4. Creating Dialogs and Tasks:
- Overview: Within each topic, you create dialogs that define how the agent should handle specific user inputs. You also set up tasks that the agent performs, such as retrieving information or executing actions.
- Challenge: Building comprehensive dialogs and tasks requires meticulous attention to detail to ensure they function correctly and handle all possible user interactions.
5. Integrating with ITSM Components:
- Overview: Topics often need to integrate with other ITSM components, such as asset management or incident management. This integration involves configuring data sources and ensuring that the topic can interact with these components effectively.
- Challenge: Ensuring seamless integration with existing ITSM systems can be complex and requires a thorough understanding of both the virtual agent's capabilities and the ITSM components it interacts with.
6. Testing and Refining:
- Overview: After creating the topic, it must be thoroughly tested to ensure it works as intended. This involves simulating user interactions and refining the topic based on feedback.
- Challenge: Testing can uncover unexpected issues, and refining the topic based on test results requires iterative adjustments and ongoing monitoring.
In summary, designing a topic in ServiceNow’s Virtual Agent Designer is a multi-faceted process that demands a detailed understanding of conversation design, trigger configuration, and system integration. The complexity of these tasks underscores the need for skilled developers and the challenges of achieving a well-functioning virtual agent.
A New Approach: WorkflowIQ
When our teams met with customers to understand their needs, they often began with a diagram detailing their processes. For instance, here’s an example of a process diagram used for ordering a new mobile device for employees.
As you can see from this diagram, creating intents to handle this use case would be exceedingly complex. There are numerous questions to ask, leading to decision points that branch the conversation in various directions, not to mention multiple integration points with the asset management and catalog component of their ITSM platform.
So, our team at Espressive brainstormed ways to simplify this process without requiring the creation of extensive intents or content on our platform. What we developed is one of the most exciting innovations we’ve seen recently (and we have a lot of exciting developments at Espressive).
The breakthrough idea was, “What if we could use this diagram to dynamically create all the necessary artifacts?” And thus, WorkflowIQ was born.
With just a simple knowledge article and our Barista Experience Selector, powered by BaristaLLM, we’ve revolutionized the process. How’s that for innovation?