Ep 9: Knowledge Copilot: The Future of Answer Engines with Precision RAG
Precision RAG is more than a buzzword. It’s a groundbreaking approach that quickly delivers accurate answers to queries from both your customers and internal teams. So what is precision RAG exactly? And how does it deliver the quickest, most accurate answers from your data? Learn how this innovative technology reduces support cases, minimizes escalations, and accelerates case resolutions. Key Topics - Why Precision RAG stands out as the most accurate solution for surfacing answers - The design philosophy behind xFind - The tangible benefits these choices bring to end users We will also cover integrations, including how your data sources are connected to the answer engine, and how you can start using Precision RAG.
So you can see here what we're going to be talking about today is how answer
engines have changed,
how knowledge copilates have changed, how expectations from your customers,
from your employees has changed, and what we've built to meet those challenges.
This is kind of just an overview of the agenda here,
where this is what we're really going to talk about,
is what that ideal solution looks like.
We're going to get very deep and technical with what precision RAG is,
which is probably why you came.
We're going to look at how it works,
and we're going to look at what this looks like inside support logic.
So kind of starting off, expectations for both your support teams and your
customers are changing.
As technology improves, as things get more complex,
you can see here that your support teams need embedded solutions in the places
that they already are working.
The CRM, the Slack space, and your customers want really great self-service.
They want to be able to take their questions in the way that they propose them
and get immediate answers back.
No longer are customers looking for a list of search results to come through,
wondering if the right answer is there or not.
The market has really changed on these expectations of what both
agents and customers are looking for.
Wouldn't you say, Sargil?
Yeah, absolutely.
I think once the chat you could take him out,
and people understood the power of AI, of Gen AI,
I think the way the immediate consequences of that was understanding
that customer support is going to change,
and customers are expecting a better experience in finding the knowledge they
want.
I think it's been an interesting two years since
in how that played out and where the technology is going in enabling that
experience,
specifically on the more complex side of customer support.
Awesome take on that.
One thing I forgot to talk about at the top of the call,
we're running a contest on these webinars.
If you've been with us before, you know about this contest.
When a GIF shows up on the screen in the chat,
the first person to name the movie that this GIF is from
is going to get an Amazon GIF card from us.
So this is a point in the webinar where we're going to pause for a quick moment
because I know what's coming up.
And I invite you to name that GIF.
We have a bit of a science theme today because we're talking to Anna,
who is an awesome scientist, and so all of these are going to be science based,
just as a little hint.
So here's our first one, and I'm going to look to the chat and see
who can name.
There we go, Chris, on it like you knew it before it came up.
I'm amazed.
That was so fast.
Nice job.
I don't think I can type that fast.
That's great.
So let me click away on that and we can kind of get back to your regular
schedule program.
So now let's talk about looking at the challenges and what the ideal solution
is
from these challenges, right?
We know that from these messy data sources, we want
immediate answers where folks are already working.
We want them to be asked by technical experts that know what they're looking
for,
but also customers.
And we want all that to happen from support cases, from bug tracking software
like Jira.
Sorry, is this right?
Is this kind of how you approached solving this originally?
Is this kind of the problem statement?
Yeah, absolutely.
So I noted that really where the game is still really being played is in the
more complex
scenarios of customer support.
The reason is in those scenarios, it's not just a simple list of frequently
asked questions
that need to be solved.
It's usually very intricate issues dealing with multiple options of different
products and versions.
And the customers don't necessarily know what they're searching for, how to
keyword their way to it.
Even technical experts will be having a hard time and usually they're doing it
as part of
solving the issue in the case.
And the main knowledge sources, from what we've been seeing in many of these
companies,
the main knowledge sources are not nicely organized article knowledge bases,
but rather
all the past cases that the company has already dealt with.
That's the main resource that can really bring up answers to these questions
and possibly next
steps.
So past cases, Jira, all the areas where work has been done on these issues.
And that's really what's setting apart the serious technology that can really
take Gen AI
and enable it in an enterprise setting from many other solutions and vendors
out there
that don't really know how to deal with that level of complexity.
That makes a lot of sense.
At this point, what I want to do is throw a few polls at the audience.
So we're going to launch poll number one right now about the knowledge base
that you have
existing for your team. Do you have a dedicated knowledge base for your
employees right now?
And we're kind of looking at the answers as they come in.
And it looks like it's a mix.
Some teams have a dedicated knowledge base, some don't.
So it sounds like there's a real possibility there for teams to leverage messy
data,
build knowledge base articles off of success, but they can get started with
precision
lag without having that knowledge base completely formed and completely ready.
So another poll I want to kind of launch after this is,
does your current knowledge base use AI to generate answers?
Is this a knowledge base with a simple search on top?
Is this a knowledge base that's using an AI component to it?
I'd love to hear about that as well.
So it sounds like no is kind of winning on that side.
It sounds like folks are using knowledge base systems.
Well, it seems like actually kind of a tie now that more votes are coming in.
So a third question for you, we're going to get all the polls kind of wrapped
up in one swoop.
Are you using the information in your support tickets as a knowledge source?
That's our third poll.
And I'd love to kind of see how the room feels about that one as well.
And it seems like it's pretty split.
So that's interesting.
So it looked like most of our viewers have a dedicated knowledge base.
Most of them are not using AI to generate answers.
And it's a tie in using support tickets as an information source.
That's really interesting information.
So before we kind of get into what precision lag is,
we're going to just pause for a moment and talk about a customer
who's having great success with it.
As you can see here, Vanit Puri from C-Vent is using this knowledge co-pilot
to help his team find the right answers and finding great success with it.
So now let's kind of get into what precision lag looks like.
And here's kind of a quick animation of an overview of this.
So you can see here, we start with a support case.
And we're going to talk about why precision lag is this ideal solution
and kind of get in depth with it.
So, Sariel, can you talk to us about what this is
and then lead us into the more technical overview?
Sure.
So what we're seeing here is on the left-hand side is a support case.
And again, in the more complex scenarios,
usually these are landscape descriptions that can go on for quite a few
comments
and internal comments on trying to figure out what's going on.
And that's a lot of information right there that can be used already as a query
as an issue that needs to be solved.
And then what we do in our implementation of a precision lag in X-line,
announced support logic is first of all, we would like to summarize the details
of the case.
So figure out what exactly is going on there
and really make it very easy for the engine and for the agent at the same time
to be able to use this information that already exists there implicitly as a
query.
That's the first step.
The second step is querying all the relevant data sources.
So as I noted, that's not only going to be a knowledge base,
it's going to be all the past cases and all the GIR tickets or whatever other
sources are out there
that hold a lot of relevant knowledge to dealing with this case.
And that really, this is something that is not obvious to many people,
really implementing Gen.E.I. in an enterprise setting really comes down to how
good your search engine
is rather than necessarily how good the large language model can then provide
an answer.
And really the search engine is a critical element in being able to retrieve
the specifically
relevant items and specifically relevant parts of those items to feed to a
large language model
to generate an answer.
And then once we've done that, then we can generate an answer.
And this is where I'll hand it over to Ana to really go more in depth and
explain
how we built that, what's going on in the engine that we built that enables
this precision
rack to happen. Okay, so RAG is essentially, as you probably know, retrieval of
maintenance
generation, where retrieval comes as a critical part of this process. Because
if we are giving
to their larger language model, to the generative model, an incorrect piece of
text to answer from,
then the answer, of course, is not going to be correct. And it will hallucinate
in sometimes in
very hilarious ways. So our main objective here is to get the most accurate
piece of text
for the retrieval, for the generative model. So we're starting by ingesting all
the different
knowledge sources in the company, where I have a very, very flexible ingestion
pipeline,
which allows us not only process the data and clean it, but also model it
because in an enterprise,
categories, different products, different versions, they mean a lot. An answer
could be
completely different if I'm talking about product A or if I'm talking about
product B.
So we have a very, very flexible modeling procedure that allows us to
fit ourselves to any type of data, any source, and build for us an index to
work with. So
after we process the data in index, we have a very high quality search that is
built on multiple
search engines that together form a solid search result. And we will, in the
next slide, compare
ourselves to the state of the art. And then before we are going to answer based
on what we found,
we are going through a guard rental model, which is a proprietary technology of
support logic,
where we essentially check whether what we have found the most similar
documents are indeed
have the information that we are trying to answer on because often in knowledge
bases in
an enterprise, some data is missing. And this is why, by the way, the tickets
are very useful
because tickets are often contained much more relevant and up to date data than
the static sources.
So before we are going to generative LML, we are indeed testing that the data
contains the answer
that with a high probability, we have a chance to give a correct answer. And
only then we are
sending this piece of text or several pieces of text that we have found with
the question that
the user asked and asking the generative LML to generate an answer based on
what we have found
and validated. After the user gets the answer and the reference to the piece of
text to those
documents from the company knowledge, so he could verify that indeed we have
fetched the correct
data so he could validate what the generative LML gave him. Then he could
feedback and give us some
additional way to improve ourselves, to improve the search, to improve the
guardways.
So the system could improve over time. So this is the basic structure of
precision reg,
which is emphasis on search quality and on verification and feedback.
That makes a lot of sense. It is coming in, you are processing the language
from the query,
you have guard rails, you have filtering going on with the knowledge sources,
you have this
feedback loop that is making everything improve over time. It is a very
exciting system. And I
know in a second you are going to get into some results when you tested this
against a very popular
alternative. Before we do that, we have got another competition here. I would
love to see if
folks know what this one is from. There is another scientist looking shocked.
It is my theme for the
day. Zach has got it. Jurassic Park, good job. I can click that off the screen.
Anna, I would love to hear about this study against OpenAI and the success that
you saw
with the precision reg engine that you built.
So here we wanted to eventually test to evaluate our search against one of the
most popular state
of the art embedding models, which is available on the market, which is OpenAI
ad embeddings,
and which is indeed quite powerful way to provide search abilities. So we
compared them on four
core collections. We created those collections in order to test the search
engine you need.
A set of queries and a set of documents that are relevant to those queries.
So we have used a technique also used by Google to create a benchmark where we
take a document
from a collection, we will sample a passage from this document, and then we
create a question from
this passage. And now we are doing the reverse engineering. We are trying to
find, given that
question, the document that it was originated from. So this document is the
relevant document we are
searching for. Now we have here four different collections. The first two,
Ember and Outlabs, these are based on the knowledge bases of companies, which
have data
that is quite common, not very complex, not very narrow, specific lingo, and
the last two ones
eight by eight and Waters, these are two companies that have
like a more sophisticated knowledge that is less common to the overall average
information on the web. The reason that this is important is because the ADA
embedding or any
other embedding that you can find available is trained on data that is scraped
from the internet.
So it is familiar with the lingo that is common, that is can be found
everywhere. But as you go
into the enterprise, you find more and more specific lingo, specific usage
combinations of terms.
And this makes much harder to use a pre-trained embeddings to get an accurate
search. And you
can see it first of all in the ADA column that the Successive Five, the ability
to find
the top five documents, the correct document, drops as you go to the more
sophisticated,
more narrow, more specific types of text. So here we compare a die against of
our Successive Five,
and we see stable difference, large, and the differences are getting larger,
the data becomes
more complex because we are using an ensemble of search methods and not only
one search method.
And our modeling of data is much, much more flexible than something that you
can get
on the internet out of the box. And this indeed, so we can see here a success,
and we see the complementary, the failure rates. So this is a crucial
difference because as you give
to the generative language model, the one that you want to generate an answer,
the correct piece of
text, the more likely you are to get a correct, clean answer. So this is
basically the benchmark.
Thank you, Anna. That's really interesting to hear about this technology and
how well it's working.
Now that there's this engine behind this knowledge co-pilot, it's really
interesting to kind of look
at the spectrum of folks that this can help, right? Sorry, could you walk us
through all of these
use cases? And I know in just a moment, we're going to get into what these
actually look like
in the product. But if you could kind of show us how every one of these groups
in an organization
benefits, I think that'd be great. Sure. So once you have a precise enough
engine,
really it can provide value across the entire enterprise. And starting from the
left,
we're starting with the case flow. So the end customer, the one who really
needs the solution,
when they're coming in with their issue, whether it's in the portal or in a
chatbot scenario,
we want to be able to provide them with the answer right then and there based
on their
description of the issue. And then the support agent and the support manager,
dealing with
complex issues, enabling them to solve them much quicker, reduce escalations.
Many
escalations happen just because no one knows that this has already been
escalated in the past.
Once you're able to find that JIRA, historical JIRA, and provide that
information, it can remove a
lot of those. And of course, the support aim in general, which is in general to
reduce case
volume and avoid lengthy cases unnecessarily. But then moving on to other areas
of the enterprise.
So in customer success, right, a lot of the same issues come up, whereas you
want to be able to
deal with new and new coming customer requests and issues based on historical
work that you've
done with other customers. So you want to be able to retrieve that information
precisely
based on a context of an account. In IT, very similar to support, you're trying
to solve internal
issues and you want to be able to retrieve what's been done with them in the
past. And even in
product and engineering, right, if we're dealing with JIRA or other types of
issue
systems. So when issues come up, when development questions arise, you want to
be able to really
to know what's been done in the past, how it's been approached. All that
information to get
existing enterprise is many times not very easy, not very efficient to reach
and to find answers
based on. And that's what a very precise engine can enable. Awesome. Thanks for
that. Now, let's
let's dive into what this looks like across the platform, right? There's these
four different
paths to these precise answers to being able to leverage this technology that's
working so well.
Sorry, could you lead us through these? And I'll play the slide jockey here and
we can look at these
four areas and how they help out different groups. Sure. So it's important to
note that the same
engine that out of the scrap earlier, the exact same engine can really power
all these different
experiences. And that's one of the powers is you don't need to build separate
engines to power
each of these. The exact same engine can connect to all the relevant knowledge
sources and appropriately
provide answers to the relevant people, the relevant users, where they are as
they need them.
So starting with the portal assist, I think we already started going through
the slide. So the
portal assist really that the idea here is all companies today, I think have
some level of
a search bar or similar experience in their site enabling customers to solve
their own issues.
But the reality today is still even with Gen AI out there, most companies I'm
seeing are still
relying on a very cured based approach to that experience. And really, the
better way forward
in providing the relevant knowledge and the relevant value to your customers is
providing
them the answers when they need them as they're describing them. And this can
be in the portal,
this can by the way can also be in the case form as they're describing their
issue if you already
got there. You want to not only bring them back a relevant list based on
knowledge, based on
keyword searches, you want to enable them to describe their issue, bring back
those items,
but then be able to provide an actual answer and be sure that that answer is
going to be accurate,
it's going to be precise, it's going to be relevant to what they're asking. So
that's the portal side
of things. If you move over to the chatbot side of things, so again, the same
engine, if you want
to enable a chatbot experience, that's the next slide over. So definitely,
sorry, we have a question,
I just wanted to, while we're still on the portal slide, Chris Raul wants, does
XFind host in a
standard portal or can it integrate into a customer portal like Salesforce
Community?
So thanks for the question. So absolutely, we can integrate into Salesforce
Community, we have
a Salesforce specific widget for that, and we can connect in addition to that
to pretty much any
search bar out there, we're an API based engine, so any search bar can really
connect to us and
get back the relevant answers. And that's actually a good segue to the chatbot
because
the chatbots today, many of them are still built for a close set of issues to
be able
for them to solve. But really, if you're having this chat type of flow with
your customers,
best thing would be as they're describing their issue in the chat to right
there and then
then they're solve that issue, right? Not only bring them back possible items
and have them
have to go and open and redo them, but just bring them the relevant information
right then and there.
So that's another really type of experience that this engine can enable and
again,
and the more complex types of issues as well.
That's great to hear. Chris, another question about,
can XFind integrate into a case creation workflow and help deflect a case which
a customer has
opened? Yes, yes, absolutely. Yes. So that's another integration, not getting
into the specifics of
the user interface, but reading as a, for example, as the customer is typing
their issue,
reading that information, sending that as a query and providing back an answer.
That's another type
of experience that the same engine can provide. Awesome, thank you. Coming up
on this next slide,
we have our third GIF and we're looking at the chat to see who knows it. I'd
love a new,
I think we're going to try to limit folks to just winning one GIF card. So if
anybody else on the
call knows this one, looks like Eliza has it. I hope I said your name right.
Oppenheimer, nice job.
All right, we can get back to get back to business. So this is the slack one.
Yeah, tell us all about
this, Sartil. Yes, so actually what we've been seeing again over the past few
years is a shift
in the way specifically support teams, but not only, I think it's enterprise-
wide,
in the way they really ask questions and try to find answers. Whereas rather
than search a lot
of times, they'll just go to any slack channel that they haven't asked the
question there and hope
the team will answer that. Well, why not, as they're doing that, instead of
them having to go to a
slack channel and wait for a response, you already have all that knowledge in
place across the
enterprise, across all your knowledge sources. Why not power that experience
with the exact same
engine I was describing? I can actually show this in live, this is on support
logic data.
Stop sharing and then you can share. Okay, so this is a slack app we're working
with
in support logic. You just have to share your screen first. It's up in the top
left corner.
Yeah, so if I'll just type in a question again, this can be as complexity as
you would like, but
xfind and then the question press enter and then wait a few seconds and I'll
just come back with
an answer. What's interesting here is that the great answers to the question,
but it's relying
here on past cases. So that's really interesting because it doesn't have to
necessarily work with
a knowledge base, with a nicely organized knowledge base. What we did here is
we took
past cases, indexed them and they're powering the answer. So just think how
powerful that is to
be able to quickly answer questions coming in in any channel from anywhere with
all the
knowledge you already have in place. It really makes the whole process so much
quicker and so
more efficient. That's so exciting. So you've got three different channels for
customers
to help serve themselves, right? Deflect cases, have fewer cases. You've got
chat,
you've got this portal space that employees can use as well. And what's
exciting about these,
and this is a question we had earlier in the week, is that you can take
knowledge sources,
like Atlassian Jira Confluence, and you can limit down with the employees
versus the customers
see. So the employees can see the whole breadth of material out of these
sources and then customers
can see a subsection of it. So it's not just off and on per source, which is
really cool.
Here I'm going to share my screen. We can get into the fourth channel, which is
a very exciting
channel. This is the Salesforce integration, CRM integration.
Right. So what we're doing here is we're integrating our existing widget into
this
Portogix Salesforce widget. And so what we're doing here is a three-tiered
experience for the agent
as they're solving the case, taking away a lot of what's taking agents time
today, which is
trying to search for knowledge and then read through the knowledge and try to
figure out how
that can help them on the case. So we're really doing a lot of the work for
them.
First step is summarize the case automatically. So take all the information in
the case,
subject description, comments, metadata, and automatically summarize that into
a nicely
organized summary of what the problem is, what the symptoms are, what the next
steps have already
been discussed. And then based on that summary and all the information in the
case, retrieve the
relevant items much like we did in the portal. So retrieve all the relevant
items
to the case. Again, our articles, past cases, Jira, whatever, whatever could be
relevant.
Again, that's happening automatically. So now the user did not have to do
anything, the agent
did not have to type any query, did not have to do anything, automatically
summarize the case,
automatically retrieve the relevant items. And then the third step, which is
the most exciting,
is summarizing all that knowledge into either what the next steps based on past
cases, for example,
could be taken, or what the actual solution is, right, that has been already
noted.
So again, summarize the case, retrieve all the relevant information, and then
summarize that information into what knowledge the agent needs to know right
now as he's working
as he or she are working on the case, taking a lot of that load away from the
agents and
enabling them just to work the case and provide the best experience of the
customer.
Oh, we've got a couple of questions from the listeners that I think would be
great follow-up
to what you're showing. Can Slack itself become a knowledge source from Slack
channels?
Absolutely. Yes. So we can take channels that are dealing with certain topics
and index them as another knowledge source. So that is absolutely an option in
Slack or Teams,
of course. Awesome. And then another question that we have here from Zach,
tickets over time, information that gets stale, how does information that's no
longer relevant
get weeded out of what the system is looking at? Yeah, that's another really
great question.
So there's two ways when we approach that, and maybe Anna can add on if you
have any other thoughts.
First is, so time itself can be a signal. So if the further on you go away from
that past case,
we can use that as a signal to it being less relevant, much like the text
itself is a signal,
two relevance, the time can be a signal as well. That's one approach. The
second approach is a bit
more specific to a company, right? Depending on the speed at which the product
changes and issues
come up, we can adapt that signal according to the company specific type of
data.
So for example, some companies, their product doesn't change that often,
maybe once every few months, they'll throw in an update. Other companies is
changing on a daily
basis, right? So you want to be able to adapt the way you use time according to
how that company is
working. That's great. Sorry, Anna. Yeah, another thing that we suspect to
updating. As I mentioned before, we have a very, very flexible ways to ingest
data.
And we are actually trying to index only data that is relevant. For example, if
you have two teams,
and the system is like a new hub, of course, in the system tickets of several
teams, but you are
showing the specific team is working with support logic, then we could limit
the data we index
only to the tickets of that team. Or for example, if you have a product that is
got deprecated and
no longer supported and no longer exists, you get just say us, okay, this is
this product no longer,
we want the previous tickets from it in the system because it will just, you
know, it's irrelevant,
no one will stop supporting it. So the system, the ingestion problem is built
in a way.
It's very, very easily customizable and adjustable. And the period of time we
are looking back
could be very easily changed, even conditionally, like for certain product, we
take three years back
for another product to look at two months back. So we are very flexible about
it. And as I mentioned,
we could also prioritize over time. Again, this is this is a bit more complex
because the time
and the relevance they play some weight in the final ranking. And but but most
of our customers really
doing great with the filters and and the deprecation they define.
That's awesome. Thank you both for for jumping into these questions so much.
And I think we
answered Chris's last question about unconventional data sources. It sounds
like that's a yes on
ingesting non standard knowledge sources. There's a question here from Eliza.
And I think it's a
perfect transition into our next slide. She asks, how many Salesforce agent
assist features do you
offer from this list? So one of the big goals for support logic is to be the
complete tech
consolidation of everything a support operations team needs. It's one of our
main goals for for
the enterprise, right? For for large companies for medium sized companies that
are very serious
about their support experience. This is the suite of use cases that we're
really solving for.
I know there's a lot on this screen. You can see across here that we're
tackling the major high
value elements in support operations efficiency. We've got a full suite of
quality monitoring.
And then in our agent productivity area, we are hitting on many of these same
things of
summarizing a case. And of course, we can update a case in our platform and in
our plugin.
Answering questions with knowledge is a lot of what we're talking about today.
querying records, of course. I'm kind of just looking at Eliza's question
answering these
and identifying the metadata out of the case. What's so exciting is it's really
an intelligence
layer that sits on top of your CRM. So all of your data is pulled out. And then
the sentiment and
the products and the custom fields that you have in your CRM are all brought
into support logic and
used for analytics and for looking at trends in your data and everything like
that. So it's kind of a
real department, the cliche marketing term. It's a real supercharge for what
you have now
in your CRM. And what's great about it too is that it's working now for real
customers.
This is all stuff that works today. It's real world results that you can see on
our website.
So I hope that answers your question. And it kind of gives me a way to look at
this slide
and what we're presenting now with this new knowledge co-pilot. You can see
here how it shows up for
agents. It shows up for support operations. And then also in this new space for
us, which is
customer self service with these portals that Sariel showed us. Just going to
check the chat
real quick in the Q&A before we move on too quickly. So folks, getting into one
of our final slides
here, you can see here that the knowledge co-pilot is really an enterprise
grade solution built for
both support teams and customers. And you can see that this is why. Right? This
is a precision
rag engine that is built for the support domain for complex B2B support and
implemented successfully.
If you go out online, you're going to see that there's some precision rag do-it
-yourself
options out there that won't get you the same results that this does. It also
helps you leverage
the messy data that you have. So you don't have to come in with a completely
formed knowledge base
of articles that are being maintained by a team. You can leverage these
different inputs,
which is exciting. It also gives you very robust answers. So it's beyond just a
list of
search results that you have to kind of look through and determine whether or
not there's
anything right in there. One of my favorite parts about this is that it will
tell you if there is
no answer, which I think goes a long way towards establishing trust with the
people who are using
these systems. I'm sure we've all encountered search systems over the last 20
years that we
don't tend to use a whole lot because they don't actually give you good results
and so you can't
rely on them. Of course, Google will always give you a great result, but a lot
of homegrown
systems, a lot of internal systems aren't built with that same kind of resili
ency and always bringing
together a great answer. And then on top of all that is back to that tech
consolidation piece,
where this is really removing the strain on your IT resources. This is a
business partnership. This
is a fully managed solution that's part of the support logic platform. Sorry,
you'll
do you have anything to add on these? I saw, Cheer, last point. I think one of
the really
points we've been hearing a lot is consolidation across the AI market in
general and support specifically
companies really are saying if I'm purchasing an AI-based solution, I wanted to
provide,
and this goes to Eliza's question as well, I wanted to provide as much value as
possible,
why do I have to deal with a whole bunch of them? And that's what really
support what
logic is doing is enabling the whole thing under one roof. And yeah, going back
to my point earlier,
a lot of companies today are thinking of it as a builder by the whole AI, gen
AI
idea or the trying to build possibly their own internal solutions, assuming
that they know best
their knowledge, which is true on the one hand. But then on the other hand,
really developing
a robust solution that can really provide value. I hope one of the things that
came across
in this webinar is that it's not as simple as you would think, especially not
what we're doing with
the level of complexity of many of these companies and their data. So it could
take a whole lot of
time and then still not provide the results. This really requires knowing what
you're doing on a
very deep level, especially on the search engine side, but not only in order to
build this out correctly.
Yeah, awesome take. Folks, thanks for joining us. We've just got one more slide
. In October,
we're going to be holding our first SX Live in person conference event. It's
very exciting.
We've got speakers from around the industry coming in to talk about AI, to talk
about everything
going on in support. And there's some real benefits to coming into San Jose and
attending this conference.
You're going to hear how folks are using real world solutions to improve the
customer experience.
You're going to be able to connect with your peers, industry leaders, folks
that are really
passionate about support. You're going to get the chance to get inspired by
these new ideas,
and you're going to grow from this kind of immersive experience. Day one is a
training day,
October 7th, and day two, October 8th is a full day of a single track of
presentations and
fireside chats. And so I invite you to jump on SX Live.com, reach out to your
customer success or your
account executive and join us in San Jose. Sorry, Alana. Thanks so much for
joining me today.
Folks, I think we've answered all of your questions. We'll have a recording of
this up
today, and we'll email it out to all of you. I can see here in the chat. It
looks like it's just
kudos all around. So thanks everyone. Have a great week.