We will dive straight in. So today's webinar is covering how winning teams set up content libraries hosted by me, Jasper Cooper co-founder and CEO of AutoRFP. Did many years in, in the RFP mines myself so this topic is a really interesting one to dive into. A particularly complex one, and one that I guess there's no real content online about this of a reasonable quality. There's a lot of like high-level blog articles, but nothing that gets into the nitty-gritty of how this set, how this is set up at different companies around the world. So today, just a bit of housekeeping. Webinar's recorded, so we'll s- share this out after. There'll be an email follow-up. All of the materials that we cover will be shared as downloads and slides as well. Chat in Zoom there, and then we also have a dedicated Q&A panel, so that'll be great. If you do have q- questions, then drop them in there. We'll try and address them as much as we can at the end. But our goal is today that you walk away, every individual on this call, customer, partner, competitor, whatever, you walk away with something actionable.
This was sparked from the research that said that it wasn't AI use that necessarily determined whether someone was going to be in the high win rate cohort versus the low win rate cohort when it comes to RFPs won. Customer insight was the strongest and we're talking a little bit about that, but ultimately, it's actually content automation is what we're gonna focus on today. So whether you use AI or not content automation rate was more important than that difference between winners and losers per se. Today's agenda, we're going to diagnose that. Set down what is that maturity curve? Where maybe do you sit on it? And what's actionable today for you immediately to move up the knowledge architecture maturity curve? Then, how do you build against that? So we'll give you some blueprints, some resources explain some of the important concepts there, and then ultimately talk a little bit about automation how that's achieved, and ultimately what the future of this also looks like. Today, would love to have a quick idea of what chats people are on at the moment.
So every team globally has deployed or is deploying a chat at this point. ChatGPT Enterprise, through Claude, through Gemini, through Copilot. Would love to get an understanding of what chat endpoints people Quite a bit of Copilot. Reasonable amount of Gemini in there. Claude. Okay, we've got a, we've got a pretty even mix. Okay now the Claude's really coming in. Yeah, Glean in the mix as well. Cool. We'll touch on, we'll touch on Glean today a little bit as well. So everyone's deploying these. And then the next question I have is understanding where people are at on the knowledge architecture maturity curve. So quite a mouthful, but the first level there would be tribal, right? It's just in people's heads, in different docs. There's not even really a formal place where knowledge should be stored or even a topical place where this type of knowledge should go here or this type of knowledge should go here. So that's where really every organization starts one day, and then you end up getting multiple tools and fixes for this, right? So some information might need to be in SharePoint, some information might make sense to be in Confluence or Notion or a tool like that.
So it's in multiple places, and you've got some idea of where it is, but it's not necessarily anyone's owning that tool or content within it, so it could be duplicate, it could be stale. Then we've got level three which is you have known sources for things. So it's known in the organization that the technical documents should sit in Confluence and all of the commercial stuff should be in these folders in SharePoint. There's some idea of an owner, great. So the… there's a person on our engineering team who looks after this content. There's someone on our legal team that looks after this. And there's some sort of cadence to that. So they're meant to keep it up to date, and it's meant to be reviewed at least every three months, every six months that kind of thing, or they're updating it live as things change there. So that would be a level three known sources, as we're calling it here. Then you get into structured knowledge bases, where it gets a little bit more nuanced, where you start to think about categorization, hierarchies dimensions, we'll also cover today, but basically organizing that
content a little bit differently. So it can maybe even sit across different sources. So it might sit across SharePoint, it might sit across Confluence, but you've got an idea of the categorization. And that's not just something that kind of has been applied based on rule of thumb and over time, but something that someone's actually thought about and been structured in a good way, the terminology's been thought about and et cetera. So that's where you'd be at level four a structured knowledge base. Then we get up to semantic knowledge base. So where not only do you have everything underneath that and you've structured it, but on top of that, you are doing a semantic search across it. So we'll talk a little bit about that as well. If you're not across semantic search, don't worry we'll break that down a little bit. But that would be the next level being able to not just have that information structured, but also be able to AI search across it. And we'll also be talking a little bit about like level six and where we see level seven going today because ninety plus percent of organizations
right now are on the semantic layer and putting the chatbot on top of that. So we'll step through how quickly you can get there, what that actually looks like and then we'll progress on to six and seven. I think a lot of people on this call probably at least at level four, but interested if you, yeah, drop in the chat what kind of levels people think they're at, or maybe if you think you might be at a level six or seven, you can place that bet now. So as you throw those in the kind of key problem that's always existed in the industry is one question, three answers, right? And this has just been true probably since the start of civilization. You ask one question like, "Do we support single sign-on?" Or "Do we have a support team in Europe?" Or whatever that looks like. You ask that one what is meant to be a simple question, and you end up with three plus different answers, right? So if I ask, "Do we support single sign-on?" I'm gonna get something from our marketing site maybe that says, "We connect with the three major providers." No idea which ones.
Wrote that a while ago. So I don't know, maybe I'm asking specifically about do we support Google sign-on and marketing's not being very helpful there. So then I search again and there's some developer documents on… It's a work in progress that's upcoming in a release. It's okay, great. I can ask the owner of that document. Oh, that's just a scoping document. I'm not sure if that went anywhere, right? It's just internal. Great. So back into the beehive and I can find another document. Yes, we support all of Google's SSO options, including advanced provisioning, blah, blah, blah. And then I look into that. Oh, that salesperson that wrote that was let go for lying, right? So there's so many different problems across all of this different content, right? And then we ultimately end up in a Slack thread or on Teams messaging someone probably too senior to be dealing with me. And they come back, "I said this in the last company all-hands. We've put everything in X system now." They link you, and then you go, "Great," "can we add this to a content library, or can we have some sort of process in order to stop this from happening going forward?" User leaves the channel or you never get a response.
So it's been a real problem because knowledge is such a vast thing. Really any white collar type company, the real thing you're doing is buying and selling knowledge. That's a lot of it. So for one person or a small team of people to be able to manage the knowledge of an entire organization is a, is an impossible feat nearly by definition. But obviously that's what the session today is about is how do you tackle that the best you can and how are the best in the industry actually doing that? So that, that broken process comes down to things like thinking that you can resolve this via constantly building a library forever, constantly working on it, or constantly next quarter, we're going to fix it up we're gonna continue expanding it, we're gonna keep growing it, et cetera. By growing it forever, it becomes an infinite task to maintain. The bigger it is just like a code base the more lines of code you write, the worse it gets over time from a maintenance burden perspective. The same… So that's the maintenance burden, and then constantly chasing subject matter experts as well. So your subject matter experts more often than not are not going to be
knowledge base management experts. That's not what they do. They do something else. Maybe they support your customers directly. So maybe there's a customer support or help guide system that they provide content into or client portals or client documents. There's places that they are working that is not necessarily meant to be a knowledge base or used for that purpose. So by definition of asking for them to come into our environment and contribute there, that's making it hard for them, and that means that they might not participate, therefore, we're constantly chasing up the subject matter experts to get them to do this double entry chore as they see it, which is not their primary job. So puts us between a rock and a hard place for sure. And the economics of this is just against us, right? Is that content management has an infinite long tail. So when I receive a, RFP, DDQ, security questionnaire, whatever it is, there's always the head of usage. There's always all of the stuff, the eighty/twenty, where a lot of this stuff is gonna get used over and over and over again. It's great. Probably should maintain it, continue to improve the level of that content.
But then, of course, you have the long tail, and it is infinite, and we just see more and more questions every year tacked onto that long tail. One one year it's like a bunch of ESG questions. Next thing it's AI, security, et cetera, and it just keeps building, right? And that long tail really will go forever. Some people have very different procurement questions to others so that long tail just keeps spreading out. So that means by definition, we also have a point of diminishing returns when it comes to actually managing that content. So in our context, we've worked with teams that have quite literally had a million-dollar budgets for managing content alone. So not even just the RFP team, but the people managing the content, they're spending a million dollars on their salaries to get this done. And then not really able to crawl, like crawl this cliff. After a certain point of time, it just doesn't matter how much money or people you put on the problem, there's no way to resolve it fully to 100%. That long tail is always gonna be unmaintained, so you need to find a solution for what do you do when things on that long tail are out of date.
You need to be able to make a trade-off there rather than thinking that you can continue to push it all the way to the end of the long tail So a question is how do winners actually approach these challenges? Because fifty to eighty percent of every response like across the market is still has some level of bespoke response in it. People aren't just auto-filling RFPs. They're trying to get an angle. They're trying to add customer insights, et cetera. And that really is the game now. A lot of the boilerplate automation you can do. So yeah, how do you make it more bespoke is one thing, but also the reason that they're doing a lot of bespoke when you dive into the research is because there's a lot of this long tail element to it. So the winners, so people that have a higher win rate are in that cohort are more likely to have a higher automation rate as well. So there is a correlation between those that have fixed this problem and have a higher win rate. So it's not that people that have a higher automation rate are losing more because they've got a structure that copy-paste.
No, they're actually winning more because they've got their content in such a way that it is actually highly reusable and of a high enough quality that, A, they can trust it so they can approve it quickly, but B, their customers are receptive to it, more receptive than they are to their competitors' content even those like losing the opportunities. So I'll jump in, but the truth is contextual and temporal is an important element. So to understand that there is no such thing as a single truth. There are many contexts. Truth can change based on a context. Maybe you're selling in one region where something is true, and then you're selling in a different region and actually something else is true. Maybe you're selling one of your products or services and the answer is yes for this, and you're selling a different product or service and the answer would be no. So it isn't like you can just have one question, one answer, and it can be as simple as that. You need to think about that contextual element, and there also needs to be the temporal element. Things change from yes to no over time and back to no.
So they… You need to be aware of that and that things change. So it's less about trying to build that single source of truth and more about thinking about who's gonna ask a question, in what context they're gonna ask it, how and how often are they gonna ask it when. But let's get into the more tangibles. So the first thing to do in any exercise of building a great knowledge architecture is just understanding first and foremost, really zooming out and thinking about where the truth could be. And really zooming out here. So public-facing documentation, there's obvious stuff like the marketing site, help documentation, like sales documents that you're sharing. Those are things that external parties that review your RFPs or your DQs, et cetera, already have access to, so they might even validate against it. So if those sources are gonna be used by your customers anyway, definitely something to consider using as part of your RFP response process. Also, you wanna think about maybe there's sources like SEC filings in some cases, or maybe you're part of a listed organization and there's annual reports that come out.
Maybe there's even internal board reports that you might not share externally, but could be a great source of infor-- of information. So really collect all of those. Same with the internal only. Are there different knowledge bases that different teams use for different things that are hidden away that you might not know of? Is there an internal roadmap system? So it's not really content as you think about it generally, but it is, maybe Asana has your roadmap upcoming items, things like that, that you're often relying on but you haven't thought about knowledge or content. You haven't thought about it through that lens before. And then finally, customer context, right? So things like meeting transcriptions are super common these days. Joining, transcribing it all, where does that ultimately go? And then, of course, your customer relationship management system and other systems that sit around the customer context, which is generally very separate to information that might span your organization and products. So map that out, and then also share that map with other people on the team so you can see if you've got any gaps, if you've missed anything So once we
know what those sources are, a few examples here, you've got to think about a little bit what they actually contain. What value is in there, and maybe is there risks inside of that information as well that we wouldn't wanna ever pull through to an RFP response or would actually just cause more problems than solutions? Also, how authoritative is it? So is there a true source of truth for certain things? And for certain things there is, and for certain things there aren't. For example, maybe there's security policies, and ultimately everything in your organization should come back to those policies. That means your source of truth would be your security policies, but maybe you have a second layer on that, which is your security frequently asked questions, right? That are meant to be in sync with those policies, but policy is the ultimate source of truth. So you can think about it through layers. So for example, maybe for our roadmap that is stored and managed in real-time and linear, and then we update that in SharePoint, and then maybe provide that to customers externally via Notion. So we can think about that in its various different layers.
And then finally, the different contexts. So even within one of these sources, we wanna start to map out the different areas. Is the US team using something different to the UK team? Are they storing their answers in different places? Is different products happening in different places? And this is quite a big task, but once you start to map out all of these systems and think about it at this abstract level without trying to apply instantly start with the solution and actually just define the problem first, this will give you a really great map of all of the different sources that are available to you and a lot of the thinking and context around them. So a few tips on what's actually dangerous what you wanna keep out. Things like stale knowledge. Generally find there's a huge drop-off point after the twenty-four month part where it can hurt more than it helps. And that is because you're trying to cover the long tail, of course, for for a very long time, and you might wanna source those other answers out. But generally, depending on the organization or depending on the type of information, things that are twenty-four months old can be more
often than not incorrect or even have a very high, wrongness rate per se. Maybe twenty percent of the time that you're getting one of those previous answers, it's now out of date. And even though that's your most recent source on the matter, it is no longer correct. So it's just thinking about it through those lens, like which sources would actually be up to date? What kind of date schedule makes sense for each of those sources? Maybe Slack, it should be very recent, or Teams, it should be very recent versus other sources that are much more authoritative. And then hyper bespoke materials. So a lot of teams, they want to boil the ocean, upload absolutely everything. But you also wanna watch out for things that were really once-off. They were built for one customer. Maybe this type of document was tried but never widely adopted by the team. You really wanna archive that and take that out of the loop, because if you end up with all these different types of documents, all those different types of knowledge, all of this knowledge legacy in the architecture, it makes it more complex than it needs to be, and it brings up specific information that's just simply no longer true or just hyper contextual and shouldn't
really be reused outside of that context. So your largest enterprise customers, for example once off, if they're ten times bigger than your next biggest customer, that's the kind of thing I would start to think about separating out. And then internal noise, language, and jargon. So if you are gonna pull context, particularly from internal communication tools or think about that, you really wanna be careful about the channels that you pull through, what kind of content actually lives in there across a long history of it. And other edge cases are things like, let's say you actually sell a legal product or a security product or something like that, and you also internally have legal or security policies. AI, in particular, is gonna have a hard time reasoning about what is external and what is internal. So you really wanna reason about that up front and have very clear lines there and even call-outs going, "Hey, for us as a company we really need to make sure that we're separating these concepts external and internal because it's confusing."
So now that we've got that and to think through that authority, you have your authoritative sources, we can think about those fallback sources, and then there's very specific sources. So that's the three buckets you can put them in Cool. So next, let's talk about organizing the content. So now we have a really good idea of all of the different sources that we need to organize, what's included in them, level of authority, some of the risks of bringing that kind of content in. And next thing we wanna do is organize that. And conceptually, that could be very simple. So let's like use a case here. So let's say you're a software company, you've got two products, and you sell into two major markets. And you can maybe try and map this to your own company and what might fit. So let's say they're two-- they have two products. They have a security platform they sell, they have a legal platform they can sell, and they sell it mostly in the UK and the US, but it's also
maybe just broadly available globally And most of the time they are selling just the same products over and over. But there is two modules within each product, which means under certain circumstances they might just sell one product, slightly changing their answers in some cases. So this would be pretty typical of a very simple organization. Many of you on the webinar today I know have, tens of different products at least, and tens of different markets in which you operate. So it's much more complex than this. But let's just imagine it's this simple example just to show you how off the rails even this can become. So simple enough, right? And this is the system and the con- the concepts that are really failing the industry at the moment is that we would just take these two products, right? And then we would start by putting them in in that's product A legal, product B security. And then under that we have our categories, and then we have maybe subcategories, and we have our two modules that are rarely used, but we'll put them in the hierarchy here Then you deploy this and you'd start to get questions.
What about stuff that's country-specific, right? So it's only true in the US or the UK. If we're constrained in this kind of model, then we need to start adding folders. We need to add one for contracts US, one for insurance US, but also, of course, for the UK and for insurance UK. So now we've expanded and we've added a bunch more folders for each of those modules. Could be tags depending on what system you use, but basically you're adding a bunch of different options there. And then you go, but there's a lot of stuff that just applies globally, and I don't want to put it in the US and the UK folder for each module. So then you start to create, okay we're gonna need global folders in that case for everything. So then let's add those in there as well. And then by the end of even this very small exercise, you have quite a complex hierarchy or categorization with many different folders. And if I want to filter to content that's relevant maybe to selling both products in the US, I now have to tick, eight different options and select that content to go forward.
So this kind of applies in different ways, right? It's complex even just to visualize or think through. It's complex if you're trying to move to a self-service RFP or DDQ model where you expect end users to jump into the system, simply select what they need to sell, and then generate the responses based on that content. So it's really adding that huge level of complexity. So a lot of the migrations we do, we end up with people moving from systems where they've done this, and they have immense hierarchy, sometimes a thousand tags, sometimes two hundred different categories and subcategories, one-dimensional, and then it basically looks like this. And then you get really hard questions like, "Oh, we're adding a new product. Does that mean I need to add four more categories?" Yes, in that kind of approach you would. Do I need to duplicate content if it's the same across two, two different products? Yes, you would. Would you… What happens if you start to sell when I sell these two products together, actually, just when that's a possibility we have a special
feature that you get when you buy both. That's also quite difficult to do. So there's just so many different issues with that old model of just having, just thinking about things through categories and subcategories only. So one of the concepts is you break your categories from one dimension down into multiple dimensions. So what that basically looks like is before you would have a list, and these would be stacked vertically here, but you'd have product A, and then you have all the different folders we've created, and then product B, and then all of the different folders there that we've created. What is much cleaner is rather than having all of these 12 is simply creating two different dimensions. So one you have it based on region, and then one you have based on the products. And this allows me to do some pretty interesting things. One, it's a lot less complexity, so there's way less options here in total. It means it's less clicks, it's m- less training, it's less
understanding, it's less terminology. It's less everything. And what that allows me to do is now have that content, rather than save it in a very specific place, I can basically use it inside of this hierarchy and use UK and insurance. So let me explain that a little better. So to make use of this kind of hierarchy, you wanna think about concepts a little differently than you might have in the past. So you don't just wanna store information necessarily in one location or one folder, but actually think about it in multiple. So rather than before we had contracts UK or insurance UK here, we can actually use this type of dimensional hierarchy to select UK and contracts at the same time. So it's very clean 'cause then I can click on UK, I can see all my UK content. I can click on contracts, and I can see all my contracts content. But then if I wanna make it specific to UK contracts, I simply select both, right? And then you can visualize that. So that's really the power of having many selected rather than just
thinking about it in a classical folder structure like you would maybe in, in a Google Drive, where you put it in one fi- you put it in one folder only. Then I know that I need all of these different folders with all of these different combinations. Rather than that, I could simplify that hierarchy and have that single piece of content available in multiple locations. The next thing is not constraining yourself to just categories and subcategories, but actually going all the way. So having multiple different layers of nuance just gives you more flexibility on certain things. So for example, if you go down to a state level in the US, you might wanna go global and then North America and then United States and then California. You don't wanna try and suppress that and end up with global and then North America hyphen United States then North America hyphen United States hyphen California, right? You wanna actually do that like that. And then finally, the thing you can do with these hierarchies that I think
is lesser thought of is when you have a hierarchy, a lot of people think about saving it at the end point. So for example, if I see a hierarchy like this, I would save my content maybe under California, and then I'd have to have every other state. But what we've found is way more optimal and just easier to conceptualize is you have information saved at the higher levels as well. So you can just save information, the entirety of the United States, North America or global, and you really try and push all your information up. So you go, look, a majority of our information applies at a global level. There's some information that should sit at North America, and then very tiny parts of information that sit at the very specific California level. So this gives you the highest leverage on your content with also a very simple hierarchy On the other side of this, so those concepts give you some time with… It takes a-- it can take a while to get your head around this, but this kind of fundamental change is something that unlocks a lot of opportunity for you to be able to manage, yeah, much more complex content much more easily and
simply once, once you've unlocked that. Then on the other side of things, don't build structure you don't need yet is a huge call-out. So don't model what you don't sell is another great one, particular to the RFP case. If you're not actually coming up against a problem, don't start to build out folders or hierarchies or tags or whatever type of system you're using. It's really good advice from people with extremely large content libraries to not build it out before you need it, but instead actually lean way too simple and then build it up over time. So here, we just start with one folder and then go great. It actually does look like we need to split it into two markets. Great. Do that over time, and then budgeting the time for that upfront as well. So rather than doing one massive project where we're gonna figure everything out, we're gonna optimize it all and think about everything we're doing in the future today, be realistic about it, keep it super simple, come up against those things, and then build them and split test and iterate over time.
It's a hard thing about hard things is getting that done. Cool. So in, in that type of setup, that means that you can add new products by simply adding another category to that hierarchy there. You don't have to duplicate content because now you've got that concept of saving it under multiple places, tagging it with multiple things at the same time. Doesn't just need to be in one place. And if a law is passed or something changes, you can just add that very specific next level, next layer down. You don't have to restructure the whole thing. It grows and adapts with you much more easily that way if you don't constrain yourself. And it solves a lot of other issues that happen downstream as your content library grows and changes over time Terminology also super underrated in terms of thinking about this. So you want to name things in a way that's accessible to other people. Generally, as a content manager, as a bid manager, et cetera, might have
been at the organization a longer period of time, but you might also just know a lot of the terminology. Assume that a lot of people in the organization don't know that terminology, and you can mu- much more closely stick to things like marketing terminology and more common internal terminology. So when you build a hierarchy that looks something like this on the left, that's not going to be great. It's not gonna be accessible. It's gonna make it harder for your SMEs. It's gonna make it harder for everyone to engage with, even though it might be easier for you. So think about that and try and make it as plain and obvious. Like this is the real hard thing here, is that simplicity is much more difficult than complexity to achieve inside of content management. So try and make it super plain, super obvious. Try and use words that already exist in the real world and are very commonly used. Try and lean away from acronyms. Try and lean away from niche terms that might be used by company insiders, but not by new joiners that are trying to navigate your content
great. So to, to recap there, you can then categorize each of your sources by dimension as well. So when you think about SharePoint, you can't just put that in one big kind of area in your brain, right? You wanna go maybe by space, by page, by Notion folder, by Notion page. Whatever those systems are, you wanna think down to that level. Which ones apply to what? So maybe we've got a UK pricing page. Great, we're gonna put that in region UK, and maybe that's for our security product. Let's put it there. And same for this, and same for this. So we can make sure to think about that at a more granular level. And it really m- some people maybe think that, "Oh, this entire space is to do with this." Really look at the space, look at the pages contained within it. Make sure that what you think is within a particular content area actually is. Do those quick audits, double-check your work And then finally, the defining ownership and review cadence. This is a super hard one, but some good rules of thumb here are
that ownership by team is better than ownership by individual. So seen many times where you assign an individual as the owner of content, and then of course, that individual changes roles, leaves the company, other things, and they basically can't update that content anymore. And you don't necessarily know. Some people find this out even years later, "Oh, HR never told me that this person left the organization, therefore, all of my content has been out of date for two years," right? So you want to assign it to teams, to functions, not to individuals. So that's a really great step when you think about ownership and building out those structures. Those don't even have to be real teams within your organization's hierarchy. They can just be the way that you think about it from a content perspective. Obviously better if it's super simply mapped to the organization's hierarchy and set up and your internal team names, but more often than not, it doesn't. So then you need to have some sort of abstraction where you go, these people on maybe these different teams can own this content.
And it's also great to have not just one owner on that team, but actually multiple owners on that team. Yes, both for them changing roles, but also just to have higher capacity. So if I need to review all the security documents every year, maybe it's much nicer to spread that workload across three SMEs rather than just the one and kind of make that fairer across a team. Then you've got your review cadences, and you wanna make sure that they make sense per topic. See a lot of companies do things like, "Oh, we'll just do it every year," or, "We'll do it quarterly." You don't wanna do it arbitrarily. You wanna think about what actually changes quarterly, and let's do it quarterly there where it matters. What is the risk of making that quarterly every six months? What is why are we doing it annually? Things like that. You wanna make sure that each different content area or different sources are treated in a different way to take pressure off your SMEs as much as possible, where that's important and really thinking about that. But then also on the flip side of things, making sure you have the most accurate up-to-date information where that is really important.
And then finally, having the concept of once-off knowledge. A lot of knowledge is disposable. It just simply shouldn't exist after its expiry date. So making sure that you treat knowledge that way. You don't arbitrarily go, "No, this is gonna review annually." You go, "No, look, this is going to end then, and we're probably not gonna use it from then on out. So by default, I'm gonna expire it, reducing the size of my overall content library, and therefore the maintenance burden." One of the resources we'll have to wrap on this and give you really actionable next steps is the RFP content library checklist. So it'll take you through these examples of, yeah, mapping out your sources, selecting owners, et cetera, et cetera and driving up this part of the maturity curve as fast as you can. So that's level four complete. That's a lot there. So knowing your sources and their authority, mapping your content in, defining the owners and reviewers, creating these flexible dimensions and hierarchy and sharing that understanding with your team as well. So once you've found the sources, share that with the team to fill gaps.
Once you've defined the hierarchy, share that with the broader team to find gaps, maybe ways to simplify terminology, et cetera. More often than not, you really wanna try and guide those outs- external collaborators that you're bringing into the process, not on how to make it more complex and add things, but actually how could I try and simplify things or cover more things under a simpler setup. So that's how you can bring those other teams in while setting expectations that you've got a particular objective in mind. Cool. Now we'll move on to, great, we've done all of that but it's still very hard to find things, it turns out. So even if we're maintaining all of our content, it's up to date, but there's still a lot of different content sources. It's constantly flowing through. How do we actually find things in all of that noise? So that's where we get into semantic knowledge bases. So this is sometimes just referred to as AI search. But let's talk a little bit about it. So different systems that you use will have different search technologies.
So something… if you use Notion they have a very high-quality AI search. So that means that you can put a query into Notion. They've got the new agents. You can type in there. It's searching by meaning. It's very easy to find things in Notion relative to maybe if you've ever had the pleasure of searching like a Google Drive or a Confluence, a lot harder to find things. And then finally other systems which may not really have any semantic search or be built for search at all, but you're using them. So maybe things like Slack, it can be very hard to find things in or email, et cetera. Some systems don't have semantic search at all but will actually, yeah, have… require very specific keywords or even filters and things like that, making it near impossible to pull the data out of. So this is one of the key problems with actually finding things in an organization is all of these different search technologies that you're having to rely on across sources. So that's where it's but my Claude fixes this, my ChatGPT, my Copilot
fixes this 'cause I've integrated my Notion, my Google Drive, my Confluence. I've got it all set up. So it's connected with everything. It's got the little green ticks there. We're good to go, right? But no, that, that's unfortunately not how it works. It is in this case for Notion, right? If it's got a great search technol- technology and their connectors use that, then that's awesome. That's gonna provide good semantic search results. But a lot of the tools that exist and, the thousands that are available now via MCP but also direct connections are going to vary quite a lot. So although some of your knowledge, as we've discussed, might be in a system like Notion, maybe a lot of it is inside of a system like Confluence, and we don't just want the AI to search Notion all the time because that's how it most easily finds things. We want it to find the right source, right? The most up-to-date, et cetera, et cetera. And it might not even be able to find that source at all if we're just relying on the tools themselves. And this is quite the gap at a lot of companies right now doing these large
scale deployments, and it's the next wave of those deployments is sending teams out into the world to try and figure out how to solve this because some companies are having great success with this approach immediately based off their stack. Others are having a very hard time. They have basically amplified the problem they already had. People are getting wrong answers, sending them to customers at scale. It's causing issues. And those those problems aren't easily surfaced, right? The AI chatbot's just coming back and Claude or ChatGPT's going, "Yes, we do this. Yes, we do that. Yes, we do this." And it's not necessarily true or in context of the question. And it's also very slow. So finding people sitting there and researching and it taking even longer for Claude to load away in the background on that, searching Notion, then keyword searching Drive, then finding another keyword and then putting that in, and it's just very laborious. So- those are the two different kind of search types is, yeah, a basic keyword search and a semantic search, which searches on meaning using AI, which is incredibly powerful.
And basically to recap there, some people are running this their AI agents on top of a, just a keyword database, which is making it easier to find things in a way, but also it's not capturing all of their knowledge or reconciling it correctly. Semantic saves a lot of time and is able to pull all of the results much more reliably. So if you're on a keyword search-based system, you might wanna consider something like building those keywords that are important to your organization into prompts or into skills. So basically giving the AI, "Hey, here are the keywords that you would need to search in Drive to more accurately find and surface things," so it's not spending so much time doing that, and it's able to, not all of the time, but hopefully more often, pull up the right content by searching the right keywords. So giving it that, and then also on the system side of things, taking more time to standardize terminology and using more keywords across your, for example file names.
That might be a really helpful one to add that new layer on top of. And then on the semantic layer, there's things you can do implement Glean, and Glean has some great technologies around embedding and basically turning some of these applications which don't have the greatest search and actually enabling a semantic layer on top of them, so they're much easier to search. And similar technologies are being worked on, don't know how good they are or not, but across things like the Microsoft Graph to embed the knowledge there across the 365 suite. So moving that from keyword and then giving you a semantic layer on top of that. So that's super useful for your agents. But the thing at the end of the day is, yeah, so the AI is not created equal, right? You can add your AI on top of a structured semantic database. You can have much, much better results than you are with your AI on top of a disjointed set of databases, some of them relying on keywords and some of them not. And I believe this is one of the core things that makes it so when we survey people, the AI use, just as a tick on or off binary, is not a differentiator in
terms of your win rate because people's experience with AI, depending on that foundation, is very different, right? Some of them are sitting there for five minutes for an answer to a simple question, getting what they think is a hallucination. Others are nearly immediately getting the right answer directly out of their system. That's a very different ultimate outcome using the same technology. On our search project and how we did this for AutoRFP customers at a technical level is we built integrations with every major knowledge source, so like Confluence, like SharePoint, like OneDrive, et cetera. And rather than rely on their search technology, we actually replicate the content within a specialized semantic data lake. So basically, we take that knowledge that has not been searched in the best way it can be, pull that across into our own managed infrastructure with the AI search, and then we can unify that.
So great, now when our agent goes and looks at that information, it's no longer going, let me search." It's just doing one search, and the information it gets back is actually unified. So it looks more like this. I can plug in the chat into AutoRFP. It's already built those connections and synced in the content recently. And then another benefit of having that single tool, that single interface or single database is that you get the structure and hierarchy as well. So you're not just getting different kinds of setups from different kinds of tools. The AI is seeing one unified approach to structure, and that makes it a lot easier to reason with because if it's looking at, okay, I've got this document from Drive that's in these subfolders, and then I've got this in Notion and these and this in Confluence in this area, and they do have conflicting information, that can be quite hard to resolve for a human, let alone a large language model trying to work with all of that context. So by keeping the context clean and on one kind of layer or, having similar
terminology between those systems, that will help the AI reason better through those more challenging answers. So yeah, ultimately what that looks is you can have that one connector and turn that on versus having all of these connectors. So if you can build something like that's great. And yeah, Glean and others provide a similar semantic layer more broadly and horizontally across an organization. So yeah, a lot of approaches to that Also dropping a workbook there to just talk about the content searchability how you can set that up, and particularly if you're working with some keyword systems, how you might rename files and establish structures there to get better results. Either, you're actually just searching things in Drive and you just wanna find some things for those of you that are doing that manually on those platforms all the way through to, yeah, you've got agents plugged in, it'll make it easier for them to search as well so that's the semantic database layer complete. So unifying all the sources, searching by meaning now and embedding those
pieces of content across the dimensions. One question now can return that, that answer. So we're most of the way there. Now it gets quite interesting. So now the agents can definitely find, a lot of the time, the relevant information. What is hard is conflict resolution, where it gets a little bit tricky. So you have all the content, but which is correct between different contexts? And how people went at this for a while is they were building AI systems that check the conflicts The problem was, is that there is so many conflicts, right? There's technically a pricing conflict, let's say, every time you send out a new proposal. Maybe you've given a different discount rate, et cetera. Has the pricing model changed? Do we need to check that? Do we need to adapt that? Technically, every year we say last year, now everything needs to be two years ago every year that progresses. So there's just a lot of different conflicts that come up. So then we don't wanna surface those ones necessarily, but
we wanna surface certain ones. You end up with this infinite queue where the AI is raising a bunch of issues to you, and then you're manually resolving them. So that is, is quite a struggle. And you're clicking, yeah approve. And again, it's that infinite long tail. So this conflict resolution queue could be infinite. And you can kinda chip away and try and automate that the best you can. But what we've moved towards and where we think it's going is the rational knowledge base. So not only having that semantic layer where we can search things, but actually codifying in the agent in the way that it searches, in that search pipeline, how it should think about the different sources that it's pulling from, how it should prioritize, and how it should actually resolve those automatically. Which way it should lean on, on different tasks. So things like, "Hey, this source is most recent," of course, is like the most basic version of this. And then you've got which source is most authoritative, and then
which source is most contextual. So how do we start to work that into that agent layer that sits on top of the semantic layer? And how can we make that more and more accurate, more and more trustworthy, so it knows who's asking, in what context, and when, and can actually provide that ultimate answer? So I'll just quickly jump in here. So we have the hi-hierarchies but this is where we get to these types of settings. So things like, okay, when we sell different products, do we wanna filter by that so the agent is only seeing things that are relevant in that context to that particular product? Probably. When we sell in different regions, do we wanna do that? Maybe not. Maybe the agent is allowed to prioritize stuff from the UK over the US, but we don't mind using US content where no UK-specific stuff exists.
So basically building in these different concepts actually into the agent layer and having it prioritize automatically for us and resolve things. So here, for example, it's going to prefer the, Correct region for that customer, therefore it is gonna use that answer. And that might even override things like, okay, this one is one week more recent, there's no factual conflict but we are going to use the older one in this case because it is from the correct region rather than just simply the most recent one looks correct. So it can start to understand that a little better and on the fly. And rather than having to tell the agent absolutely everything about our organization, how we do everything, giving the agent that kind of context at the exact time it needs to resolve that type of conflict. And then the different priorities of content as well. So maybe your content library is the number one thing, you always want that to weigh very heavily versus past projects versus documentation.
Or maybe you want your documentation to be the absolute source of truth, no conflict should survive that, versus previous projects, you really don't wanna weigh on those. You just wanna use your previous responses to things as the long tail to try and pull things out, but you don't want to rely on it or weight them if you don't have to at all. So rather than sitting in that kind of perpetual queue and approving conflicts that may never come up, how can we give the reasoning to the agent so it can do that on the fly, but then we can get it eventually to show it's working. For example, how it came to that and ultimately what it resolved to, and start to build trust with the agent under certain conditions. So to do that yeah, if you're a customer, you can configure that and we work with you on that. But also you could build a skill and start to codify some of these decisions so it can think about not just how to search, but actually when you get results, think about think about resolving conflicts in this particular way
Great. The learning loop won't really touch on this today, but the learning loop's an important part of capturing more content going forward, so not necessarily content management. But of course, you want some sort of loop where the agent can draft, you can edit it as a human, you review it, you approve it, and you actually want that saved back. So you don't wanna just let all of the content that you're generating day in and day out go. You wanna be capturing that as much as you can, bringing in that most recent information as soon as possible And finally, the future level. Like, where does this ultimately go? So where we see this, one of the changes that I think is coming down the pipe here is automated content management and separating different concerns. One that can definitely be managed by AI and one that is still remains the competitive edge. So we recently released snippets, which is basically like variables, right? Variables that you can insert into responses. So a really simple one is like employee count or assets under management
or how many offices you have. And those are updated once and then populated across, hundreds or thousands of different responses so that fact stays consistent. But what we're going to see there is agents that sit on top of these facts and actually maintain them for you. Things that are very straightforward. So we have an AI routine, whether that's in platform, in ChatGPT, in Claude, wherever that sits, then it can be updated. So we're gonna allow these to be updated via MCP, and then that allows it to go live in all of the responses immediately. So no longer do you have a subject matter expert log in and having to do that, but you're actually setting up these autonomous kind of workflows, routines on behalf of your subject matter experts that pulls from the places that they work in. So examples of that could be maybe rather than ask your HR team to always update the employee count, we can trigger when there's a new hire in the HR system, automatically update the employee count, but maybe also create a new profile content item based on their resume, 'cause we need that content as
well, rather than have HR send it to us and us upload that into the system. Or maybe someone leaves, can we automatically archive their profile from the system to ensure we're immediately not using that going forward? So these things are very bespoke and very different organization to organization. But now with all of these different connectors and MCPs, these things become possible. Not just an agent that kind of blindly looks at conflicts coming through the system and flags a bunch of things, but actually, no, this is the source of truth. This is exactly where it goes. I'm not gonna make a mistake. This has been a tested, repeatable process. We're gonna approve it, and we're gonna trust it to do that. And it can take so much of that really monotonous labor that is content management off the table and remove all of these things, just leaving us to work on the edge of content management. How do we put our most recent differentiators in? How are we positioning ourselves in market? How do we make sure this speaks to our brand, our tone, our voice, et cetera? Oh a lot to go through there. Thanks for listening to my, my, my rant and rave through that.
I hope that there was a few kind of unlocks through there, and that you can take this presentation home with the recording as well. Step through it, see if there's different lenses or models or learnings that you can apply from us talking to hundreds of bid managers working across the Fortune Five Hundred and startups and everywhere in between. And we'll send over those free down- those free downloads. If you, yeah, more interested to learn about how this could work for your organization, if you haven't already, you can book a demo. And if you're a customer already, you can reach out to your account manager and step through any more of this as well, of course. But otherwise, yeah, happy to thank you for your time and answer any questions for those on the call Yeah, it's a great question. So a few questions here. How do you get buy-in for the investment necessary when it is yeah, when it's technically defined as overhead? So the return on investment calculations for this is interesting, and the thing is that this is not an additional cost.
There's already a cost that you pay every day, so I think it's calculating that cost. Trying to calculate how long are people spending at the moment trying to answer questions or trying to find that content. You can probably calculate that. So maybe you do a simple survey. How many minutes per day to blah, blah, blah? What are the main things that make it difficult for you to do your job? Blah, blah, blah. Then you could times that rate by, hey, this many minutes per day, this many dollars per hour. This is our current investment in people finding answers. Boom. That's number one, the existing cost. There might be an opportunity cost associated with that as well. Maybe this is salespeople, so we're gonna get a return from them spending their time working and meeting with customers rather than searching around our knowledge base. So we can get that cost, we can get that potential opportunity, so that's the two kind of first CFO numbers there. And then we can take that, and we can put together a case of what we're looking to invest is 100 hours, whatever it looks like, in content management. We expect that even if this had a 10% reduction in the amount of time
it took to get answers, then that is a positive return on investment. So basically putting it in those numbers because there's always a cost of what you're doing today, so it's about reducing that Any other questions, you can pop them through. Best practice for applying concepts into a system that's already in use. Yeah that's a really good one. So one for that is you can take your current content map. I would think definitely make sure that you've already completed the steps that we went through earlier around mapping the sources and everything out like that outside of your current library. Make sure that you've captured that and thought about that. And then you can think about what that future state is and then migrate to it over time. So I'd always have a stepped process for that, like particularly starting with simplifications, because those are usually the biggest unlocks is what can we delete?
What can we merge together? What can we simplify? Start with simplification and then build out from there. But definitely a phased approach. But yeah, it can always be helpful to zoom out before you start undertake that kind of project, figure out where you wanna get to, and then break that into stages to make it easier. And yes, absolutely, we'll share the deck. You'll get a email within the next day with this entire presentation so you can download it and share it with anyone else Any other questions, pop them through. Otherwise, we can call it a day, and we'll let everyone get back to work. But appreciate your time. Thank you all Thanks all. Have a good rest of the day
