AI Intelligence Hub

Project Overview

Product Vision

When our small but mighty product team was approached by Conversica's CEO with a vision for a brand new automotive intelligence platform based on NotebookLM, we were more than prepared to jump into gear. We had the following vision laid out for us:

• It needed to be a platform-specific experience, launching solely for the automotive industry first with others to follow
• We had to retain Conversica's main offering of sales, marketing, and customer service agents while expanding to an internal agent
• Users should have the ability to make AI do just about everything for them within the platform, save for key escalations and handoffs
• There needed to be a guided process that helped users set up campaigns, inbound lead flows, and special offers
• Each area of the product was to be used as a data source, with a NotebookLM style chat easily accessible for all users

From these requirements, which painted the picture of a hands-off, self-service AI partner, I identified several design priorities to guide my work across the platform:

• Letting users have clear visibility into the why of the agent's logic, allowing them to guide and correct as needed
• Creating a method of data deliverability within the agent interface that helped users to take actions quickly
• Showing the different parts of the AI - the sources, personality, and knowledge bases - in a scannable format
• Consistency in designs across different screens, something that is generally hard to accomplish in fast-paced environments

AI-Generated Designs

v0 Base44 Claude Design HTML.to.design

In order to generate proofs of concept quickly, our team turned to AI to help us out with the initial prototype. There were several different AI tools I used over the course of the product:

AI Tool	Used For
v0	Initial proof of concept screenshots & discovering the initial elements that would make the product a success
Base44	Complete product prototype & validation of the product with existing and potential customers
Claude Design	Comparing design patterns & incorporating customer feedback into the overall design

I often choose not only the tool to use, but the level of AI involvement based on what I'm trying to accomplish. Large scale prototyping tools like v0 and Base44 are used to explore and test product directions, because they excel at showing the big picture. Meanwhile, tools such as Claude Design - which are capable of handling single screenshots in addition to larger prototypes - are used to refine different elements of larger designs, because they contain useful conversation prompts that make me think in different ways and help validate I really am delivering the best experience.

However, it is still important to me that I use my own product and design judgement to evaluate outputs against what I know about our target audience, design best practices, and knowledge gained from the industry and user testing. Ultimately, my designs did get completed on Figma - not because AI didn't make it much faster to complete the design, but because as more precision became required, the more important it was for me to have full control over what was being presented to our customers and handed over to Engineering.

Design Strategy

Functional Design & Product Interaction Spec Design & Product Strategy

I had been using AI as a designer to intentionally explore concepts, but Product & Leadership were generating their own prototypes at the same time to narrow down the product requirements and concepts. As the sole designer on the team, it fell to me to reconcile the two versions into a single prorotype bringing both of our ideas together.

Because the prototypes provided by product often looked more resolved than the underlying product requirements truly were, I often found myself as the sole source of determining things such as:

• If an element was intentional or an AI hallucination
• Why certain options, buttons, or verbiage existed
• What actions needed to happen on non-functional clickable elements
• If the behavior within each prototype was what leadership intended
• Different states for various interactions and labels
• Edge cases that had not been fully explored
• Which terminology and verbiage was more in line with the brand
• If any minor UI elements had been eliminated from the prototype by mistake

In order to do this, I systematically would review the prototypes every week, compiling a comprehensive list of questions around the section the team had agreed to meet on that week. I would then facilitate a working session with the leadership team until each question was answered, which normally took anywhere from 2 to 4 hours at a time. Sometimes, these questions would be answered - but plenty of times, there was enough dissent among the team that the final call rested in my hands.

When it came time to make these decisions, I reviewed notes from user testing sessions on behavior and preferences, anticipated future needs from both those users and the company, incorporated current product goals and market positioning, thought about system consequences, and also spent time with Engineering to learn about the technical reality of certain solutions.

Defining AI Agent Behavior

The main product Conversica is known for is their autonomous AI agents, who act on the behalf of sales, marketing, and customer service reps to perform client and lead outreach. Just like regular employees, they are capable of making connections and building relationships to work towards business goals. But unlike humans, the AI agents needed configuration controls to define their personality, communication style, and behavior.

I started off by giving the users a way to assign the AI a specific tone of voice, which established a baseline for how each agent would communicate.



Each of these established the agent’s approach to interacting with leads, and default personality traits were associated with each one, though the user could change those as needed.

Tone	Description	Traits
Balanced	These agents are often clear and concise, using language that is easy to understand for all audiences. They operate with confidence	Approachable, organized, thoughtful, adaptable, reliable, easygoing
Engaging	These agents are often conversational and warm, actively showing they enjoy the conversation. They tend to heavily personalize interactions and are creative, making them a valuable asset on customer service and retention teams.	Cooperative, outgoing, friendly, curious, encouraging, attentive
Executive	These agents are often direct and to the point, showing they have an understanding of strategic priorities. They focus on being both persistent and concise, targeting their communication towards business professionals.	Efficient, dependable, composed, personable, practical, pragmatic
AI-Suggested	These agents automatically speak in a tone that works best for your company, matching the feel of uploaded branded materials and provided sources. They are a good option for marketing teams needing consistent brand-based communication.	Varies depending on the available source material.

The agent also had certain behavioral dimensions initially set based on their selected personality type, which were fully adjustable to give users more granular control on how their agents communicated.



In order to define these, I thought about what might actually change various messaging behavior and writing styles, as there is more that goes into communication than abstract personality traits. I decided that each dimension should be able to influence distinct aspects of the messages the AI generated, and set up the following:

Behaviors	Usage
Reserved vs. Expressive	Used to control writing style. Reserved agents tend to write in straightforward, declarative sentences, while expressive agents are more prone to exclamation points and other flourishes.
Verbose vs. Concise	Used to control the length of messages. Verbose agents write long messages with lengthier descriptions when available, while concise agents keep messages short and purposeful.
Cautious vs. Confident	Used to control how much information is provided voluntarily. Cautious agents offer more access to human representatives in conversations, while confident agents offer more scenarios they can handle without human involvement.
Analytical vs. Creative	Used to control how close to the example messaging responses should be. Analytical agents will stick close to any provided copy almost verbatim, while creative agents take the copy more as a suggestion and send out a more unique array of messages.
Patient vs. Persistent	Used to control how assertive messages come off as. Patient agents will let the lead go at their own pace, while persistent agents tend to highlight more urgency when it comes to timelines and next steps.
Objective vs. Personalized	Used to control the amount of variables and personalization details mentioned. Objective agents will stick to known products or offer details, while personalized agents will custom tailor messages to leads to expand into things that might specifically interest them.

However, despite some controls related to formality listed within the agent traits and behaviors, there was one more big thing I needed to take when it came to agent configuration - multi-language behavior. Conversica provides support for a number of languages, including English, Spanish, German, French, and Japanese.

While multilingual support extends the agent's reach, translation alone doesn't account for differences in communication conventions across languages and markets. Expectations around formality, titles, tone, and other conversational behaviors can vary significantly. As Conversica expanded internationally, the agent needed more granular controls over how its personality translated across languages.

With this in mind, I defined several things that can occur within conversations which may need to vary by language or market:

• What level of formality the AI would speak in at the start of the conversation, and if tone flexibility was allowed
• Tone mirroring, where the AI matches the speaking style of the person talking to it
• The use of formal forms of address, such as titles being written next to names or the use of honorifics
• The use of emojis, which AI often tends to add to conversations when the overall personality is an outgoing type unless otherwise specified

This led to me creating the following design for language-specific communication standards, which encompassed the above traits per language.

Maintaining AI Knowledge

In addition to defining behavior, AI agents also needed access to information regarding the company, their products and services, typical branded communication, current offers and promotions, and the leads they were contacting.

Most of that data was collected simply through normal business operation, and included current inventory, upcoming appointments, and products leads had expressed interest in. Current customers already had this data located within Conversica, but new customers often needed to pull this from Salesforce, Marketo, or their Dealer Management System alongside other specialized systems such as those for inventory and recalls, and port it into Conversica via a two-way integration.

This information lives within data tables located across the product, and information can easily be obtained from the system of record - or in the case of lead information, the AI agent can update lead records which would then be synced back to any other systems of record.

However, there were plenty of other sources that didn’t exist within these structured systems. Clients generally needed their agents to have access to their current website, alongside any other platform information such as social media posts, product documentation, and other branded materials. In many cases, they wanted the ability to manually add facts that were not surfaced on any platforms, such as special offers for current customers, situations where human intervention was asked for, or temporary changes to normal business operations.

In order to aggregate this information together, I designed a knowledge base where users could connect existing sources and manage the information available to their AI agents.

Sources

The most used features within the knowledge base were website sources, which support ingestion from verified URLs and import that data into Conversica’s system.


URLs needed to be verified before users would be able to import data from them, which was accomplished via the user uploading a file from Conversica onto their domain to prove ownership.

I designed a simple setup for users to add new website sources, which included a quick selection between the following for inclusion in each URL:

• Entire Domain for users wanting their entire website crawled
• Single Page for users wanting only the specified page included
• Page + Selected Subpages for users who wanted most of their domain included, with a couple exceptions
• Include / Exclude Rules for advanced users who had specific requirements about which URLs should and should not be present in the source

By using this system, it allowed the entire list of subpages to not be displayed unless it was necessary, which reduced decision fatigue for users. It also allowed users the ability to add different sections of their websites via different sources, helping to categorize which specific part of the website the AI agent might need to look at for each request.

Alternatively, users could provide file sources, such as PDFs, CSV files, or Word documents. These operated as a simple file upload modal with a toggle to indicate whether an AI agent was authorized to send these directly within conversations or not.

Offers & Events

Offers required a different approach, since they weren’t necessarily based upon a URL or marketing material. I designed a framework for users to add current discounts, incentives, promotions, and other offers operating under the following rules:

• In order for the AI to confidently talk about the offer, they would need to know the requirements, restrictions, and redemption instructions
• Some offers came with their own set of terms & conditions that would need to be surfaced
• Offers would be attached to campaigns that were sent to eligible users, so eligibility was less important to be defined within the offer itself

Events were very similar to offers, but they had a unique issue: while offers could simply be mentioned in messages during the dates they were active, events often lasted only a single day and therefore needed to be communicated before they happened.

I solved this problem by adding a promotional period, which could span any dates prior or concurrent to the event itself. This was then added to the offers, in case users wanted their agents to be able to talk about upcoming offers with leads who were on the fence about purchasing.

Facts

In Conversica’s original system, website scrapes and CSV uploads would automatically populate facts for AI agents. With this brand new version of the product, those were able to live independently as sources, while facts could be a narrower list of information that users intentionally provided to the AI.

The decision to keep facts intact rather than discontinue them in favor of the more compact sources feature was due to a combination of the following:

• In order for AI agents to seem human-like, they might require access to information that is not public knowledge or readily available on webpages
• Facts included an area for sample questions, which helped to redirect the AI agent towards a proper response in case they routinely encountered confusing or conflicting requests

This made facts useful for information that needed to be explicitly defined, and gave users more direct control over how the AI responded to specific questions.

Guardrails

Finally, users were able to set up guardrails that were set up to override provided information and spontaneous responses as needed. These ranged from company policies regarding not speaking to leads about pricing to stopping messages after a certain conversation limit had been reached.


One important thing to note about guardrails was that the user was not given a free text box to define the instructions and qualifications for when the guardrail should be used. Instead, they needed to pick from a dropdown list with the following options about if leads:

• Ask about certain topics
• Ask questions similar to the provided one
• Respond negatively to something
• Respond positively to something
• Send a certain number of messages

I made this decision because it was important to help guide the user towards the kinds of inputs AI is capable of looking into and making a judgement call on. Additionally, with other instructions needing to come after the initial qualification - such as if messages should stop and continue for each channel, and the selection of specific actions - it was better to give users separate controls for these, rather than them specifying everything in a free text box and potentially confusing the agent.

Using this combined with the rest of the knowledge base, users had multiple ways to provide AI agents with the information they needed, while maintaining control over when and how that information could be used.

Building Trust in AI

One of the recurring challenges I encountered with this project was the company’s overall update to their positioning, which encouraged full use of AI with minimal user input. Meanwhile, users had not changed their stance despite the advancement of AI over the past few years, and still were requesting full control over various aspects of their messaging. Since I knew that the company would continue to push for greater AI autonomy, I decided to use the initial launch of this product to help users build trust in Conversica’s AI agents.

The most prominent area where this approach can be seen is in my work on the campaign builder, which was a guided wizard meant to help users set up outbound campaigns and incoming lead flows. For each step the user takes, even though they define the information, AI helps them along the way to limit the amount of time they need to put into the campaign setup.

Step	AI Contribution
Step 1: Choose Audience	The user is responsible for uploading the initial contact list or segment, but the AI will then make recommendations for related lists to add to the campaign.
Step 2: Select Goal	Based on the provided list or segment and the types of leads selected, the AI will automatically filter down to the most likely matches. If there is only a single match, the AI will automatically select it.
Step 3: Campaign Information	The AI will autofill information such as a suggested campaign name, agent to handle it, and relevant special offers. If the user uploads a campaign knowledge PDF, the AI will read this to help autofill other fields.
Step 4: Agent Instructions	For most campaigns, the AI will recommend a standard messaging cadence. This screen also tells users what the AI is capable of personalizing within the context of each message.
Step 5: Message Preview	Each attempt for the first outgoing message will automatically be generated by the AI, including the subject line. Users can opt to continue regenerating messaging until they find something they like, or switch to manual editing.

There was one more part of the campaign builder that was not located as a separate step in the wizard, which was the testing process. After an assessment of what it would take for users to actively choose an AI-generated message for their first attempt over their own copy, I decided that when testing the campaign, there needed to be several ways to show users what AI can do for them that manual editing can’t.

The first part of this was to highlight personalization. For each lead, there was a set of information such as their first and last name, vehicle of interest, and other things that were learned through past conversations, submission forms, etc. These were stored as variables within Conversica, and could be added to any message as needed.

If users had chosen manual editing, they would be able to clearly see where variables were in the messaging and insert their own. But for some leads, if they were missing information or their entry had not been mapped properly, this might lead to this grammatically incorrect or awkward messaging (especially with multi-language considerations). By highlighting personalization within the message, users would be able to see where their written verbiage had failed, and the changes that AI would have made to produce a more natural response.

Next was to focus on the available AI insights. At any point during the testing session, users could view AI insights on a message of their choice. These AI insights reveal potential spam triggers, misconfigured variables, and places where overall messaging could be improved. If the message was a reply, these insights would also reveal what information the AI had gained from the lead and why they responded in the way that they did. While users would still have to make any changes they wanted manually, they could also choose to switch to fully AI-generated messaging to make all of the changes automatically.

From there, users could choose to regenerate messages, resulting in an AI written attempt. Any messages they liked could be saved as attempts moving forward, altering the campaign to have substantially more AI-generated content than before.

Designing Human-AI Workflows

Something I find that is very different in AI product design specifically is the way information needs to be surfaced between autonomous AI agents and the humans working alongside them. In a traditional product, the system generally waits for a human to do something. With an autonomous AI agent, work can happen without the human being actively involved, which creates different design problems - most notably figuring out when users need to intervene, surfacing what the AI had done up to that point, and helping users find the information they need to move forward.

In order to accomplish this, I designed a feature within Conversica for task assignment, which signals the handoff point between the AI agent and their human counterpart - in Conversica’s case, usually a sales rep. When the user was assigned a task, it would appear in their inbox, and information about the AI’s activities and why they had been pulled into the loop would be surfaced.


This solved the design problems via the following methods:

• Users would know they needed to intervene in certain conversations when a task appeared in their inbox
• The provided conversation history in a side panel allowed the user to see the AI agent’s communication with the lead, and learn insights about those messages
• Each task was labeled with a task type and summary with recommended next steps, and users could pull up the native AI Intelligence Agent to ask it further details about how to resolve the task

This visibility was particularly important because AI agents handled a variety of tasks for the user, such as taking charge on responding to leads across various channels, encouraging them to buy products or services, answering questions that were asked of them, and even scheduling appointments for the user - something which required the AI to have insight to the user’s calendar.

However, when it comes to designing human-AI workflows, the human-in-the-loop is not the only person that needs to be considered. The lead also experiences and communicates with the AI, making that interaction just as important.

One of the things I designed related to this interaction was the channel switching experience - what it looks like when a lead asks to switch to SMS, or chooses to open a chat window instead of replying via email.

SMS

Most campaigns and outbound messages start via email, but one common request from leads is that they want to be texted instead. There are a lot of rules surrounding SMS when it comes to business messaging, including:

• SMS opt-ins must be verified before messaging can begin
• Opt-outs must be allowed at any point in time
• There are rate limits controlling how often messages can be sent
• Quiet hours are generally from 8am to 8pm, but vary by region

For the most part, these items are handled via Twilio, which helps to keep track of verified numbers and can automatically pause messaging sequences to allow for rate limits and quiet hours. However, when the user is setting up campaigns, they are responsible for setting up the preferred behavior surrounding SMS consent.


The advantage of turning this decision over to the user is that they could ensure leads would continue receiving outreach via email when appropriate rather than unnecessarily ending the conversation, the preference of which might vary depending on the type of campaign being sent.

Chat

A common workflow pattern when it comes to AI agents and lead intake is where a lead reaches out via chat on a website, has a conversation with the AI agent, and then eventually is handed off to a human-in-the-loop an email or ticketing system.

While this is available in Conversica, I designed a system that can also go the other way around - a lead who has been emailed can opt to switch to a chat experience at any point in the conversation.


This had been a requested feature from our B2C clients, who were continually handling users only being available at certain times and transactions being slower due to the nature of email. I decided on the following features for the email-initiated chat experience:

• Agents needed to send the first message in the chat, reminding the user where they left off in the email
• Quick replies needed to be available to guide the lead towards a positive, action-oriented response
• Chat could not be turned on for campaigns until the widget was properly configured, including adding a privacy statement

This led to the following design for the widget, which was launched open on a separate small window when the lead selected the chat option from their email:


One of the largest concerns was that once the lead had switched over to a chat experience, it became more obvious that they were speaking with AI. Conversica does offer transparency settings to support compliance with regulations such as the EU AI Act, but when possible, the preference was for lead to believe they were messaging a human employee. Therefore, I decided to give the user two options:

• They could choose to change the name of their agent in the chat, connecting leads to the same agent in the back end while making them feel they were speaking to someone different on the front end, or
• If they wanted their agent to have the same name, they would need to add an AI disclosure statement to their emails to be transparent about the agent’s AI identity

Finally, the handoffs had to be coordinated a little differently than they were in the standard chat experience. Because the chat existed to provide leads with faster answers, it automatically became a bad experience for them if the AI got stuck and needed to assign a task to a human-in-the-loop. There were also concerns with timeouts, and how further back-and-forth interactions would be handled. Below is an overview of the challenges uncovered, and how I solved them:

Challenge	UX Solution
The AI agent might need to assign a task to a human-in-the-loop, effectively pausing the conversation.	In addition to creating a task for the rep, the AI agent would offer to continue the discussion via chat with the lead regarding other topics they are able to handle autonomously. If there were no other things to address, then the AI agent would end the chat.
The lead might leave the window open and stop responding, leading to an eventual timeout.	Timeouts are set to occur after 20 minutes of inactivity, which prompts the AI agent to send a goodbye message and deactivate the chat window. Leads can click a button to restart the chat, or close and open the chat window back up.
The lead might send another email after the chat interaction ends.	A chat summary would be sent via email to the lead as a reply to the last message upon closing the window, a timeout, or ending the chat. This gave a natural responding point for any future email communication.
The lead might open the chat window again after previously closing it.	Chats contain both a record of emails sent and previous chat conversations, allowing the lead to refer back to it. This does not change the behavior, where the AI agent opens with a statement summarizing where the previous conversation left off.
Chat allowed for longer and less structured conversations than email campaigns were typically designed to handle.	Guardrails and verbatim responses can be configured to match chat experiences, and the chat channel preferences would be used automatically once the channel has been switched.

Together, these workflows allowed the AI agent to operate autonomously without leaving either side of the conversation disconnected from what was happening. Humans-in-the-loop were given the context and guidance they needed when intervention became necessary, while leads could move between channels without losing the continuity of their conversation. Designing these interactions meant considering not only what the AI could accomplish independently, but how each person involved would enter, leave, and re-enter the workflow as the conversation progressed.

AI-Native Interaction Model

AI products span a wide range of use cases, but one of the things that sets generative products apart is the inclusion of a native AI interface. These involve interactions with internal AI assistants, and Conversica’s is their Intelligence Agent.

LLMs at a baseline are able to understand and respond to user queries in their configured language, though plenty have access to a standard set of actions to extend what they can accomplish during conversations. Conversica’s internal Intelligence Agent was given the ability to perform the following actions:

• Knowledge retrieval from internal data tables, active conversations, and third-party integrations
• File parsing of PDFs, CSVs, and Word documents
• Output of CSV files and PDFs that summarize findings
• Creation of platform-specific objects such as campaigns, segments, and appointments
• Definition of what constitutes a formal Conversica Insight™ optionally including a recommended user action based on it

Most of these I chose to depict via the use of a widget, because they were often the valuable outcomes of intense research and business analysis sessions, meaning if the user came back to a conversation later on they would want these items to jump out at them appropriately.







Good products aim to be sticky, meaning that users spend a lot of time with them each day to the point they become indispensable. In order to compete with products such as NotebookLM (now Gemini Notebook) which also had access to uploaded data sources, it was also important to encourage continued engagement by giving users ongoing suggestions for ways to interact with the Intelligence Agent.

I accomplished this both with rotating placeholders in the input box with general suggestions for requests such as “analyzing business challenges” or “investigating industry trends”, and with intentional quick replies to each message that either asked the Intelligence Agent a specific follow-up question or asked it to take an action based on its findings.

These were meant to help the user think of queries that met the capabilities of the Intelligence Agent, but also to teach them what sorts of actions or further thinking the assistant was capable of.

As these interactions developed into deeper conversations focused on one specific business goal or insight, it became important for users to be able to easily return to them later. When it came time to design the history of these chats for that access, I decided to highlight these business topics heavily in the history cards.

• Blue cards were for conversations where the Intelligence Agent had finished responding
• Mint cards were for conversations where the Intelligence Agent was in the middle of writing a response.
• Yellow cards were for conversations where the Intelligence Agent needed to ask the user a question before proceeding with the conversation
• Grey cards were for conversations that had encountered an error (such as a timeout) when retrieving a response, and needed to be queried again

Users also had the ability to edit the original AI-generated title and description, and share their findings with other users within their organization. Shared chats in particular needed other considerations to be made that had been outside the original scope of the project, including:

• Distinguishing between two users, both in the UI and for the assistant itself
• How simultaneous queries are handled and prioritized when multiple users are actively in the chat
• Permissions between different roles, so that an unauthorized person does not have access to see data discussed with a different role

Considering I was designing this feature very close to the launch date, I made the final call on prioritization that if sharing chats was a mandatory feature for this release, then the share would simply create an independent branch of the conversation for anyone it had been shared with, rather than letting users all continue speaking with the Intelligence Agent on the same branch. Additionally, chats could only be shared with users at the same company with the same level of access as the original speaker or higher, to avoid permission issues.

Design System

Design System Figma

The underlying foundation beneath this entire product was Signal, a scalable enterprise design system that I built specifically to support this 0-to-1 launch.

I pitched the idea to Conversica’s leadership team for a design system meant to cut through the noise and pinpoint the most important actions for users with a minimalist, modern approach, and received immediate buy-in. I was in charge of setting up the governance for the system, as well as tokens for common colors and spacing. It has roughly 28 components and 7 patterns, each of which have full documentation provided through a web-based documentation hub.



To get the design system moving quickly, I leaned heavily into Conversica's newest branding, using several blues and neutrals to build a mostly monochromatic color palette. Most of the visual hierarchy and data states are driven by various border and background color shades, using small pops of other colors to bring tags and icons to life.


While design systems contain many components, the most frequently used element across the product is a card containing a repeatable data display framework. These form the essential building blocks for the data uploaded to Conversica, and though the AI intelligence agent would mainly be responsible for parsing this data, there are still enough users that want to view and filter their own data that I knew any table pattern would need to be simple and easy to handle.



Since there is a table on nearly every single page, one of the primary areas of focus was making sure there was adequate visual interest among each columns. By using a series of tags, badges, and statuses, almost every table could look unique and different.

Badge	Name	Purpose
	Status Badge	Used to specify the status of a record, often a campaign, vehicle, or conversation.
	Type Badge	Used to declare the content type, most often indicating specific service or escalation reasons.
	Finance Badge	Used for dollar amounts or other concrete numbers that convey value to the business.
	Percentage Badge	Used for percentages and estimates trending across reports, tables, and charts.
	Clickable Badge	Used for linking existing complex objects into tables, such as campaigns or segments.

While the above badges help to break up the monotony of a standard table, especially in dense, data-heavy sets, one of the most helpful features within the card are the filters. Their visibility can be toggled on and off by using the button in the upper right corner. By using a variety of unique filters, users are able to quickly get to the information they need by narrowing down to the exact data that is relevant to their use case.





Though Signal has many more components to help promote consistency in design across various product areas, these are the core ones making up the non-agentic side of the product, and many users will interact with these every day they log into Conversica.

Outcome

The automotive version of the AI Intelligence Hub was shown off at NADA 2026, resulting in new clients purchasing the product before Conversica had even built it. Out of everything that was shown, these new prospects were most excited about the Intelligence Agent and how it could be used to identify their business challenges and take action on them all from the same platform.

Conversica successfully launched the Intelligence Agent as a standalone experience on April 1, 2026, using third-party integrations as data sources. Essential pages for external agent functionality, including Conversations, Tasks, Campaigns, and Segments launched the following month on May 1, 2026.

Conversica had plans to launch the rest of the product in early July 2026, and expand into other target audiences starting in 2027.