Calming Customer Chaos: Tips for Tackling Complex Journeys in Adobe Journey Optimizer (AJO)

Transcript

Hello, everyone, and thanks for joining me for some tips on tackling complexity within customer journeys, specifically using Adobe Journey Optimizer.

I’m going to begin by asking you, how do you eat an elephant? Or said differently, what’s the best way to eat an elephant? If you’ve never heard this question before, you may be thinking, it’s an odd way to start a presentation and wondering what do elephants have to do with customer journeys? You’ve heard it before, and you likely know the answer.

The best way to eat an elephant is one bite at a time. This is not a metaphor that I’ve created. It’s a metaphor that’s often used to describe the best way to tackle complex problems. And in my experience, it’s one that certainly can be applied to customer journeys.

The best way for us to tackle large customer journeys, which may otherwise be complex or overwhelming is to break them down into smaller bite-sized problems that we can then tackle individually.

Before we get started, my name is Adam Wilson. I’m the Director of Marketing Operations at Air Miles in Canada, where I lead a team of marketing operations professionals that leverage Experience Platform to orchestrate customer journeys across multiple channels.

We’ll begin our session today by discussing customer journeys in general and reviewing how even the simplest customer journey can quickly grow in complexity.

We’ll then move into our tips, beginning with using a bite-sized approach for designing and developing our journeys using Jump Actions and Journey Optimizer. Next, we’ll talk about how you can leverage tags and tag categories to aid in the day-to-day management of your customer journeys.

Then finally, we’ll wrap up by reviewing a few strategies to simplify your data management planning as you build your journeys.

So let’s start by talking about what defines a journey.

Defining characteristic of customer journeys are that our customers are moving through a series of milestones or moments, and our marketing is being used to drive them through these milestones.

Journeys are inherently personalized as customers move through these milestones at their own pace. For a single journey, one customer may move through that journey in a few days, while another may take a few weeks to complete the journey.

And again, due to their personalized nature, the exact marketing touchpoints that a customer receives may vary depending on which of those milestones they’ve completed organically, and then which ones require a boost through our marketing.

So what makes a journey complex? Well, when we add additional milestones, for example, deciding we want to encourage our customers to download our mobile app, may add complexity. This is especially true when customers may bypass these milestones if they’ve already completed them.

When we add additional channels, such as expanding an email-based journey to include mobile push notifications or SMS, that can add complexity. This is especially true when we need to consider customers’ individual channel preferences in order to deliver marketing through those channels.

And then finally, when we add additional data sources, for example, tapping into a product catalog in an e-commerce use case, that may also add complexity. And as we can see here, there’s a handful of ways that our journeys can grow in complexity, even when the underlying business objective or requirement is not particularly complex itself.

So this brings us to our first tip, where we’re going to go through a strategy for breaking larger journeys down into smaller subjourneys as we build. To do this, we’ll use a sample loyalty program onboarding journey.

This journey will have three milestones, two channels, and a simple communication strategy of sending a reminder communication for each of the milestones we’re promoting in our journey.

This sounds simple? Let’s take a look at how it appears when we lay it out on a page. Now imagine what this would look like if we added more milestones, more channels, or more complex journey paths than the simple reminders we’ve used here.

This visual illustrates how even a seemingly simple customer journey can come across as overwhelming when laid out on a single page. We need a strategy that will remove the overwhelming nature of this work and give us a place to start. A good place to start once you’ve mapped out your entire customer journey from a logical point of view is to break it down into phases. In our onboarding example, we have a phase for each of the milestones that we’re trying to drive, as you can see in this visual.

With our phases in place, we can now treat each one of these phases as a separate subjourney with its own related marketing objective. So in phase one, we’re trying to increase our customers’ digital engagement through mobile adoption by encouraging them to download our mobile app.

In phase two, we’re introducing them to the concept of earning rewards through loyalty transactions by encouraging them to make that first transaction. Then finally, in our third phase, we’re reinforcing that value and hopefully increasing the lifetime value of that customer by encouraging them to make their second transaction. Tackling three separate yet connected journeys not only simplifies the design and development process for our marketing operations team, but it also makes the collaboration process with marketing much smoother by adding clarity.

We can translate this approach directly into the Journey Optimizer application leveraging jump actions, but there are a few requirements for this approach to work. Your overall customer journey must begin with a triggering event rather than by reading an audience or using an audience qualification action. As you’ll see, all subjourneys will also begin with a triggering event.

Our first step will be to create a schema within the data management section of Experience Platform. The schema will be an experience event class, and it’ll be used to describe the events we use to move customers from one phase of our journey to the next.

We’re going to share the schema across all the transitions in our larger customer journey. So we need to make it possible to identify the origin journey, which is a journey our customers are coming from in the transition, and the target journey, which is the journey the customer is moving into within our transition.

In the screenshot here, the only fields we’ve added beyond those that are built in for the experience event class are two strings to capture these origin and target journeys.

So we should make it possible for us to identify customers moving from phase one and phase two using these fields.

We now need to prepare ourselves to use this schema by locating the identifiers for our and target journeys that we will use when moving customers from phase one to two.

So in this example, we’ll go to the technical details for phase one and phase two of our journeys and locate the unique journey IDs for both of these journeys. We’ll then set aside these journey IDs for usage in later steps. It’s worth noting that the schema in this approach technically allows you to use any string to identify these journeys. We’re simply using the built-in journey IDs as a consistent approach that reduces the risk of any ambiguity that might exist when we come up with these values ourselves and try to scale that across our teams.

Next, we’ll create the event that will be the entry point as customers move into our target sub journey. In our example, this is going to be the second phase of our journey. So this is done within the administrative configuration of Journey Optimizer. We’re going to select the schema that we’ve created in the first step.

We’ll define a condition on this event by using the journey IDs that we set aside for phase one and phase two.

The condition is going to uniquely identify the transition for customers moving from that phase one, which is our origin, to phase two, which is our target.

The event created, we then need to add it into our phase two sub journey.

So this is going to be the entry point for customers entering phase two. And we’re going to do something similar using similarly defined events for each of the transitions that exist in our larger customer journey. So if you have a phase three or a phase four, the entry points are going to be similar, but with the unique journey IDs for those transitions. We’ll now bring back that high level logical diagram that we created earlier to talk about how we’re going to plan out our jump actions. At any point in this logical diagram where we noted that customers will be moving on to the next phase in the journey, we’ll plan for jump actions when we begin working in the Journey Optimizer application.

Configuration for our jump actions requires us to select the downstream journey as our target, indicating where we are transitioning customers. So for us, this is going to be the phase two journey.

Then the action parameters will use those same journey IDs for our origin and target or destination journeys that we previously configured in our event. The reason for this is that the jump action will actually be generating an experience event record that our phase two journey will respond to, moving customers along in our own customer journey. So the jump action here needs to uniquely identify the transition being made by our customer from one sub journey to the next.

By using this approach, we can also seamlessly translate our logical diagram into the journey canvas and journey optimizer, as you can see here.

And finally, once you add the jump actions into phase one, you’ll see that a jump origin is automatically added into your phase two journey for each spot where you’ve used a jump action in phase one.

Now move on to our second tip of the day, which is leveraging tags and tag categories to support your day to day journey management.

I’d like to start this tip by asking you to picture yourself in a typical day for an enterprise marketing operations team. This team works with multiple groups or lines of business that exist in marketing.

For each of these groups, they have multiple campaigns or journeys they’re supporting.

As we’ve just seen, each of those journeys might have multiple phases.

And finally, this team is supporting multiple marketing objectives across the business.

In this context, they need to be able to quickly locate and monitor the success of these initiatives Now, if you’re like most teams, you’ll know that the best way to do this is to establish a shared journey naming convention.

Right? Well, to consider the effectiveness of naming conventions in practice, let’s use an example of what a typical approach could look like. So our naming convention could begin with the marketing stakeholder team for the journey we’re building, could include the marketing objective, the campaign or journey name, the phase or the milestone name. And then finally, within our naming convention, we may want to indicate the dates in which we expect this journey to be in market.

In practice, when we use this naming convention, it might look like this.

If I make a mistake when implementing this naming convention, it’s going to look like this.

If I make a different mistake, it’s going to look like this.

As you can see, interpretations of these names becomes quite difficult because the execution of such an approach is really easy for us to get wrong.

A further issue is that these conventions result in our journey names becoming very long and the management of journeys is actually made more complex even when we’re executing it correctly. As you can see with this screenshot, it’s really not going to be easy for our marketing operations teams to quickly locate, monitor and optimize journeys when they need to do so.

Tags and tag categories in Journey Optimizer are a small but powerful feature that allow you to do what the naming convention is doing.

Essentially managed tag categories enforce the structure of the naming convention, but provide improvements over a naming convention in terms of the implementation.

We can easily filter our journeys based on categories or specific types of initiatives, objectives or in-market dates, as we’ve done with the previous naming convention example. That allows us to be more focused when we’re naming our journeys in the platform on identifying the specific milestone associated with that journey. So let’s walk through how you might set this up.

Tags can be created and managed within the administrative settings of Journey Optimizer.

You’ll start by creating the high-level tag categories that you use to organize your journeys.

Good candidates are any of the metadata attributes that we used in the previous naming convention that might otherwise be implemented with that kind of complex naming convention.

Each time you launch a journey, you’ll want to create a tag for each of these tag categories.

The management of these tags does require a little bit of governance, as you don’t want any close variations or duplicates that’s going to make it difficult to identify one journey from another.

Then finally, the purpose of these tags is to make it possible for you to identify specific journeys or collections of journeys that are similar on the attribute you’ve selected for your category.

With the tags defined, we can then shift to using a clear, concise name for individual journeys, while also using the tag and the tag categories to describe the other attributes and allowing you to filter on journeys that are similar. So you can filter to get collections of journeys.

Coming back to our instance of Journey Optimizer, we can see that it’s significantly easier to look through our journeys, to view them, and to manage them on a day-to-day basis. Whenever needed, our team can easily filter on specific tags or tag categories to quickly zoom in on the journeys that they need to review or optimize.

We’ll wrap up today’s session with a discussion on data management.

I’m going to begin this tip by saying something that we probably all know if we’ve spent any time reviewing the Experience Platform documentation.

The unified customer profile is powerful. It enables us to scale our audience activation across all of our channels. But it can’t be done successfully without careful planning.

When ingesting data from external databases, we need to ensure all of our data sources are synchronized. So proper alerts need to be in place to trigger an investigation and resolution whenever failures do occur.

The profile guardrails need to be considered on top of the data ingestion guardrails that They exist for any data we’re bringing into the data lake.

Identity data and its integrity and modeling in your source systems need to be carefully considered in order to create healthy customer identity graphs.

And then finally, the utilization of your data lake is an important part of any pre-ingestion assessment.

So this begs the question. Does your use case require profile-enabled data? Or does your use case require you to bring data into the Experience Platform data lake at all? There are several reasons why it is worthwhile to ingest data and enable it for profiles. Asking yourself a few simple questions will help you determine whether it is.

Is it going to be useful to use this data to create audiences and specifically leverage audiences and channels outside of Journey Optimizer? Is the data going to play a key role in stitching together identities to unify otherwise disparate profile fragments? Or is the data source going to enable any sort of on-site or in-app personalization? If the answer to any of these questions is yes, then it is likely going to be worthwhile for you to enable this data source for profile and go through the planning and considerations that I mentioned at the start of this section.

In some cases, however, your data sources are really only intended to be used for specific journeys either to orchestrate communications or to personalize content. And we’re going to review two techniques for simplifying data management by bypassing some of the considerations that I previously mentioned and saving yourself some headaches. We’ll start by reviewing the usage of contextual attributes on experience event records, and then we’ll wrap up by reviewing the usage of external data sources.

As we review our first technique, I need to mention a few prerequisites.

This will only be applicable on event-driven journeys. Similar to the first tip we talked about, it won’t be applicable on those that begin by reading audiences.

The data we leverage will need to contain an identity field that can be used to link these records to profiles that exist within the experience platform.

And then finally, all the contextual attributes that you want to leverage, of course, must be present in the source event and then modeled appropriately in Journey Optimizer for your use case.

With these prerequisites met, it’s important to note that the dataset used in this technique This can also be leveraged, as I mentioned at the top of the section, for orchestrating communications or for personalizing content.

An example of where we may want to use this technique is when we have a customer completing a transaction and then we want to move them into a journey where we’re personalizing it based on the product or brand that they’ve purchased.

I’m going to go over the implementation of both of these techniques at a high level, so it’s worth reviewing the Experience League documentation in detail before you leverage them yourselves, because I’m not going to have time to go deep on the technical details.

Similar to the steps involved in our first tip, you’ll need to define a schema and an event in Journey Optimizer to use as the entry point for your journey. You’ll also need to define a dataset to land these records in the data lake. So you go through these steps, be mindful of the attributes that you want to leverage to ensure they’re present on the source data and ensure they’re modeled in Journey Optimizer in a way that allows you to easily access them within your journeys.

Once defined and pulled into your journeys, you can leverage these attributes on the event to orchestrate branches in your journey, as you see in these screenshots. Again, you could do this without the dataset being enabled for profile, as long as the data is in the database. You can also pull this data into content itself. For example, into the HTML for an email or into the body of a push notification.

Our second technique requires us to fetch data from an external system which can be made available to Journey Optimizer via network requests. So there are a few prerequisites related to that functionality.

The data source must be exposed through an endpoint that supports GET, POST, or PUT requests.

The endpoint needs to support JSON formatted payloads. And then finally, the endpoint needs to be performant enough to support the lowest possible throttling configuration in Journey Optimizer, which is currently 200 transactions per second. The response returned by this endpoint needs to contain all of the attributes required for usage in your journeys. Because you’re going to be interacting with this endpoint directly within the journeys, you don’t actually need to bring this data into the experience platform data lake or enable this dataset for profile.

An example of where you might want to use this technique is when we’re fetching product details headlessly from an external content management system for usage in a cart abandonment journey.

Again, this overview is going to be done at a high level, so review documentation on Experience League to get the finer technical details.

We need to begin by defining a custom action within the administrative configurations in Journey Optimizer. You’ll start by inputting the data source endpoint along with the method that Journey Optimizer should use to interact with that endpoint.

Next, you’ll need to configure the header values that are going to be sent with these requests. Header values can be variable, meaning that they’ll be configured within your journey whenever you’re using this action, or they can be constant, which means they’re not going to be configured in the journey.

The query parameters or body data can similarly be either constant or variable. You’re going to want to refer to documentation on your endpoint that you’re configuring in order to complete these steps.

Journey Optimizer has support for different types of API authentication, most of which are fairly straightforward. For those that involve the exchange of credentials for a temporary access token, you’ll need to do some additional configuration. Once you’ve selected custom authentication, you’ll begin by indicating the endpoint that’s used to generate an access token for your API and the method that’s used to do so. Similar to our previous step, you’ll also configure the headers and the body data required by the authentication endpoint. This is where you’re going to enter the credentials that you use to generate your access tokens. As you can see within this screenshot, all sensitive values are hidden once they’ve been entered and saved. Then finally, you’re going to indicate where in the response coming from this authentication the token should be accessed and how long Journey Optimizer should cache this token before generating a new one with a new auth request.

The final step in configuring our custom action is to indicate the expected response from this endpoint. And that response should contain all of the data that we want to leverage in our journeys. To do this, you’re going to make a sample request to your external endpoint, copy the response that’s returned, and then paste it into Journey Optimizer.

The application is going to attempt to automatically model the data based on the provided response, so it’s important for you to review the data types that are automatically assigned and ensure that they’re appropriate for how you intend to use the data.

When leveraging this action within your journey, any values that you configured to be variable will need to be configured in the journey canvas. These can be populated using attributes on the customer profile, data coming in from your journey events, or even just using static values that you’ve set based on a particular branch in your journey.

Similar to our previous example, this data can then be accessed and leveraged in both the registration interface as well as the content personalization. This time, however, you’ll find that data within the actions menu rather than events.

I hope you found these tips helpful, and I’d like to leave you with a few takeaways to reduce complexity in your customer journey management practice and hopefully prevent your teams from getting overwhelmed.

First is to consider using a sub-journey approach when designing and building larger journeys with multiple milestones or phases.

The second is to leverage tags and tag categories as a replacement for more complex naming conventions whenever you’re looking to use additional journey metadata to monitor or maintain your journeys.

And finally, carefully consider your use case when planning for data ingestion. You may be able to use some alternative techniques for accessing this data and use cases where you only need to use it in journeys.

Thanks a lot for joining me today. I’m excited to move into the Q&A sections where I can answer some of your questions.

Thanks, Adam. That was really an actionable content. Hope you all got smart ways from Adam to untangle the chaos using Journey Optimizer features smartly. And as he says, tackling large, potentially overwhelming challenges requires us to break them into smaller bite-sized challenges. So his breaking of unmanageable complex journeys into small manageable journeys has been echoed to you. Thank you for joining us, Adam. So yeah, thank you. Thanks. Thanks for having me. I’m really happy to be here.

So we got a good lineup of questions. So here are we moving to our Q&A. So an enthusiast asked us, can we set alerts on journeys when they set to expire to intimate marketers to extend if required? Yeah, it’s a great question. I think on that particular topic, so if you’re concerned about having journeys that are going to expire without you knowing they’re about to expire, to my knowledge, that’s not currently a feature in the product, but there’s a lot of tactics that you could use as a practitioner or as someone on the team to make yourself aware of that. So I would make it part of your journey setup process if that is a concern to, for example, put something in your Outlook calendar to send you a reminder or to put a meeting invitation in your or your team’s calendar to say, hey, make sure you double check that, hey, are we going to extend this journey or are we going to allow it to expire? Make that part of the setup process so that you’ll actually have that alert in place, even if it’s not coming from the platform itself. If you’re using some some other workflow tool to kind of manage cross team collaboration or cross team workflows and setting up campaigns, a lot of those have alert features as well. So you can do it there. But on the topic of like expiring journeys or expiring campaigns, to my knowledge, that’s not an alert that exists in the platform, but lots of other ways you could bake that into your process to make sure that you’re aware of those when it’s going to happen.

Okay, so I think you have already answered about alerts. So we also have a question on alerts. Can we set alerts if any drops or failures in journey run due to breaking events or tech that flows the data? Yes, so this is one that is in the platform.

Specifically on some of those more technical integration. So I talked a little bit about custom actions. You can set up alerts so that when those custom actions are failing at a rate above what you would deem to be acceptable, you can get an alert on that. The one tip I would share if you’re not familiar with it is make sure you double check your alert settings in an experience platform in Journey Optimizer, because you’ll want to make sure that you have those relevant alerts enabled, and then you’ll want to make sure that you’re actually subscribed to get the notification in the right way. Sometimes you’ll just get those alerts in the UI. You’ll want to go into your account settings to make sure that alerts are actually being delivered via email as well, if that’s how you want to receive those alerts. And the only other tip I would share when it comes to alerts, beyond just those that are relevant for the Journeys, is if you have too many alerts set up and you’ve set those up on those that might not be super high priority, what tends to happen is you stop paying attention to those alerts if you’ve set them up on those that are not particularly high priority, and some of them are more like FYI. So really carefully consider the severity of the alerts that you actually want to get in your inbox so that you don’t get to a point where you’re ignoring critical alerts, because your inbox is filling up with those that are more of FYI. So that’s just something I’ve personally encountered and I’ve encountered with the teams, is setting up like email notifications, for example. Make sure you’re setting up the ones that really require action for yourself to not, you know, put you in a place where you’re numb to those alerts. That was insightful. And I hope the approach is a practical tip for a lot of guys here. So here is the next question. Did I see, a user asked, did I see in an early slide that a journey must start with a customer action? For the approach that I shared, yes. So for the approach where you’re breaking down larger journeys into smaller ones, that is required. And the reason for that is effectively what’s happening when you’re moving customers from one phase to another is you’re generating an event, right? So you’re generating an event that acts as the triggering event for your next phase. The reason that doesn’t necessarily work with like a batch or like an audience read is, of course, a ton of profiles are going to be realized into that journey at once. So that approach where you’re kind of triggering the parent journey or the starting journey is kind of also needs to be event triggered. So that particular technique, yeah, it’s limited to those that are going to be event-driven journeys.

Yeah. And they can also think of journeys initiated by marketing teams. So what are your views on the journeys initiated by the marketing teams? Yeah, yeah, exactly.

Can we use Adobe Workfront to automate the expiration of any campaigns, journeys in HEO? Yeah, I mean, I didn’t mention the Workfront product, but yeah, I would consider that to be one of the products that you could use if your team is using Workfront for sort of those cross-team collaboration workflows.

That’s where I would look to set up some of those alerts when a campaign is going to expire. To my knowledge, there isn’t like an out of the box integration that exists there, but I will be very honest, I’m not the expert on integrations between Workfront and Journey Optimizer. But when I mentioned kind of those cross-team collaboration tools, Workfront is a great example of one that a lot of customers use.

Oh, yeah, that was insightful again. So here is the next question.

This question might be going with a lot of folks. Is there a solution to stop any journey which is already on? Solution to stop any journey which is already on? I’m not 100% sure if I fully understand that question, but I’ll take a stab at tackling it. If it’s really about doing a search for all journeys that are live and then stopping those, to my knowledge, there’s not like a one-click feature for that. But the way I would do that is using the filtering features that exist in your Journey Optimizer instance. You can filter easily on status and then you could deactivate all those there. If I didn’t understand that question correctly, feel free to clarify in the chat because I’m nailed that one.

No worries, no worries. I think the user is likely to ask any one-stop solution for the live journeys and you nailed it all. So we have another question about, do you have any tips to share on enabling journey tags for performance marketing in CJ or outside the platform? Any tips to share on enabling journey tags for performance reporting? Good question. So I’ll be honest, I’m not an expert on customer journey analytics, but I think the question is taking those tags and pulling those into reporting tools to be able to use that there. I’m trying to think through the question. It’s a really great question. To my knowledge, I would have to think through, to be honest with you, how you would set that up. Obviously, one of the usages of naming conventions that I went through is to kind of enable reporting and that type of analysis. And there is a trade-off there that if you clean up the names from a maintenance point of view and make it simpler to manage, if that’s kind of a linchpin to your reporting solution, you may have to incorporate aspects of that naming convention approach, which I know I kind of spoke poorly of, but there is a bit of a trade-off there. I would really stress test, I suppose, those reporting solutions against the out-of-the-box reporting solutions you get in Journey Optimizer, as well as if you’re not using CJA in the example where it’s outside of the platform. If you’re using, for example, Adobe Analytics or you’re using another analytics product, could you use campaign tags and the URLs to get some of that as well? So short answer is you may need to use a naming convention if your reporting structure is very much integrated around that. But just knowing kind of the costs that I kind of mentioned in terms of complexity on those naming conventions, I would really pressure test your approach to make sure that’s absolutely required. I think the key point that I was trying to get through there is that there is an overhead to those types of naming conventions, and that overhead is that it makes management a lot more difficult. As a practitioner, I’m not able to just look across everything I have live and quickly interpret it. I’ve kind of got to have this encyclopedia sitting next to me where I go, okay, what does this journey mean? So I think just making sure you’re going through that step of really thinking critically about your solutions and the complexity they cause is a critical part of evaluating those solutions.

I hope your approach has been insightful to many. So here is the next question. What is the best tips for managing when a customer qualifies for multiple journeys based on their actions and events? So great question. I would say I don’t know if you have an automagic solution. And to be honest with you, I don’t know if anyone would want an automagic solution, which if you’re not familiar with the word automagic, it’s just where you snap your fingers and it’s done. But I think what you want to do there is if you have a single event that might be relevant for multiple journeys, the starting point is actually thinking through those customer experiences. And that’s what I mean by I don’t know if you’d want an automagic solution because you actually want to be thinking about the customer experience and which of those would be appropriate. There are scenarios where a given customer interaction might trigger multiple possible experiences for the customer, but as much as possible, you want to de-duplicate those.

Okay, I’ve looked at a transaction event and there’s three journeys that I want to put someone into when they do that. In that case, the approach I would take is actually doing some sequencing. So you can call it next best action. You can just call it customer experience mapping. But thinking about, okay, this person’s made this transaction. What’s the first experience or journey I’d want to put them into? If we have a reason for them to re-qualify making a second transaction, then maybe the next time they make a transaction, you move them into that second journey. But to kind of really drive the point home, if you find yourself in a scenario where a given customer interaction might be related to multiple journeys, take the time up front to map out that experience, not only with your teams that are going to actually need to build it, but with the marketing teams as well. What I found is you can actually simplify the work of your marketing operations team significantly by just working through kind of that mapping exercise with your marketing counterparts, because oftentimes really framing it in more of a customer through more of a customer lens allows you to simplify a lot because the team may see, okay, you know, one, two, three, here’s first priority experience. Here’s a second priority experience. And here’s the third priority experience. And that makes it very easy for you to kind of manage those overlapping journeys, if you want to call it that.

Thank you, Adam. And we got so many comments about your presentation. It has been great. And so many questions are popping up. I think we can take one or two more. So let’s take more questions. Is there any option to set a threshold for errors, failures in Churnee and get alert notification? I think this will be covered in one of the sessions as well. Okay, perfect. Do you want to just do a throw out to that one? No, you can give them a teaser.

So yes, most of the alerts that you can configure in the platform have some sort of threshold to it. So when you take a look at those alerts, you should be able to see the threshold. If not, if that’s not obvious to you, you can open a ticket with support to get a view of what your current threshold is set at. But yeah, you can set it to say, okay, I’m comfortable with an error rate of 5%, right? I think you’d still want to think about what is happening with those failures, if that’s what the alert is. Is the customer dropping out of the journey altogether? Or do you have to have some sort of recovery mechanism? But to answer the question directly, yes, in configuring those alerts, the threshold that is going to trigger it from happy expected path to unhappy unexpected path is something that you can configure as a customer.

Adam, we have got a great line of questions. And sorry, guys, we cannot have more questions now. But there is something coming up for you. Thank you so much, Adam, for the deep dive on customer journeys.

Thank you very much. I’ve really enjoyed being here.