Develop Practical B2B Use Cases

Transcript

Okay. Hello, everyone, and welcome. Today we are here for Build B2B Better, a guide for developing practical business use cases. My name is Katherine Coppola. I am a senior field engineer here at Adobe based out of New York City, and I’ll let Wyatt introduce himself. Hi, my name is Wyatt Hink. I’m based out of Portland, Oregon. I’m also a senior field engineer. Before we get started today, I want to quickly go over our agenda. So we’re going to start by just disambiguating solution capability versus business use case. Then we’re going to jump into the architecture overview. We’ll discuss a little bit about how B2B is different. That’s really going to bring us to the meat of our presentation, which is the B2B use case template and examples. Then we’re going to walk through both some good and bad examples of use case writing for technical implementation. And really what we’re going to try to do is connect those back to our entity relationship diagram or the ERD, as you’ll hear us refer to it. And we’ll close out with why you need to write a B2B business use case. So with that, Kat, I’ll hand things back to you. Thanks. So many of our clients struggle to define appropriate business use cases early on. And that results in a lot of struggle for them and could result in reimplementation in worst case scenarios, just a few short ones after launch. So this is due to lack of clear business objectives, well thought out use cases, audiences, and an ERD, and sometimes the lack of appropriate resources. So we like to say, begin with the end in mind. And hopefully today we can help make the case for why business use cases are not a roadblock, but rather a streamlining way to successfully implement your Adobe Stack.

So what we’ve learned running launch projects is you’ll be in a room with a lot of teammates with a lot of different functions from marketing ops, data analytics, IT, and everyone sort of brings their own vocabulary. The terms you use every day might mean something to different teams and recognizing that upfront helps with align us faster and avoid confusion as we move the project forward. We throw around a lot of buzzwords, KPIs, average session time, audience qualification, and they mean different things to different folks. What attribution means to an analytics team might not mean the same thing to marketing or finance. And if we don’t align our terms and our use cases in plain text and kind of keep a shared vocabulary to make sure that we’re always on the same page. So to start, I’m going to define what solution capability versus business use case is. We want to make a really clear distinction between capabilities and business use cases. When you work with ultimate success, the first thing we ask when you start is what is your business use case? And many teams can conflate capabilities and business use cases. It’s very, very common. So solution capability describes a system requirement from the end user’s perspective. It could be things like, I want to segment my audience. I want to create a unified profile. I want to activate to this destination or send an email. Those are capabilities. And that’s the reason you bought the platform because it can do those things. But a business use case is different. It ties the capabilities to a specific trigger, action, or outcome. For example, when someone from a buying group scans their badge at a booth or attends a webinar, we want to notify the account director with a push notification so that they can engage in near real time. The goal is to capitalize on the interest and shorten the purchase life cycle. That level of specifics is what helps us configure a solution that can correctly have success and directly to the use case. So the business use cases focuses on the financial or operational gain of the organization. It’s about the outcomes, not the capabilities and features. It should spill out the business objective, how we’ll measure it with clear KPIs, and the risk if we miss this goal. It identifies the target audience, the data sources we’ll use, and where we’ll activate, whether that’s Marketo or AP or some CRM or whatever destination you like.

Now, I hear this a couple times a week. Why do I need to write a business use case? I just want to send my emails out by April. And the idea is that the use case is not red tape. It is the fastest way to get your value and avoid rework. So while it doesn’t feel like it’s productive, it’s actually super foundational. It clarifies the objective, the audience, and the data and consent and compliance and basically the cutover plan. Without it, you’re going to risk delay, poor deliverability, and missed outcomes. And with it, we prioritize smallest viable path to something like emails by April. Okay. And just to drive the point home a little more, we’re not going to go over the entire architecture of AEP and its applications, but I’m going to just like explain the sections of this diagram. You don’t need to know the whole thing in detail. So on the left here, you have all of the systems and touch points that are producing data, your web and app, your point of sale, call center, events, CRM, typically where the data is first captured and first stored. Okay. So that’s all the way on the left. And then all the way on the right, you have the places where you activate emails, push notification, web personalization, paid media, call center, anything like that. That’s where audiences and offers and journeys actually execute. Now, everything in the middle is AEP. And that’s where all the heavy lifting happens, the ingesting, the standardizing, the governing, the unifying of the profiles, segmenting, and the orchestrating of activation. So there are three components I want to call out in the middle because they’re foundational and we’re going to keep revisiting them. There’s edge, right? So that’s up at the top, that big red box at the top. That is our low latency layer for real time collection and delivery, super fast. Then there’s the hub, the central orchestration and profile services that coordinate data and decisions. And then there’s the data link. That is the persistent storage and processing layer for raw and curated data. Keep in mind this left and middle right view as we walk through use cases, because it helps connect the business outcomes to the right data processing and activation paths. Now, we’ll just go into a little bit more detail on this middle section. I’m going to simplify it. I’m going to simplify it on the next slide for you. So again, you don’t need to know everything, but just a little helps make the case for why you need a business use case. Okay. So from that big diagram we had, in the middle of the architecture, and I’m going to simplify it for you. There are three core principles of the AAP data lake. All data written to experience platform eventually ends up in the data lake as an XDM data set. That’s the durable system of record behind the real time customer profile segmentation and activation. The data lake acts as the common storage layer for upstream collection and downstream application. Remember, upstream collection is the left and downstream application is the right of that big diagram we were looking at before. So, ingested sources land there, profiles built there, query service reporting read from there, and created data sets feed activation to destinations from there. The storage mechanism is app-end only. That means that no in-place update operations. When the data changes, you’re going to write a new event or record to the same key and update the attributes. You rely on event time, versioning, and merge logic to reflect the latest state of the profile and created views. Okay. Another part I want to go over in that big diagram is the experience platform data stores. So, let me first break down the real-time customer profile. There are two key data stores. There’s the profile store. That’s where we keep the fragments for a person. So, attributes, behaviors, and supporting entities wherever a data set is enabled for profile. And then we have the identity store. This is just relationships. It’s where we maintain the identity graph. Each ID plus the relationship to the other ID is stored here. If a record has two or more IDs, we create and enrich the relationships that connect them. So, why does this matter? I think that if you’re on the business side, well, on the technical side, it’s super important to understand this, but from the business side, high level, we don’t store single static profiles, right? Instead, at activation time, whether you’re asking AJO, real-time CDP for an audience, AP resolves the audience in real-time by traversing the related IDs and assembling the latest relevant fragments according to your merge policy. So, keep in mind, the real-time customer profile is an activation layer and it contains a subset of data from the data lake. Everything you ingest in AP is persisted in the data lake and the profile holds just what’s needed for real-time audience evaluation and activation. So, you need to know what data is needed, right? And that’s why you need the business use case. Okay. So, looking back at the architecture, again, you don’t have to know all of this, but there are three primary ingestion paths, each optimized for different activation speeds. The edge SDKs and APIs to the edge network. This is the low latency path. So, signals are captured at the edge, segments can be qualified at the edge, and you can activate experiences within seconds or even milliseconds. Then there’s streaming to the hub. Events stream into the hub into the central services, flow into RT-CDP, and are available within minutes. This supports real-time audience qualification and activation. And then there’s batch. Files land in the data lake and if the data set is enabled for real-time customer profile, the profile store is updated shortly after. Batch segmentation typically runs on a daily cycle about every 24 hours. So, audiences based on batch data are available after the job completes. And then for B2B, you have this extra layer, right? Your entity and relationship data, so that’s your accounts, your opportunities, buying groups, they surface in AJO B2B, but you can build the audiences and buying groups at the account layer, at the account level, and then either activate through AJO B2B, Marketo, or you can pass to other places for activation across different destinations. As new events come in via streaming in the edge, they move through the pipeline and reach the B2B destination within minutes, enabling real-time triggers or journeys. And then the last thing I’ll point out is there’s AEM assets essentials connected to AJO for content creation and reuse. So, your teams can manage assets through their centrally, so it’s a little bit separate. But the idea is that you have all of these moving parts and when you write your business use case, what you’re doing is you’re helping the technical team determine where those attributes that you need for innovation are going to live so that they can meet the business use case promptly. Okay? All right. So, this is probably one of the simplest ways to explain the data ingestion methods. Data comes in, again, we talked about edge, streaming, and batch. Edge is ultra low latency path for on-site and in-app experiences and qualifying and activating within seconds or seconds. I want to talk about the key contrast between streaming and batch. Edge is like your same and next page personalization. I think where customers get tripped is making choices about design when it comes to streaming and batch. Volume and frequency. Streaming delivers small payloads at a high frequency and batch delivers large volumes on a scheduled but less frequent canons. Latency to activation. Streaming data is available for audience qualification and activation within minutes and batch data requires scheduled processing and batch segment evaluation, which typically runs on a daily basis. So, you want to use streaming when you’re in near real-time triggers and quick audience updates. And you want to use batch for large historical loads, periodic refreshes, and bulk corrections. Okay? And here is just another way of describing pretty much the same thing. Right? Edge is going to be super fast but super simple. Streaming is somewhere in the middle of really fast moderate complexity and then batch is slower but you get much higher complexity in terms of what you can query and the types of audiences you can produce. So, you see there’s a balance here. And when you write the business use case, what you’re helping your technical team and whoever is designing to do is determine whether you need Edge Streamer batch. Okay? All right. And with that, I’m going to hand this over to Wyatt because there’s more to it when we’re talking about B2B.

Thanks, Kat. So, hopefully everyone followed what Kat was describing and it should be pretty clear at this point that it’s definitely complicated. I would say B2B is usually more complicated than B2C. The main reason for that is the changes in the data structure. And we’ll go over that a lot in the ERD portion, the entity relationship diagram. But first, let’s just try to set the foundation for how is B2B different. So, for starters, we have longer buying processes. We typically have longer relationships with the customers and longer decision-making processes that we have to work with. Oftentimes, we’re dealing with group decisions, which means getting consensus, potentially seeking executive sponsorship. All of that means that there are different people with different roles in approving the purchase of our goods. So, beyond that, there are also things made more complicated as we have this lead to sales cycle. So, there’s always a marketing sales handoff process. Sometimes, there’s also a handoff back from sales to marketing as well. And for that it’s important to align on MQLs, SQLs, making sure that those definitions are set consistently across different teams. And of course, lastly here, we have account-based marketing ABM. So, ideal ABM approaches are always going to focus on buying groups, which allows us to orchestrate personalized journeys for the varying stakeholders within an org tailored to their role and level of influence. So, let’s dive into this just a little bit more. So, of course, in B2C, the end users are making purchase decisions for themselves. I might walk into a grocery store and at the checkout line, maybe I grab a pack of gum and I just make that instinctive purchasing decision quickly for myself. But when we’re talking about B2B decisions, they’re much more complicated. If I work for a power plant and I need to go purchase a new turbine, I’m not just going to walk into GE and purchase a new turbine instinctively. There’s going to be a long process of engaging with a lot of different stakeholders. So, in B2B, we interact with individuals, but they represent companies and collaborate together to make collective purchasing decisions on behalf of the business rather than on behalf of themselves. So, these things are similar, but they’re not the same.

And I realize there’s a lot of text on this slide, so let me just read it all to you line by line. Just kidding, I won’t do that. In fact, I’m going to skip over this entire first column here around the individual. I’m sure all of you know what it’s like to be marketed to as an individual every day and many of you probably have experience in marketing to individuals directly as well. Instead, I want to focus first on this account column. So, when we’re talking about account, this is an organization and we can choose to market or segment based on organization level traits. That could be things like industry vertical, number of employees, region of headquarters, whatever it is, we’re targeting based on that account level. So, it’s a little bit more complex than the person, but it’s less than ideal in some ways. After all, just because everyone happens to work at the same company doesn’t mean that they approach things the same way as individuals within those collective processes. So, buying groups are a little bit different because it’s for those stakeholders within that account, within that organization. So, it’s group level stakeholders for a specific buying decision or if you prefer a different method terminology here, an opportunity. So, it’s more complex and it might include things like engaging not only the practitioners, but maybe sponsors, the IT department, finance department, legal department, things like that as well. Let’s go a little bit deeper into a buying group example. So, everyone you see on the screen here is a member of the account Acme, but let’s say I’m Adobe and I have a whole lot of different products. I’ve got Photoshop, I’ve got AEM, I’ve got RTCDP. Not everyone at this Acme company is going to be involved in every one of those purchases. Accounts are hierarchical and different products are going to be sold at different levels in the hierarchy. Some might only be sold at one level in that hierarchy, some might be sold at multiple levels within that hierarchy. It doesn’t make sense for me to try to market Photoshop to the VP of engineering, but it does make sense for me to market AEM to the VP of engineering. So, I can create different buying groups based on the opportunity that I’m trying to nurture, that I’m trying to drive, and in that way I can tailor things more closely. So, this is really helpful when you have multiple opportunities on the same individual account and we need to orchestrate those concurrently. And that really brings us to the meat of our presentation, so I’m going to hand things back to Kat to talk through the business use case template. Thank you, Wyatt. All right, let’s walk through some of the elements of the use case. So, we have two rules up front. First, state as clearly as possible what the business wants to achieve, and second, don’t worry about the technical design. We’re going to translate the business brief into a solution design later. At this point, we don’t want you to think about technology or solution or solution capabilities. We just want to know what the business needs to do. Okay. All right. So, if we look at this slide, this is the first part of the template.

So, we’ve got the basics, right? The name, summary, business objective, kind of what you’re trying to achieve. Remember that word cloud I showed you a couple of slides ago? We want to bridge the gap and make sure that the tech team or whoever’s implementing understands what the business is trying to achieve so that they can design appropriately, right? So, we want to explain what the key objective is as clearly as possible, and then we want to outline the audience description on who they want to target, who they don’t want to target in the exclusions, and then a definition, so an explanation of it, right? So, I like to add in the explanation in addition to the description because it’s the specific conditions that detail kind of what you’re trying to do or who you’re trying to read that way. If like the IT team is trying to understand it, they might implement everything in the description section correctly, but then read what you’re actually trying to achieve and be like, oh, wait a second, and it gives that extra filter and sort of bridges the gap between the marketing and the IT. And then the data sources. So, where is the data that this use case uses? Where is that coming from? Drilling in a little bit to audience qualification, these are basically four of the main objects where you’re going to get B2B data from for your audience. So, there’s person, that’s everything about the person, where they live, their email address, their phone number, if they’re a member of a certain audience, state, region, things like that. Then there’s an account, right? And that goes back to kind of like what Wyatt was saying before, right? In B2B, we’re doing business with the account, not the individual. So, this is industry, this is the number of employees, the country, are there opportunities? And then that brings us to opportunities. What kinds of opportunities? What stages the opportunity? Is this person a member of the opportunity? All of those things. And then there’s the group, which goes to solution, interest, status, role, and membership within the buying group. And now I’ll hand it off, Wyatt, do you want to finish up the template? Yeah, absolutely. So, that brings us to one of the fun parts here, the activation and goal sections. So, the team should be thinking about things like what do we have available? What do we have licensed? We have Marketo, we’ve got AGO B2B, we’ve got Adobe Target, maybe we’ve got an SMS partner like Twilio or someone else involved as well. So, we don’t need to design too much, we just want to define these basics. And now when we go over into user journey touch points, we need to start thinking about in as much detail as possible, what are these interactions going to be? What are the emails we’re going to send? What are the text messages we’re going to send? Is all of that required data present and available? And for this next part, the personalization components. So, I really want you to think of this as two different components, if you will. There is the personalization of the journey. So, that’s when do you receive a message? If you receive a message, what channel is it on? How is it being served on that channel? But then there’s actually the personalization of the content in the message itself, that’s the other piece. So, for an example, in an email it might be something like an account number, maybe we’re passing along the details of a certain sales rep, things like that. So, there’s the journey personalization and the content personalization and we’re going to want to define both of those within these personalization components. Now, something that’s definitely a little bit more b2b specific, the routing automation. So, we want to think about what types of sales routing need to occur and when. And then, of course, very closely connected that, speed delete. So, do we need to get a certain record to sales in a certain amount of time? What’s the speed at which a qualification must occur? Do we have to send an email within minutes or can we send it tomorrow? If they fill out a form, how soon do I have to fill the follow-up? It might seem like very minor details when we’re trying to build and execute these campaigns, but it actually makes a really, really big difference in the way we choose to implement these things. And, of course, lastly, within this goals area, so we want to know what our KPIs are, we want to know what our key performance indicators are, that’s what we’re setting out to achieve. So, we might choose to define this as something like a click-through rate of 20 percent and we want to know that expectation because we want to be able to measure this and see how far off are we from achieving that goal, have we already exceeded that goal, and do we need to set a new one? And one of the very important parts of this is how do we choose to measure things? So, there should always be a really meaningful conversation about how can we measure things differently and which is the right mode of measurement for us. Let’s say, for example, that there are more than 12 clicks from the same person on a single email. Do we choose to factor that into our click-through rate? How do we account for that? And, of course, there are oftentimes going to be multiple different reporting suites or reporting options available and we need to make sure that our methodology aligns best for what we’re trying to measure. So, with that, let’s do an example together. Now, I want to be very clear up front, this is a bad example, so please don’t try to recreate this example. I actually put this together just to make Kat frustrated. So, let’s start walking through this at a high level. I’m just going to break it through bullet point by bullet point. So, my marketing team wants to recreate an existing campaign called Welcome Nurture New 2019. Expecting this to be a simple lift and shift into our new Adobe technology. The audience will be derived from CRM and manually uploaded into the Adobe solution for now. We’ll figure out segmentation at some point in the future. This campaign sends emails with virtual hobbits assigned to the lowest content block. Hobbits are mission critical to this particular campaign. And Advanced Lead Scoring Program is also mission critical. I just want to make sure I tack that on as well. And, of course, our overall goal here is just to make our newest members feel as welcome as possible. So, hopefully, you all are seeing some red flags here. Kat, can you help me go through this and make this a little bit better? Maybe call out what I’m doing wrong here. Good job frustrating me, Wyatt. Okay, so the first thing is we never lift and shift. Anytime your team is kind of moving in that direction, I’m going to encourage you to stop them. It just doesn’t work that way with major enterprise technology. You can’t copy and paste from one system to another. You need to evaluate and redesign and hopefully optimize while you’re doing that. And I’ve said the audience will be derived from CRM and manually uploaded, and we’re going to figure out segmentation in the future. This sounds an awful lot like assuming design and not stating requirements. So, we don’t want to make assumptions about what’s going to be done later on. We want to state explicit requirements for what we’re trying to accomplish. Next up is virtual hobbits. Were you watching Lord of the Rings when you wrote this, Wyatt? The question is what does this virtual hobbit mean? That’s obviously being satirical here, but the idea is that you had something in your old system that worked really well, and it met some sort of use case. And instead of attempting to rebuild it, we would just want to know what need it was meeting that you really found useful. And then we’ll redesign with the new technology. Maybe we have an akin feature, but maybe we have a better feature that we can use and help optimize it. So, trying not to recreate things and just, again, work with what we have. And this lead scoring program being mission critical to the campaign. It seems like I’m really just allergic to requirements today. I’m, again, mixing up use cases and just not clearly stating the requirements of the one use case that I should really be focused on and staying in scope on. And then the lastly is making members feel welcome is great and driving velocity is great, but they’re not measurable KPIs. So, the problem with goals like this is that we can’t tell if you’re successful without measurable KPIs. So, it’s a good start, but it’s not going to get you there. Let’s write this better then.

So, the first part we’re going to call out here is renaming it Welcome Nurture Campaign for New Customers. That’s much better than what I had before, I think, for my summary. So, my goal here is to create a warm, personalized experience. I want to educate the audience about our product and services, establish trust, make sure to drive future engagement. I’m providing some context. My organization has been running a successful welcome campaign since 2019. The functional requirements for this use case are based on transitioning the current live campaign off of that legacy technology. And my business objectives are to just make sure that new customers are finishing boarding paperwork, that they’re educated about our offerings, and that we’re driving early-stage engagement with personalized content. So, how did I do this time, Kat? Have I done better? Much better. Much better. Here, we’ve avoided the lift and shift mindset while adding context of the past success, and we’ve set clear objectives for the use case. Okay. I took a stab at writing the next section. So, here, I’ve outlined my audience descriptions. So, has opportunity, is closed one in the past two days, marketing opt-in is true and has visited through more pages and registered for a welcome webinar. I’m clear about what I want to exclude because this is more for practitioners. I want to exclude my executives. I want to, you know, keep GDPR and consent in mind with unsubscribes. Let’s say for this certain product, I am not including product XYZ. It has its own path.

I want to exclude anyone who’s changed companies since they’ve kind of onboarded, and I’m looking for a conversion event. So, someone who’s already filled out the onboarding paperwork, I wouldn’t want to include them since it’s not relevant. And then I explain just plainly what I’m trying to do. I’m trying to target customers affiliated with newly closed one opportunities, and I’m focused on using practitioners and champions for offerings and services. Standard consent applies. Now, by giving the definition here, what I’m helping is helping the IT team do is understand what I’m trying to achieve because maybe when I wrote the description, you know, I wrote visiting onboarded page in the past three, you know, two days, but maybe there’s another subset of pages that I might consider, and if I just explain what I’m trying to do to them, they might be able to add a more robust detail to my use case and help with the technical design. And then data sources, I know this data comes out of CDP, Snowflake, Marketo, and Salesforce.com. How’s that, Wyatt? Better? Yes, this is great. So, we’ve identified the data points we need for segmentation, things like marketing opt-in, role, unsubscribe. We’ve identified the activities we need as well, things like visiting the onboarding pages, registering for the webinar, and above all, clear context for what the objective is here. So, this is great and exactly what we would want to see.

Now, let’s see if I can get us a little bit farther here. So, the activation channels and solutions that we have available, we want to use Marketo, Agio B2B, and Adobe Target. For user journey touch points, so as they enter the journey, upon qualification, the audience will receive a weekly email for four weeks intended to drive them to relevant web pages about a new product. Additionally, our sales rep will check on their progress and personally reach out by phone and invite them for meetings at trade show booths for personalization components. So, again, breaking this down into the journey and the content. So, for the journey portion, we’re going to be personalizing based on previous web and email interactions. If the customer completes necessary onboarding paperwork, we can just hide that message from them for the remainder of the journey. So, that’s sort of the when and the if. The content, so this is the actual personalization within the messages and communications we’re sending out, are going to be things like first name, date of onboarding, and their sales reps details. When it comes to the sales routing process, so as the customer completes the onboarding process, we’ll simply increment their lead score by one for each page visit and 10 for each webinar attended or trade booth they visit. Once they achieve a score of 15 or higher, a salesperson will be notified and will consider that onboarding complete. If they don’t engage with the onboarding content, then a sales rep will be alerted after five days to try to nudge them along further. Defining our speed to lead, a customer should receive their first welcome message within three days of onboarding and we want to alert sales as soon as the forms are completed. So, I think I’ve done a pretty good job here. Can you confirm that, Kat? Yes, beautiful job. States what solutions are involved, the types of touch points, it highlights the personalization requirements, and has clear routing and speed expectations to help us with our design. Good job. All right, I’ll take a final stab at the last. KPIs are clear. When we see KPIs, they should have numbers there. So, I have my numbers here, 95% complete in seven days, reduce call center follow-up by 35%, 30% attend an onboarding webinar, and more than 50% open rate KPI. And then I’m just, again, just clearly stating what I’m trying to do. A successful campaign automates the paperwork process, alleviates the follow-up from the call center. Customers should walk away feeling fully onboarded, knowledgeable about the offerings, and aware of who their sales representative is. How’s that, Wyatt? This is great. So, we’re, of course, defining a measurable KPI. So, we’re not going for something impossible to measure, like how many customers thought about completing their onboarding paperwork in the last seven days. We’re focusing on things that we can actually quantifiably measure, and we’re making sure that we have a clear understanding of what success really looks like. So, it’s not just about hitting these numbers as critical as they are, it’s about making sure that we have a successful onboarding process that people are experiencing and walking through. But what about the ERD? So, the entity relationship diagram. I know that some of you have heard me refer to it multiple times earlier in the call. Let’s look at two very simple versions of the ERD. So, before we get too far into it, I will say this is a data model. If you do the out-of-box model, this is exactly what it’ll look like. These are the objects, and you’ll see what this color coding will correspond to in just a moment. What I really want you to do is try to follow along with these colors as we walk through and tell a story here.

So, I’m going to tell a story about Kat, who is a field engineer at Adobe since 1982, when Adobe was founded. So, Adobe is headquartered in San Jose and has more than 10 employees, and what we’re focused on here is interest in purchasing product A. That’s our opportunity.

So, Kat’s going to influence, that’s driving the relationship to the opportunity, the decision, along with other employees that are at Adobe. She does not influence every opportunity at Adobe.

And as Kat visits web page and fills out an interest form, that information is going to come in as an experience event here, and as a result, she’s now going to be subscribed as a marketing list member to the product A marketing list, and as a member of the list, she’s invited to the campaign program member for the product A webinar or campaign, if you prefer. And then when she will send her an email after arriving, her record will reflect her attendance and program success. So, just to quickly recap and break that down. So, of course, Kat is the person really at the center of this map. Adobe is the account, that’s the organization that’s linked. So, you’ll notice that there are certain details that are an intersection of those two things, like how long a particular person has been at that company. We’ll also have an intersection of people to specific opportunities. So, there are going to be multiple opportunities open that are tied to Adobe, but not every single one of those is necessarily going to have a relationship to Kat, we only want to focus on those that are actually relevant to her. And of course, we can use these experience events to help drive coordinated actions to further that opportunity. So, hopefully everyone is able to follow along in that example. And now we’re going to make a jump to make things complicated here. So, here on this slide up top, I’ve got a slightly more complex entity relationship diagram. So, rather than just focusing on an abstraction of the object, I’ve actually listed the specific fields available within each object so we can better see how they connect together. And down here below in the red box, I’ve set forward a series of requirements. Hopefully you recognize these requirements we were just running through in the use case example earlier.

And many of you may be noticing that there’s something very important that’s missing here. Can anybody find out what’s missing? Anybody have an idea? Feel free to throw an answer in the chat if you think you know what’s missing here. Give everyone just a few seconds to do that. So, what we’re really missing here is the opportunity. We need to have that opportunity is closed one in the past two days and nowhere in this diagram do we have that opportunity object present. So, I’m going to hand things over to Kat to help me get this working. Okay, let’s try again. So, let’s go ahead and fix the diagram. And so, here you see we’ve added this opportunity object. Now, what I want you to think about here is that when you wrote the use case and you gave it to the IT team or the technical implementer, what they’re going to do is they’re going to build this diagram and make sure that everything you need from your use case is actually in the diagram and in a place where it can be accessed at the speed that you need it. Right? And we won’t get into how and why that works with the hops and all of that stuff and it can’t be in a lookup table and all that stuff. But just know that everything you put in that use case actually literally goes into the building of the ERD. So, let’s see. Is this going to work, Wyatt? I think… Yes, it absolutely will. Awesome. This one’s going to work. And so, what you can see here, what we’ve highlighted in pink is everything from the business use case that was written that is relevant, that is incorporated into the diagram. Now, this ERD has to serve many use cases, but what we want to do is make sure that it serves your use case in the speed and time that you need it. So, there are other features and settings on each one of these. So, this is a very simple example. But for example, we would want to make sure that you’ve enabled it for profile, that you can use it in personalization, that if you’re segmenting by account, it’s in the right account space. So, all of that stuff. So, what you write in the use case is really, really super relevant to your technical team, and they should be expecting you to provide them with this level of detail so that they can build something that is actually useful to you. Okay. And so, I hope that this helps you kind of grasp why writing the business use cases is not red tape, but it’s actually super important. We’ve been going at this for about 40 minutes now, and hopefully you can answer why you need a business use case. You need to know what data is going to be brought in to identify your audience so that you can activate them. And you need to know which channels you need, how fast you want to act, whether it’s someone scanning in a booth or something like that. And you need to know if the data is going to be available for you to actually use it. So, while they seem very disparate, these two components are actually the building of the ERD, the big model enterprise architecture we showed you, and what the business actually needs are super incorporated. And these shouldn’t be… One can’t really exist without the other if you want to ensure success of your launch. So, with that, we will open up for questions. I’m going to launch a survey in our chat. So, let us know what you thought, and we’ll take any questions. If there are any questions, we’ll take those out. Okay.

All right. And I know it can take a moment to jump off mute, so we’ll… Yeah. Well, we’re here. We’re here for another couple minutes.

And with that, if you have any questions or you think of anything, I think these slides are going to get sent out to you. And Wyatt and I are available to you through your account team, so just reach out to your TAM. We can answer follow-up questions or support you through your launch advisory or success accelerators in the future. Thank you for coming today.

Bye, everyone. Thanks, everyone.