[Music] [Anish Chadalavada] Thanks, everyone, for joining us this morning. I know folks are still trickling in, but we'll start getting started and get the ball rolling, and then we'll leave plenty of time at the end for questions too so everyone can get more detailed as well. So as you're walking around Summit, I'm sure you're hearing a lot about agents and a lot about AI and a lot about the different use cases that you can get with those agents. And we've got some really great content for you on one of the more complex and pretty powerful use cases we've seen with AI agents so far, which is really around the work we're doing on migrations with AWS and with Slalom, our partners here.
We've got a great set of speakers on the panel. I'll do a quick round of introductions for our panelists. We'll tell you a little bit about Gradial in case you don't know. And then we'll jump into a presentation style with some Q&A so you can hear from our panelists who are going through this process now of the AI-powered migration. And then we'll leave plenty of time at the end for questions so we can really keep it pretty conversational and open-ended. So on my left here is Lee. He's a Delivery Director at Slalom. He leads the experience practice there, specializing in content supply chain. He's got over 20 of experience in digital transformation, and he's a certified AEM architect building enterprise solutions to drive CX impact. Fallon is with AWS. She's got over 15 years of experience. She leads Technical Product Management for AWS's marketing channels, including website and email. Before that, she did in-game messaging and personalization for Call of Duty and other video games in Activision.
Anup is one of the co-founders of Gradial. He comes from an investing background and was previously the CFO, COO at Certa as well. I'm going to be the moderator today. I'm also one of the co-founders. But I lost the coin toss, so I got relegated off the panel as a result. But hopefully, it's good.
I touched on this a little bit, but our agenda today is going to be a case study/panel discussion. We'll keep it pretty conversational so you can hear about the people, the process, the change management, the steps of what this future state of AI-powered content operations really looks like. We'll do a demo for you so you can see the platform in action, and then we'll jump into a Q&A with all of you so you get a chance to ask some questions. When you do that, we've got a couple of mics in the room. So just so we can hear you, you should use those mics.
So if all that sounds good, we'll get started. Maybe before jumping right in, I'll let Anup do a quick introduction on what Gradial is so everyone's on the same page. [Anup Chamrajnagar] Yeah. So I'm assuming you guys know what Slalom and AWS are. So we'll introduce Gradial here. We're an AI content operations platform. What that means is we observe that there's a lot of great GenAI tooling on the market, mainly focused on the content creation aspects of the content supply chain, but we saw that there still remains somewhat of a bottleneck in the content execution side of it. And so we set out to build a series of agents to help streamline the content supply chain a little bit more post the point of content creation. So how do you make things like content updates, migrations, page launches, and planning around that much faster and the delivery straight to Adobe Experience Manager significantly faster, all while adhering to all of your authoring, brand guidelines, and compliance and regulatory, guidelines as well. So excited to show you guys a little bit about the demo here and talk a little bit through the platform. Awesome. So now we can jump right in. So maybe as the first question, so folks get the lay of the land with what we're dealing with and really the scale, maybe I'll go to you first, Fallon. So as you're thinking about transforming CX across AWS.com and all of the sites and properties that you guys are managing and moving to a single great new design system, how are you thinking about the landscape that you're managing across fragmented CMS systems and design systems, and really approaching this migration when there's such big scale? [Fallon Christian] Yeah. Definitely. So we really want to make sure that it is easy for customers when they visit the AWS website to make it easy for them to find what they are looking for. And visual noise in terms of inconsistency across pages makes that really difficult. So we really wanted to try to converge all of that and move to a new design system that was more unified. But that has been very challenging given the scale at which we're operating with a ton of pages. Distributed teams have been creating those pages, lots of customization, multiple CMS authoring, just so many different things that we've been doing. And it's been a problem that we've been chipping away at, but with this opportunity to move environments, we saw, "Hey, maybe we can do the rest of this. Maybe we can do a large scale design transformation." And it seemed impossible, given the tight timelines that we were under. But with Gradial, we were able to do it. We're in the process now and it's going really well.
Gradial had features that made it possible for us to do this. For example, as we have been moving the pages over, Gradial has been able to intelligently select from our new components and our new design system and improve with every iteration. So as we go on, it keeps getting better. Additional features that helped us where we had a ton of legal pages, and with Gradial, we were able to say, "Hey, don't change the content when you move it." So we've been able to do what we were hoping to do and it seemed impossible but so far, it's going great. Awesome. That's super helpful context. And one follow-up to that is everything is oriented around the timeline around tentpole events and getting things done as quickly as possible. Could you tell us a little bit about what's driving the urgency behind this migration? Because, obviously, AWS is trying to move as quickly as possible. What's some of the motivation behind that? Definitely. So a new team came on to this project in about September, including myself.
Other folks may be able to relate to coming on to a project where there are already committed deadlines. And so we were trying to move everything by the end of May, so September to end of May, not a lot of time. So we partnered with Slalom to figure out how to move forward and found Gradial. And yeah, we've been building the plane a little bit as we've been flying it. But the reason that the team committed was because we need to stop kicking the can down the road. This was such a massive complex problem that we really said, "Hey, we need to do this." And now we're doing it. Awesome. So as we think about the actual approach, Lee, I think this is a good question for you. Based on your expertise managing these types of migrations and large projects, could you tell us a little bit about what the delivery methodology looks like for a migration like this one? [Lee Asling] Yeah, sure. So typically with a migration project, the first thing we want to do is figure out what are we migrating and how are we going to migrate it.
When we're dealing with the number of pages like AWS has, things like scripting and HTML scraping can be real cumbersome and time-consuming, require a lot of iterations. And so figuring that piece out first, it was pretty easy to determine that Gradial was a good fit for this with the automation pieces of it. But then on top of that, you still have all of the strategy and process that goes into it, the communication pieces that have to go out to the high number of stakeholders that are involved at every step of this process. And then on top of that, you've also got additional development efforts that need to continue to happen for components and templates with QA support on the end of that, which is slightly different than a traditional QA effort, where we're more doing validation of content and layout structures and what not.
But yeah, so I think the interesting thing about what's shifted for Slalom is, normally with these, we'd be looking at staffing developers to come in and be hands-on keyboard writing code to try and do this.
But with Gradial, we really don't need the technical resources. It really shifts to more of a strategy and a process-related migration. And how does it compare in terms of some of the specific steps that go into the migration process? You talked a little bit about strategy and planning. Obviously, there's the component development, the mapping, the design phases. How do you think about both the steps of the migration and where the real impact and savings are coming from versus scripting or the more manual approach that we've seen in the past? Yeah. Sure. So I think QA is probably the biggest area. So one of the things that the Gradial platform gives us when we migrate pages is a confidence score of how the content matches up from the old system to the new design system. And so if you've got a batch of 1,000 pages that you're migrating, 500 of them getting a score of 100, meaning that the content is transferred perfectly over to the new design system, you can ignore those pages. In reality, we know that they're good to go. And so then you need to adjust and figure out what's the threshold that you want to start checking those pages. And so is the confidence score like 50 or below, then you can focus your validation efforts on looking at those pages and trying to find, are there any areas where there's consistent patterns that we may be able to go back to Gradial, retrain it, and then reprocess the pages? So it's a lot of looking at and figuring out what the next step should be.
Just in comparison to a manual migration, for example, I think we guesstimated at the beginning of the project that it would be about 160 manual resources and upwards of $20 million to do this as a manual migration with the number of pages that we're looking at. So it's pretty easy to figure out which option was the best one for this. Super helpful. So, Anup, maybe over to you for this one. How do you think Gradial's approach is unique compared to some of the other migration tools and efforts we talked about with the scripting and the traditional approach? Yeah. I think to go towards the traditional approach, you have to have more of a linear mindset to how the migration timeline is going to look. And part of that linear mindset is normally thinking about it in terms of knowing what all of the mappings need to look like in terms of where your assets are going, what the components map to what components in this particular migration and some more complex situations, there are multiple three to one mappings that need to happen because you're going from multiple different CMSs into one. And so all of those things, there's a huge pre-planning and processing step before the scripts are even made, and then you usually have to write the scripts, and then some of them may not work at the beginning or outset, so you have to rescript it and remap it, and so there's a lot of back and forth, back and forth that happens, which usually starts to extend initial migration timelines in a lot of cases. And so what makes Gradial's approach very unique is that as the pages are being migrated, it's smartly being able to map pages against a best or golden record of pages that have been migrated really successfully, and is able to learn and iterate from that. And so you can go from more of a linear mindset to more of a parallel processing mindset where you can actually start sending batches of pages through, and having those process in real-time and then learning from that and moving on to the next batch. So we've been able to migrate hundreds if not thousands of pages in single settings because of this approach. Awesome. I can't stress how important the DAM aspect of that is as well, right? When you're going from an old system to a new design system, chances are the images aren't going to match up. So one of the best features, I think, anyway is as your assets are coming over and being migrated, Gradial will resize the assets according to what the new design system is and then put them in the DAM in the appropriate location. So you don't have to worry about a DAM migration if you're only worried about the web assets. And that was obviously a super accelerator for this project with the amount of assets we're talking about. Definitely. And I think one of the biggest questions we've heard from folks is really around the quality and consistency and what they can expect when it comes to AI agents. So, Anup, can you talk a little bit about how Gradial's platform, how the agents are really ensuring that there's 100% quality adherence to brand guidelines, consistency across pages? Yeah. I think the unique way we've built the stack is we're leveraging a lot of GenAI in order to be smart mapping and actually porting the content over, but something that Fallon mentioned earlier was you'll be able to map the content completely like for like. Now that's not natural to an LLM. An LLM's natural tendency is to almost rewrite things, and so that's what we're most mostly used to seeing is an LLM generating different pros based on probabilistic outcomes and things like that, but we've been able to build it so that Gradial's engine is able to actually just transfer the content completely like for like and fit it into the components even if they're slightly newer or different looking components than what the content was usually in. And so that's the consistency aspect of things, which is a little unique. On the quality aspect of things we mentioned on the asset side, we'll see things like a chart that stretches across a complete web page, right? And now in the migration, that chart now needs to fit into a picture component on the right-hand side of this new component in this new design system. So how do you actually, one, transfer that asset over which involves resizing, retagging, uploading to the DAM, but also point out that maybe the CX team should actually look at this page post-migration and try to reimagine if the asset should even belong in that page anymore, right? And so that's part of that QA step in the content quality piece of things is in this new design, in this new look and feel, in this new CX, should this actually still belong here or should this be rethought? That's a really great point. How do you think about actually documenting these learnings on an ongoing basis, Lee? Like, a lot of the stuff Anup just talked about, you could imagine that you don't run into that problem until you've migrated a batch of 1,000 or 2,000 pages, and then you realize this component hasn't been developed and there needs to be some guidance or articulation of what needs to happen there. So how do you think about the process of both documenting and then incorporating those learnings as you migrate the pages? Yeah. So documentation is something that we have to be very collaborative on across all of the teams because there's so many moving pieces. But we've got a great team on the ground. We keep decision logs. We've got a great QA lead in Peter who put together a really great structure for us that clearly defines what the steps are when X, Y, and Z happen. And just making sure that we're really writing down and keeping track of everything on paper, making sure that any changes in the process, decisions are logged in the appropriate documentation. If there's any tasks that come out of anything, making sure they're in Workday to be tasked upon.
Yeah. Yeah. No. That's super helpful. And we talked a little bit about the impact in terms of the cost savings. We talked a little bit about the quality. I want to double-click on that because I think sometimes that's one of the pieces that isn't always super clear, especially when you've got a very large migration until you start to see a new approach to doing these things because there's been such an established status quo. So we talked a little bit about the cost impact but we'd love to hear maybe first from you, Fallon, and then also from Lee in terms of the time and the cost and the quality, like what's the real impact of taking this new approach with this migration? Yeah. I think when we looked at the timelines, there was just no way with the number of pages that we had. And so we were like, "Well, can we automate this?" But strict automation would not be able to get us there either. So this was really the only type of solution that that would have worked and we went from really not having a clear path to having one. I think that also doing a POC initially really helped us but we ended up basically scrapping most of what we thought we were going to do once we saw what it could do. And it really not only is going to enable us to achieve the deadline that we've set but also, like I said, we've been chipping away at this design problem for a year at least. And so this is just that opportunity to do it all-in-one go and end up in a new environment with only what we need looking the way that we want. I think, let me know if you agree with this, but sometimes you just don't know what you don't know. Yeah. And you'll have to actually see the page or at least a version of it when it's migrated to actually make a decision on it. And that's what we're finding out as well is it's so much faster when you're just looking at a page, and that goes broader to what the platform can do in general in terms of page launches, but right now we're talking about migration. But being able to just see it instead of it being on a Figma file with arrows drawn to, this is going to be what the page looks like or a Copy Doc format of what the content is going to look like at the end of the day. Just looking at it makes a huge difference, and so being able to get to that much faster. Which also plays into the other migration methods, right? If you think about Groovy scripts, which I absolutely love is an ongoing joke-- - Groovy guy. - How much I love Groovy scripts.
But they do work really well when you've got structured content that makes sense, right? But when you've got an older implementation where the node structures may not make as much sense, it's hard to map those node patterns over to a new design system.
And so when you think about how many iterations you would need as a technical or development team to go through 50,000 pages and figure out what all of those different patterns are at either the node or the HTML level, that's a lot of work. And so you can pretty instantly realize a lot of cost and resource savings in that area and then focus your resources on the places where they can really make impact. Yep. And where do you guys see the time back really going when your teams are able to get away from some of the scripting and the mapping and the manual QA efforts? Is that time going back to CX, your strategy, design, just resting? All of the above, right? I mean, I think-- Not as much resting. - Yeah, not as much resting. - No rest. Not really much rest. But that's okay.
No, I think it's all of the above. I mean, the fact that we were able to do this and do the strategy and process behind it, I think it completely freed up your team to be able to focus on building the components and templates that need to be there for this migration to be successful. Yeah. The kind of work what we're doing instead is the strategic decision-making that we need to do in order to make sure we're making the right choices versus just hands-on a keyboard the whole time. So yeah, we're definitely able to apply our time to tasks that we can't outsource to some automation or model. Yeah. And I think I know Amazon has a really great principle of everyone like a product manager and you're owning the product, and I think I'm seeing that firsthand too with how people are leveraging Gradial or thinking about Gradial on both the Amazon and Slalom teams of maybe we can use it for this or maybe we can build out this plan and then run it through Gradial for this and then go through the-- It's cool to see people starting to think in that world instead of just every single LinkedIn headline saying AI agents or reading about AI agents or just seeing the word agent every single day. It's cool to actually participate with it and being able to almost make your own universe out of it.
Yeah. And, Fallon, maybe not even a question but curious. Your thoughts like, AWS is obviously a very tech-forward company. And so it's a unique opportunity we have where we've got a way to demonstrate an agentic use case that's fully in production, which is usually the big barrier that most POCs and accelerators are running into today. And do you see the added advantages or benefits of getting a really good, almost like first-party customer zero style use case with Gradial, where we're really using the clogged and bedrock models on AWS. Yes. And we appreciate that.
Yes. Definitely. At AWS, we are always looking for opportunities to use GenAI in our daily lives. We've seen its transformational power. It really is making us so much more efficient so we can focus on what I was discussing. And I think that this is a great example of how companies can use AWS to build applications and power their businesses, and now we're able to take advantage of that for our own projects, which is really exciting. Awesome. So next up, we'll do a little bit of a product demo, which Anup will walk through in a second here so you'll get a chance to see the platform in action. Anup, I'll let you do a little setup right before I play it because we jump right in. So if you want to give a quick overview of what folks will see, and then I can play our demo. Yeah. For sure. So what we're about to show you is a little bit about the Gradial platform. We're going to go through basically an old design system, and it's going to be in an AWS theme and format. An old design system migrating to a new design system, but actually batch migrating. So migrating more than one page at once. So you can basically get a bunch of live links in a CSV, note that what template or component library you want the Gradial tool to actually leverage from, and actually port those pages over to a new design system with, again, all of the assets resized, uploaded to the DAM, tagged in the correct way. And so, yeah, stoked to show you guys what this looks like here. Cool.
Yep. So it's Gradial platform. We're going to go through the CSV and click one of these live links. This is the old design system that I was mentioning, so you see a lot of those AEM components there, all the customer case studies and all of those components. And so we're going to take a CSV full of links to this and then move it to a new design system. You can upload your new design system to a library of brands that contain the components, and you see pictorial representations of what those components could actually look like on a page and even add to those templates through a library that has been pre-downloaded based on what your component library is looking like. In a case where you want to add new components, those will get added to this library as well. And so if we go to the batch task function, you can name batches, assign them to specific projects. In this case, there's an AWS migration project to assign to, and you can actually upload that CSV, and it will render all of those links as individual tasks that it'll have to batch run. And you can assign project owners, task owners to those individual tasks that are being run and click Play. What it's going to do is it's going to auto-map those pages over to the new design system, and you can run it with strict copy mode which, as we were mentioning, means all of the copy is going to be exactly the same and it's going to start running those tasks. We've already run a task earlier. This takes about 10 minutes, so just clicking into a task we've done. That's the same thing. Clicking into the new link, we give our Page Studio view. So the Page Studio on the left-hand side is a pictorial representation of the page, dissected into different components, and on the right-hand side, you basically have this representation of a Copy Doc. And so you have all of the assets that are resized so you know what's going on. This is where teams can collaborate on what the copy could be or should be, what the assets should be, and all of the assets are then downloaded into the DAM, retitled to what the titling should be and tagged appropriately, and we then give you a staging link of what it would look like in AEM. And so this is all in AEM. This is a real staging link. You can actually push this straight to publication in your prod environment, and you can see all of the links and animation stay intact, so that we can keep the integrity of the platform and design system.
Awesome. So we'll get into questions in just a second so folks can dive into to the migration itself. But to give the overview on Gradial's entire platform because there's more to life than just migration. It would be helpful if you could give a little bit of a lay of the land of Gradial's capabilities end-to-end. Once you've onboarded Gradial agents for migrations and they know the design system and brand guidelines, what are some of the other things you can really start to realize? Yeah. What we've found is that folks on the Adobe ecosystem use Adobe because of the feature richness of the platform, but they also use other system outside and around Adobe to move the content across their supply chain, right? And what we want to do at Gradial is make sure that those things are pretty seamless so that your experience across the entire Adobe ecosystem and all of your other systems of record are much more connected with each other. So what that usually means is, one, migrating or implementing with Adobe has to be much faster and more efficient. And so once we get in there, usually what we do is help our customers establish a strong foundation. And so what does that mean? Having the right QA procedures in place to make sure content is following all of the right guidelines and checking off, making sure that you're ADA accessibility compliant, all of your content and pages are complying with all of those policies, and being able to actually then automate the process of actually updating and maintaining new content. So for a lot of our customers, even pushing a new content update across, you go from a ticketing system to assigning it to a human either through a partner or your own team. That human picks it up and does the change in AEM, has to comply with all of the QA, branding guidelines, authoring guidelines, and then that gets QA'd by someone. That goes to compliance and legal. They check it off and then the content update is good to go. That usually takes three to four days for a small content update, multiple weeks for a large content update. And so our customers are now using Gradial to-- Instead of assigning the ticket to a human, they're assigning the Workfront task or ticket or Jira task or ticket to Gradial. And so Gradial is able to pick it up exactly how you've written it to a human and actually make the update into your AEM instance exactly as a very well-trained author would do. Similarly with page launches, what we're seeing is to get from a Figma, or a Copy Doc, or anything like that, it takes multiple weeks to actually get to an AEM page with all of the assets and content present that people can actually start to collaborate off of and then ultimately launch. And so the other thing that we've solved for here is to get from that point, source of truth wherever you guys work into a page in AEM in your own design system, compliant with all your guidelines so that you can actually start working from that page right there and then and push to publish. And the next aspect of this, which I'm proud to announce that we're officially in beta for, is how do you actually optimize this content? How do you take Adobe Analytics for instance, Adobe Target, the tests you've been doing there, and actually come up with proactive recommendations on what the content should be and not just what the content should be but then being able to actually publish that instantly or author it into AEM, right? So not just stopping at the recommendation but moving through the entire chain and getting the update actually across so you're able to test it out. And so we've seen a lot of appeal across stringing together a lot of these different systems to make AEM and the Adobe Experience much more engaging and wholesome for the customer. I also think that opens up a whole another world for design resources as well because if you think about going from-- You've already got your design system, you want to test out some new layouts. Well, now you can just put it in Figma, stick it in Gradial, and you get a page created for you so you can actually play with it in real-time rather than waiting for a developer to come along and do that for you. It's just automatic, and it's really neat. Awesome. And I think you touched on this, Anup, but super quickly the difference between what's truly agentic and RPA is a question that we get a lot from folks. So maybe quickly, if you could give a summary of what truly differentiates the agentic approach, which I think you covered in your last answer too. Yeah. No. I think, this goes back to my first response in this. I think RPA, the whole world of RPA is very linear decision tree, if then, if then, if then, and that's going to break at some point. And I'm sure we've all used some of those before and it has broken and there are some battle scars from that, mainly because there are so many different variations. There's so many different combinations of things to do. It's not just fitting something into a template but really reimagining the way that we deliver content. And so what does the word agentic mean to us? Agentic means being able to actually do the work as if you have a supercharged marketer on your team, right? And so being able to actually make some of those operational decisions, being able to actually move things through your different systems of record while following all of your rules, policies, and guidelines, and being able to train it over time to get better and better and better, to deliver faster results, personalized variance, be able to test out different things, experiment with audiences, and so having that full experience all while being able to keep your systems and processes, that's what agentic means to me. Awesome. And couple questions for everyone up here before we jump into the Q&A portion. Maybe, we'll start with Lee, then Fallon, then Anup.
What advice would you give to Adobe customers that are thinking about automation for their content supply chain and really going beyond just content creation? Yeah. I think everybody is really excited about content supply chain and AI in general. And a lot of times when we get excited about things, we tend to jump in two feet first and sometimes that's not a good thing. And so I think, really taking a step back and figuring out what is your strategy, what is your end business goal, what are you trying to solve for is probably the best thing to do. While it may not give you instant results, it will prevent a lot of iteration in the future that will make your project go over budget and probably not hit target dates.
Yep. Yeah. I mean, for me, I would say just look for opportunities to leverage GenAI. Things are always changing, but for us, we've just seen so much time savings, and just being open to that new technology has helped us, trying it out and then making changes based on what we've seen has been great. Yeah. And, Anup, you can't just say Gradial. I was just going to say agents, man, agents.
No, I mean, really though, I think touching doubling down on what Fallon said, being able to really understand where you can automate and should automate, I think everyone has a mandate to automate and use AI. Everyone does in this year, but you can't just put AI in everything. There are some things where you do have to have humans in the loop, and it's a lot of process planning and strategy involved in actually executing. And so giving it some thought on where you should use it, where you should start with it, and build trust with it in your process is probably the most important thing for this year. I think a lot of people and leaders in organizations will need to figure out, for sure. And last question to wrap up this portion. If you could use AI to automate anything, like work or personal, as everything starts to change with the latest models, what do you think you'd go and focus that time on? What do you think you would go and automate with AI? We'll start with you again, Lee.
I probably should have prepared for this question better but I don't know.
I honestly, like to use it for simple things, like I love to travel but I hate planning travel. So using it for simple things like that that take away stress from everyday life, I think, is a good use case for me personally.
For me, it would-- This is a little boring but email inbox management and calendar management. If I could get some help managing that situation, that would greatly improve my life. You guys took mine.
Is there any ideas? I can't say content supply chain either.
There was a lot of interesting use cases that came up last year at re:Invent, one of our lead investors, Madrona, who actually just led our series A. That was announced on Monday so that was a great timing there, but thank you.
But they held this dinner there and everyone was talking about a bunch of different GenAI use cases to use in there every day and someone representing one of the major airlines actually brought up the travel point, and I think it's going to be really exciting that coming out in a couple of months being able to actually have an end-to-end travel booking, but not just the end-to-end travel booking, but an iterative agent that you wake up late and you can't make your flight. How do you actually book a new flight? What if you go to a new destination? You have to book a new hotel, if you want to change from two queens to one king, how do you do that very quickly? All of these little things that having a personalized booking agent would be able to do. I think things like that and having mini-vertical personal assistants will start to be really cool as we start to use and interact with our phone in a completely different way. And I think the second point is, two years ago I was a Fintech investor, so everyone was saying Web 3.0 like crazy, and I think now we're actually living in Web 3.0, where someone's site will be an increasingly important source of truth for their brand because you'll have to solve for SEO and natural organic traffic, but you'll also have to solve for the perplexities of the world like the AI search engines to be able to filter through content. So I think you'll need probably two different kinds of experiences just catered to that, and so agents that are able to navigate companies and people through those interfaces will be really interesting, and take form of how the web experience is going to transform across the next couple years here. Definitely. Awesome. - Thank you all for-- - What about you? - No. - Yeah. You've just been asking all of the questions here, man. - Man. - There was a little answers. It's a good one.
You came up with this.
You guys took all the good ones.
I would say for me, probably a lot of the billing, invoicing, like appointment management stuff like, you're just so busy and then you try to get an appointment with a doctor or something, it just takes forever to do that. And then if you want to reschedule, it takes forever. You get a bill that takes forever. So I don't know, automating some of that would actually help quite a lot with pretty limited free time. So I think that would be a good use case, and I think that's been a very legacy approach that really hasn't changed in a very long time. So akin to the travel use case, I think we'll start to see a lot of that disruption in the next year or two years, so exciting. Or they just bill us at the desk when we're done with the appointment. I don't know why. They mail back every time, I always miss it.
Yep. Exactly. Awesome. Thank you all so much for coming out. Thank you to our panelists.
[Music]
