Salesforce, Inc. (CRM) Earnings Call Transcript & Summary

Hello, everyone, welcome to today's session. Thank you so much for joining us today. Before we begin, I'd like to cover a few quick notes with you about our webinar platform. Today's webinar will be available on demand [indiscernible] [Operator Instructions] We've also added some additional resources, which are available through the resource library to the right of the slide. There, you can find additional related content. We encourage you to submit your questions at any time throughout our presentation today using the Submit a Question widget. We'll do our best to answer as many questions as we can at the end of the presentation. And lastly, let us know what you think of today's presentation by sharing your feedback via our webinar survey. You're also welcome to share your excitement in the moment by using emoji reactions on your screen. And with that, I'm turning things over to Brock to get us started.

All right. Thanks, Ariana. Thank you, everyone, for joining us today. Excited to dive into our session on 5 Tips for Getting Started with Data Cloud and Agentforce. Data Cloud and Agentforce together provide a pretty robust set of capabilities. And I think one of the things we oftentimes hear from our customers and partners is there's so much there that sometimes figuring out just how to get started can lead to a bit of analysis paralysis. And so today's session is really about sharing some tips and a simple framework for just thinking about how to get going and get started. It's really all about defining those use cases. I'm really excited to present on that today. Before we actually dive into the session, just a quick note. Our forward-looking statement here. A quick reminder that Salesforce is a publicly traded company, and customers should be making their purchasing decisions based on the products and services that are currently available and not on anything that may be coming in the future, which is mentioned in today's call. So with that out of the way, we can get into introductions. I'm Brock Jones, Senior Director of Product Marketing here on the Data Cloud team. Presenting alongside me today, I'm very excited to introduce Omarr McDonald. Ommar, do you want to introduce yourself?

Hey, guys. I'm equally thrilled to be here with you all as well. I'm Ommar McDonald, I'm a director within our data cloud practice for go-to-market here at Salesforce. And I work with customers to build and go-to-market scalable efficient solutions on the Salesforce platform, particularly on Data Cloud, which is the key foundation for Agentforce. Been here at Salesforce a little over 10 years and been in the ecosystem over 17. Happy to be talking with you guys.

All right. Well, let's dive in. So as I mentioned, today's session is going to be really sharing a lot of best practices and frameworks to help you think about how to get started. But before doing that, just kind of want to level set by really starting with what is Data Cloud. I'm sure for most of you who are here, you're obviously far enough along in your journey that you've got a decent understanding, but I did kind of want to start here on how we think about Data Cloud. And really, it's the foundation for not only our Customer 360, but now Agentforce. We really think that it is kind of that trusted foundation that's going to allow you to activate your data fully with the entire Salesforce platform. And it's going to provide 3 core benefits. First, it's going to allow you to create that Customer 360 that's deeply integrated with our platform, so giving the ability to bring together bigger all of your structured and unstructured data into a single view of the customer that actually is completely natively integrated with the Salesforce platform. So it's actually integrated with our unified meta data layer. And that's going to give our platforms like Agentforce the ability to deeply understand your customer, and not only understand them but be able to take action on all that data because it has that tight connection with the metadata framework. So it understands when you ask it to complete tasks, like, hey, can you update an opportunity, it actually knows what an opportunity is deeply integrated with that metadata layer. It's going to create that C360 is going to help you deliver that trusted contextual data to Agentforce And it's going to allow you to do autonomous actions all in the flow of work, right? So being able to drive action is really what data cloud is all about. That's our unique differentiator. As you think about other data platforms maybe in your tech stack, it's really about activation of data, whether it's through activating that new agentic layer in your organization. We're activating data more fully inside your Customer 360 applications, be it Sales Cloud, Service Cloud, Marketing Cloud, all the platforms your teams are very familiar with working inside of every day. And in terms of how all this works, I want to provide this simple framework kind of left to right visual. With Data Cloud, it really starts with connecting your data. So you're able to bring all of your data and whether it's Salesforce data or external data, how do you actually have your data already organized in that data lake warehouse, you can bring that in through 0 copy and just simply federate or query the data and as needed. So after you bring all that data in, you can then harmonize it into unified profiles. You're then able to govern that data safely with the help of some AI assistance. So Data Cloud, we had announced previously at Dreamforce in some of our Agentforce world tours is now rolling out some robust governance and security features that are going to allow you to really develop policy-based, governance rules and define access for who sees what data right inside data cloud. So you're able to govern that and then you can activate it anywhere, whether that's building insights or predictive models with the data that you've adjusted, driving actions across any of the Salesforce applications or using it to actually power Agentforce. And a lot of that comes with our search and RAG capabilities. So being able to bring in important sources like unstructured information and actually allow agents to intelligently explore all that information through search or retrieve the right infrastructure data from the RAG process. Lastly, all of that happens in our real-time layer, if you so choose and need. So being able to activate all this data in real time is another important capability here that we offer a Data Cloud with that subsecond real-time layer. So that's a bit about how it works. With that, let's get into more of the framework, the meat of today's discussion. I'll turn it over to Ommar to kick us off. Ommar, you might be on mute.

Sorry about that. First time I've ever done that in my life. Thanks, Brock. Let's start with tip #1, which is organization alignment. Organizational alignment is critical for any programmatic success on the Salesforce platform across data AI, CRM. And we're at an interesting juncture right now because it seems like every company is focused on data strategy and platform integration, right? And I guess the past couple of years have been very interesting for IT and data engineering organizations within those companies because a lot of them given the mandate, right? So they need to be able to consolidate data from a large number of places across their organization, centralize it, whether it be they've invested in a data-lake platform like Databricks or Snowflake or Redshift or what have you. And you need to do this while also maintaining their business operations. So typically, what we see how this plays out is you got the IT organization doing their thing, focusing on master data management strategies. You got -- your business is also doing everything in parallel as well, too. So you've got marketing department working on their digital strategy. You've got sales and service [ frustrated ] with their customizations on sales and service cloud. And everyone is just operating in silos from that perspective in terms of getting their daily jobs done, but lacking coordination across. And that's typically where we can help in terms of implementing organization alignment across a business. And we have a point of view to share here in terms of what does that look like and what are some of the components and key features of org alignment across the business. Before I jump into that, I just want to endeavor that as you look to start implementing within your organization, ensure that it's fit for business, right, fit for your needs. But when we think about where the core components of that, you have executive leadership over the top. They said the vision to set the strategy. We typically see, from our perspective, a center of excellence where there's a steering committee of business stakeholders that can drive success there. And they're the group that implements the best practices. They set the program charter. They set the standards, the whole accountability from that end. Looking on the far right there, we're thinking about who owns our data, who manages our platform. So that could be your IT, the department. That's an organization that will provide insight on data sources, data fidelity, how could data be brought in from that end and from that perspective. And then most importantly, the business areas, the functional areas that we want to support. So thinking of sales, service, marketing, commerce, operations, analytics. It's important that we have steering committee across those functional areas as well too so that we can implement change and value across the entire organization from that end. The key common denominator is that lot of customers see this as a new way of working, right? If you think about high school and having different cliques, we need to be able to bring those together and have coordinated efforts across the business from that end. So with tip #1 out the way, I want to jump into tip #2, which is picking a use case, right? We've now gotten the band together. We now have organizational alignment across the business. Let's start thinking about which use cases make sense for us, right? And the important thing when we think about use cases are, a lot of companies will want to leave a technology. This point solution is going to drive maximum value for my business along x percent. I challenge you to think about the outcomes, be outcomes based. And when I say outcomes, I'm thinking about 2 things: The whats, what am I building, what am I delivering; and the for whom, the end user, have the end user in mind. An End user can be external, it could be internal. When I think of external, I think of the customer. I think of ways in which they are transacting with you, whether it be individual or entity or a business; the ways in which they raised their hand, they want to hear from you from a brand perspective. And then I think about internal, I think about the seller, I think about the service agents. I think about the marketer. What are ways in which I can improve and impact their daily jobs, their jobs to be done and be able to maximize that across the organization so that I can realize value up towards x percent of cost savings or increased AOV to that perspective. Once you lead with outcomes and have the end user in mind, everything else falls into place. The technology decisions that you make, the people and the process that need to optimize in order to drive that long-term success from that end as well to you. So that will be my challenge to you on the call here is think about outcomes, think about the end user and what you want to influence from that perspective And when we look at Data Cloud from that end, we've been in the market for about 4-plus years now, and we've done our due diligence in terms of what are the common popular use cases that we've seen in market, right? And this is our gift to you in terms of starting to get the juices flowing along the lines of what are typical use cases that we see across these functional areas, right, sales, service, marketing, commerce, sales, for example, trying to improve productivity from that end, from an operation perspective. Service could be reducing attrition. Marketing is just higher engagement by providing personalized communications along those lines. These are ways in which we can provide you some examples that you can take and started to build prototypes around, start the POC in your heads and realize as well on the platform from that end. What I'd love to do is double-click on one of these -- actually, correction. I'll actually do 2 for 1 here and talk about sales and service, but along the lines of cross-sell, upsell. So taking a step back and thinking about what cross-sell upsell means. Let's say, you are a retail organization, you're selling me a pair of hands. You know that I love hands. Talk to me about a short to match. I'm a subscription-based organization, I bought a subscription. You know my affinities, what I like. Talk to me about add-ons that makes sense for me, right, from that perspective. So the goal here being, again, leading with outcomes, looking at the bottom right there, if I think about from a sales organization perspective, I want to boost revenue by providing more white space, by providing more upsell-cross sell opportunities for my customers. And then from the service perspective, it's really taking those sort of service interactions in those cases and turning those into revenue-generating opportunities along those lines as well, too. That then segues back into what do I need to facilitate that use case. So -- and this is the way in which we want to functionalize how we approach the key components of the use cases. Number one being what data is needed. Think about your CRM incidents, think about your Salesforce ecosystem in terms of accounts, contacts, cases, opportunity, profile information, if you will. Think about any external data that you want to bring in collaboration with that. So maybe some purchase information, transaction data, potentially -- these scores as well, too, if you've done that due diligence as well, getting those insights. It segues into the next step, which is what sort of insights do I want to glean on that data set. Indicative example here is maybe propensity to buy based on frequency of purchases. Let's say, I purchase 3 times in the past 90 days, perhaps I want to be able to define high propensity for that customer, right? That information, that insight, along with the data set, maybe I want to be able to visualize that on a contact page, a contact record or account record, so that this information is in front and center for our sales and service rep. It can be a valuable piece of intel as they're having a conversation with that customer on the phone, or it can be a valuable piece of intel that they use for a follow up communication. And then also important, what actions do I want to take on that piece of information. Along the sales line, maybe I want to create a lead, high-value guy, follow what that person leads; or on a service perspective, create an best action on that case as you're dealing with that customer on the phone as well. There may be some insights that you want to glean from a reporting perspective, like sales pipeline, look at propensity along those lines, those dimensions. But to really -- to segue here the TL;DR is think about breaking down the components along your use case, but most importantly, lead with the outcome in terms of what you want to improve and impact. So in regard to the first 2 use cases, we talked about organizational alignment and use case definition. I'm going to have to pass the baton back to Brock to talk about, okay, let's think about definition of success.

Thanks, Ommar. Yes. So once our use case is defined, it's really about establishing, okay, what are kind of our success measures and goals. Let's get everybody aligned to that before we actually start running with the implementation of Data Cloud. So when it comes to success metrics, we thought we'd provide some simple buckets for you to think about it as a framework for defining kind of goals and what success looks like for your own use case. You can see here, there are about 6 buckets that we've kind of collapsed common success metrics into. And these are the types of metrics we found come up over and over again when working with our customers. So starting on the left, things like data quality and really about the integration and connection of data. You have metrics around data sources. So for you to find use case, you can actually go in and say, okay, we know we have these x number of data sources. We want x percent of all data maybe on a low level or what have you ingested into the platform by certain dates, right? So you're really usually trying to go for 100% completion or whatever that percentage goal is. Data integrity, another metric in there is really about the quality of this data, so identifying error rates, duplication, really making sure that everything you're bringing in and transforming and harmonizing is coming in as clean data and high-quality data. And the data latency is all about the speed at which you can sort of perform all these actions and you can measure and monitor that as well. After that, down below, you have engagement and adoption metrics. This is really that bucket that's all about those traditional user satisfaction metrics, right? Are the people that you're deploying this to inside your organization satisfied? Are they onboarding quickly and at the rate at which you would define as successful? Business KPIs, a huge one, sell by outcomes, right? So based on the outcomes for any use case, you really want to figure out what are those metrics that we want to look at and start to understand are we moving the needle or not with the way we've implemented data cloud for that particular use case. So things like customer lifetime value or are we seeing retention rates go up, maybe you were trying to decrease case resolution for a service case. Those would be business KPIs that are critical to track and monitor. Operational efficiencies. These are more internal for you and your team, whether it's things like query time or system uptime or overall cost savings. These are important metrics to also be thinking about tracking. Marketing metrics kind of fit within business KPIs, but we do see a lot of more kind of CDP-like marketing use cases. And so these are metrics related to campaign ROIs, overall conversion rate for leads, engagement metrics. And then last, but specifically not least, any compliance or security metrics that are important for you and your organization. I think depending on the use case and the industry you sit in, you will have more or less of these, but looking at data compliance rate and security incidents and setting goals for that will be critical. So these are the buckets. There are a lot of different metrics that could fit within any of these buckets, so we just wanted to provide you a sample of those. I think what's most important as you define the metrics is just having a set of questions to be prepared to work through with your team of stakeholders. So questions that we often typically see used as a blueprint for defining successful -- not to be redundant, but successful success metrics would be things like what's the problem that you're looking to solve with this use case for Data Cloud? How is Data Cloud going to help? How can we measure it? What would be an indicator of that success? If you define the measure, what's the actual goal that you're looking to achieve that you want to hit with any of those measures you defined. So that's a bit about success metrics. Moving forward, after we sort of identified that use case, we know what success looks like. We need to start putting down on paper, what is sort of the capability and architecture framework look like for everybody. It's always important to start here, so you know where you're headed. That is going to make everybody a lot more aligned to what you're trying to achieve. And so building out this capability and architecture framework is super important. This is where professionals like Ommar and the professional services team can provide a ton of value as well as you think about, okay, we have this use case, but how does it all lay out on paper. Can you really start to map that out? And what I always like to do here is first just start by reminding everyone that there's a ton of capabilities within Data Cloud. Everything though, really boils down to this one simple premise, which is you're ultimately looking to create just that one single view of the customer that is natively integrated with Salesforce. And that's going to unlock your desired use case, that's going to unlock the ability to provide that data seamlessly to Agentforce to maybe create that new agent use case that you're looking for. And so I start here because this slide -- before we go into a bunch of capabilities -- is illustrative of that high-level premise that we don't want to forget about. And all of the capabilities and functions kind of ladder back to this. The example I'll show for capability mapping has to do with a customer that was recently looking to unify their Salesforce data. They're actually looking to bring in Salesforce data alongside structured external data from Amazon Kinesis as well as their Snowflake data. And they also were interested in activating their unstructured data from their knowledge base, particularly for a service agent use case powered by Agentforce. So it's kind of the ultimate definition. Again, it's a service-based use case; they're looking to deploy it and activate it not only with their sales reps, so in live chats, they actually have access to this fully unified profile to provide better service, but also powering Agentforce, right, so they can help Agentforce deeply understand their customers. And what this ultimately look like when we all mapped it out in terms of capabilities that would be leverage, you can see on this slide here, right? So lots and lots of pillboxes here. These are all different capabilities that align to data cloud functionality. But what's most important is the pillbox has highlighted sort of that bright blue were the capabilities that were relevant to the use case that have been defined for the starting point of this Data Cloud and Agentforce use case. So it's not everything, right? And importantly, Data Cloud's not priced in such a way that you're going to get charged for everything. It's really priced from a usage and consumption standpoint. So really pay for what you use. And so you start small with the use case, you can start to narrow in, okay, what are the capabilities we really care about? What are we trying to sort of turn on? And what do we not need to necessarily worry too much about right now? So this is kind of that capability map. And for any use case can kind of light up this board and get everybody aligned to, okay, what are the capabilities that we need. And then from there, you can start to create this architectural diagram. It's really important to map this out. So everybody can just kind of see the flow of data and what you're trying to achieve. So on this slide here, we have our architectural framework for the service use case. You can see at the very bottom of the slide, those 3 different sources of data I had mentioned that were of relevance. We have the Amazon Kinesis external data. We had our Snowflake data. And we even had knowledge articles as well. So the implementation here was how do we take that external Amazon Kinesis data and the Snowflake data bring it into Data Cloud. So that's by way of the Amazon Kinesis connector that we have and then the zero-copy integration with Snowflake. That middle box with Data Cloud is just actually showing from left to right what's happening with that data as it comes in. So we're connecting it. We're harmonizing, creating those unified profiles through our identity resolution, and then ultimately creating any insights that we need so that we have kind of that enhanced unified view of the customer. And then we would service that up into Service Cloud, right? And so the Service Cloud box is showing the different places that this unified view may need to show up, be it in live chats or the case resolution process. That would be for live service agents. But then we have Agentforce out here on the right as well, right? Maybe we're trying to actually implement a better service agent experience, something that can kind of take on some of the workload for that service organization. And so those reps, the service agents that they're creating need to actually understand all of the unstructured information from all their knowledge base articles, Think of like those traditional helps support articles. And so Data Cloud has the ability to upload that unstructured data through our vector database. I won't get into all the details, but we can create sort of the embeddings and the chunking through factory database. And what that does is that makes unstructured data a source of information that AI can actually explore and understand and make meeting from. And when you upload that into Data Cloud, now you actually have a way for the agent to go and retrieve and search across all that information and use semantic search and the understanding of all those knowledge-based articles to inform the outcomes and responses based off whatever sort of question the agent gets. So it's a super cool tool what we do with unstructured information. But this is how we think about the solution architecture. And it's really important to get this on a page so everybody can kind of see, everyone's clear, different stakeholders might have different input and concerns as you start to think about the flow of data. So always important to start here. So moving into our last tip, I will hand it over to Ommar.

Thanks, Brock. So to round out the tips that we provided to you over this afternoon or morning, depending on where you are, or evening, building a road map. So I want to set the stage here for this sort of scenario. You've gone through organizational alignment, you have the crew together from that perspective. You've defined on 1 or 2 use cases that you now have defined KPIs for and you know what the success metrics are around those. You've defined the capabilities that you want to influence and the architecture that you're going to build. You've launched and deployed and you're popping champagne, you're celebrating. My question to you is what's next. And when we think about what's next, it's important that you think about what's next at the beginning of that cycle. So in terms of building the road map, I know Brock had mentioned start small. It's important that we start some all from that end. I want to challenge you to think about it from 2 lines: Before and after. When I think big, you want to be able to not just have those 2 initial use cases or what have you, but have a laundry list of use cases. Start to build prioritization around those. What are low-hanging fruits? What are high-value items that are low effort that you can celebrate as quick wins, if you would? What is -- what are high value, but actually requires a little bit more effort that you can start to prioritize for, let's say, Phase 2, Phase 3 from that perspective? The goal is to think big. Start small, but then also that allows you to move fast. So once you do go through your first release, your first phase, if you would, you can then iterate quickly into your next phase, and there's no lull in terms of what's next there from that perspective. Now jumping into what that could look like from a road map. This example aligns to Brock's customer example that you just mentioned and sort of recap the customers' AWS from an infrastructure perspective so that they leverage Kinesis. So they're streaming data into the Data Cloud ecosystem. They have Snowflake as well. So they're an aspect of zero-copy from between Data Cloud and Snowflake. And they also leverage Service Cloud from a service console perspective to have service desk organization. So for them, they want to implement a crawl-walk-run approach taking a more incremental approach to value so that they can realize value along the way in a very accelerated iterative manner. So with their crawl, their goal is really to prototype up a solution; really define a proof of technology; hit the check box on the capabilities that have been deployed into market; and also measure success along those lines. Phase 2 is your walk where now I'm starting to scale up my data foundation for additional data sources. So they're adding on more data streams, they're thinking about real-time capabilities in addition to batch data pipelines; and they want to layer on Agentforce because the goal is not just the surface data, but to also leverage that data for more conversational use cases, let's say, account planning. Give me some -- give me a case summary on this case for this customer and I'm talking to. Give me an account summary on this account record so that I don't have to needle through every single data point on that account detail page, for example. And the goal here is to start to roll out additional use case, additional experiences from that end. Phase 3 is when they're really running from that end, where now they're looking at predictive models, they're looking at reporting and analytics. They're starting to layer on Tableau from a dashboarding perspective and thinking about ways in which they can introduce propensity into their current use cases and capabilities and also more Gen AI as one on top of that to really looking to optimize on the operational efficiency from that end. Again, the goal for this is think big, start small, but also move fast. And so to round it out in terms of the 5 use cases, I'm just going to do a quick recap in terms of what we discussed along those lines. So first, number one, get the band together. Think about your organization, think about your gaps, make sure the right folks are brought along, enabled and enfranchised. Number two, focus on the use cases that matter, have the end user in mind, have the outcome in mind. Number three, think about the definition of success. What are the KPIs? What are the operational metrics that you want to improve so that you can prove success, prove value within the business so that you can start to scale up for more use cases? Number four, thinking about capabilities and your architecture framework, make sure you have the right capabilities prioritized and think about the data that's needed to facilitate those use cases. And then last but not least, think about the what's next. Think about that road map from the beginning; and along the way, celebrate those early wins, celebrate the quick wins along the path to your big bang, if you would. With that, I pass to back to Brock.

All right. Thanks, Ommar. So those are the 5 tips. We really hope that you're able to use them to think about how you get started with Data Cloud to power any use case, ideally, some of the exciting ones we're seeing with Agentforce using this framework. A lot of these principles are really what many of our most successful customers have used when first getting started. Customers like Heathrow, who have seen the ability to reduce their average call handling time, thanks to unified profiles or Turtle Bay who implemented unified profiles and we're able to use them to increase their booking rates amongst their sales reps with customers by around 20% after implementing data cloud. So really seeing a ton of great success with this framework as a starting point. I would highly encourage you to use it. So when it comes to getting started with Data Cloud, we would really encourage you to explore more -- if you haven't yet in your journey, if this is going to be your first time -- really thinking about, okay, how do I get started? Here's a few resources that we'd want to share with you. Obviously, check out Trail Head, there's a lot of great learning content, if you feel like you still need to learn more about some of the capabilities and features that we offer to help you define some of those use cases that are right for your organization. Next, we definitely encourage you to look into the Data Cloud starter bundle. This is a package deal that comes bundled with professional services. So you'll get the help of incredibly talented, knowledgeable people like Ommar to think with you on prototyping out what are those use cases, how do we start small, get some quick wins. That's what really the starter bundle is all about. And last, but certainly not least, think about joining our Data Blazer community. It is a great resource. If you are looking to connect with others who are thinking about data and how to activate it across the organization or just thinking about Data Cloud, it's a great community that we're seeing a lot of traction and engagement with. And there are folks with varying levels of expertise and at various stages in their Data Cloud journey. So I would encourage you to check that out as well. So with that, we will close out the session. Again, thank you for the time. Really appreciate you taking the time out of your busy schedule to come and hear from us. And with that, I think we can turn it over to the Q&A section.

Right. Let's pull up some of the questions. Ommar, we can just kind of handle these on the fly.

Let's do it.

Want to see the top. Can you talk a bit more about how Data Cloud connects with data lakes and databases outside of Salesforce? Yes, I think the primary way for connecting data lakes is with our zero-copy architecture. So that's actually different than like a traditional connection point. You're actually not physically moving or ingesting the data with zero-copy. So by way of some of the partnerships that we have with data lakes like Snowflake or Databricks, we're actually able to federate or query that data in. So you would go through the setup process, it would kind of look and feel very similar to setting up a connector in Data Cloud. But instead of actually ingesting what's happening is you're querying or federating that data in as needed. So depending on sort of the schedule you set, you would query the data and then run the actions on it. So that's really the difference for any other external data sources. There's over 200 connectors that Data Cloud offers that you'd be able to set up, whether you're looking for a batch ingest or a streaming ingest. That's really the process that you would go through as you make those connections is kind of defining the parameters in which -- how are you bringing that data in. So those are kind of the 2 ways at the highest level of how that works.

Let's see. I guess jumping into the next question here. When you're setting up a Center of Excellence, what people should you pull in to be a part of it? What team should they come from? So typically, when we think about a COE, Center of Excellence, there are a couple of key personas that you want to think about, right? So first and foremost, you think about the executive sponsor. So who's the champion for your COE? Who's setting the strategy? Who's setting the vision? Who's setting the alignment from that end? Within that, then you have the owner. Who's the owner of the Center of Excellence? Who's accountable? Who's it go to choke from that perspective and is overseeing the management measurement and accountability for your Center of Excellence? Underneath that, you have your business leads. So think about who are your lines -- who owns your lines of business that could provide insight into goals and challenges. What are your technical leads alongside those guys who own the platforms like Agentforce and Data Cloud and Databricks and Snowflake or internal systems, and they can provide insights along those applications as well. And then last but not least, your functional areas. So your sales, service, marketing, commerce, operations. You want to have -- across those as well as part of your COE to drive value. So those are typically the personas that we would see in the COE.

All right. I'll take one more here. When defining success metrics for Data Cloud, do you see any one is like more common or less common? I think that it just -- the real answer is it depends on the use case, but the buckets that we most often see and hear about are the ones like data integration and quality. So just making sure that you're really focused on bringing the data in successfully and sort of maintaining high quality. So it's a trusted source of data. So that's key. Business KPIs or outcomes are almost always something you have to have. Any stakeholder who's investing in a resource like this is going to want to understand what are the actual business outcomes we're driving. So business KPIs are key. And the last bucket that's probably almost always in there is just engagement and adoption success metrics. So things like time to onboard, overall satisfaction. Those are really the big 3 that are almost always involved no matter the use case.

I'll also grab one, too. Let's see. So when working with customers on Data Cloud, what are some common pitfalls or mistakes that you see? I want to pull up a chair, I have a lot to share, but I'll distill down to 2 answers. Along the people lines, when we think about the 3 Ps, people, process, platform, people and process are probably where you see probably the most pitfalls. Thinking about people, thinking about who are the right folks to bring in. So I just discussed Center of Excellence, for example, right? So what we typically will see is the customer does not know who owns their data. Who are the system owners? Or worse, they are already preoccupied with other work within their organization and don't have the capacity to take on, let's say, the Data Cloud aspects of this implementation or summing up the integrations, if you would to. So a lot of times finding the right people, building that RACE is important and a critical first step as part of a Data Cloud project. And that's one of the common pitfalls I do see. The other pitfall would be on the data. So thinking about -- understand -- do you have a really good understanding of your data that you're going to utilize. We typically see this manifest itself, especially on some of our more comprehensive projects, like, let's say, for example, I'm dealing with a multi-org setup where I have multiple instances of CRM, and I want to leverage data cloud to build sort of a multi-work pipeline. I have different data sets across eCRM org, the goal being to standardize. So there's some data strategy there in terms of what is an opportunity on or correlate to another opportunity or another. Do you have the same sort of schemes across them as well, too. It can also apply itself to external data as well. How do I standardize and define a data dictionary around that data so that it can make sense of it for a business end user. So if you don't take the time upfront to define that data strategy, have a data dictionary, that can also cause pitfalls down the line because we really don't have a strong handle on what your data is and how it can be utilized downstream for the business.

Let's see. Question came up. This is a good one. Apologies. The architecture slide showed knowledge articles being outside of Data Cloud. How do you connect knowledge to make sure it's ingested Data Cloud. Do you always need data but for it? Yes. So this is why putting an architecture diagram down is helpful because that was certainly a mistake. The knowledge articles are uploaded into Data Cloud. The only way you can activate unstructured data in Agentforce is by way of Data Cloud. So those knowledge articles have to go through the vector database in Data Cloud. I think we were just trying to visually show them as kind of a separate use case from the live service rep interactions. But yes, those knowledge articles would be in Data Cloud. And it really is the only way to activate unstructured data. You have to use a vector database to transform that data into a source that's meaningful to any AI model, and Data Cloud is the solution for that. I think that's good.

I see a good question that just came up. If we have Tableau Cloud for connectors, would we need Data Cloud as well? If so, what is the benefit of leveraging Data Cloud to? That's a pretty good question because I actually had this question -- this conversation with a customer earlier this morning. So I think the way to think about Data Cloud is along the lines of the left to right that Brock had mentioned earlier in the presentation, we're bringing in data from a number of different sources. We have a very robust list of connectors that we can ingest data from into the Data Cloud ecosystem. We are able to standardize and build a canonical data model around that. But the most important part is what kind of insights and actions could I determine and glean as a next step along that data pipeline? So let's say, for example, I want to be able to create a lead in sales and service cloud. I want to be able to trigger a journey in Marketing Cloud. I want to be able to segment an audience that I can utilize, let's say, for outside of a digital channel, for example, throw it on to an S3 bucket or onto an SFTP, for example. There are ways in which Data Cloud can action much more capabilities within the Salesforce ecosystem from that and outside of just analytics. Data Cloud does provide analytics support in that. Tableau can sit on top of Data Cloud, right? So you can have a JDBC connector between Tableau and Data Cloud. And Data Cloud is another data source for Tableau to leverage from that end, for dashboarding and things of that nature. So I see them as not being or, I see them as being and in that they can complement one another very well in that IT support my analytics use cases. but I can also support more of my crossword automation use cases, cross system and use cases within the Salesforce ecosystem and also outside the Salesforce ecosystem.

It's just kind of all inherently baked in. Data Cloud through the retrieval augmented generation process that we do, which is really the whole process that allows Agentforce to retrieve your data. The Einstein Trust Layer sort of sits there inherently in that process. So when you're using Data Cloud Agentforce, it's just kind of there and working behind the scenes to do all the trusted work that we're doing, like masking a data, if it's in some information, removing it so it's not actually being stored within those LLM frameworks, right? So the Trust Layer is just kind of inherently baked in. All right. I think that's all we have time for today. So with that, as Ariana mentioned, the recording of the session will be shared out with all of you. So again, thank you for your time. Really appreciate you spending a little over a half hour with us today to learn more about all this. Thank you, everyone.

Thanks, guys. Happy hump there.