[Music] [Melissa Reano] Okay. Hi, everyone. Thank you so much for joining us in this session today in which Ron from GM will talk about how he managed to Redefine Engagement using AEM Forms. So before we get started, I just wanted to ask everyone here a quick question, which is, what's the connection between these products and services? We have a house, a business loan, a motorcycle and a VR headset. Feel free to shout anything, think quietly, both options are okay.
Give it a couple seconds there.
I heard someone over there maybe? No? Okay.
So the answer is that you need to experience them before you buy them. You actually need to go into the house and figure out if the lighting matches what you saw in the pictures. You need to go into the bank and negotiate those contract terms. You need to test out that motorcycle and see if that's the speed that you were actually looking for, and figure out if you like a VR headset or you don't. And the way that customers are going to arrive to those experiences is through forms.
This is what's going to happen. They're going to do a lot of research in the market, narrow down their options to maybe top three or top two, and for the ones that they want to test, they're going to request an experience using a form. Now on the other side, what organizations want to happen is to make that experience as best as possible because in that way, you're maximizing your chances of turning that person into an actual customer and buying your products. So the real question here is how do forms need to be to actually drive successful experiences? And it's three things. Agile, it needs to be able to be used for any author, for any type of form. It needs to adapt to all your customers. And finally, it needs to be integrated with all your systems. So now, I will pass it over to Ron, in which he will tell his story about forms in GM.
[Ronald Diemicke] Thanks, Melissa. So a lot of the-- GM's really interesting. And my role at GM, I'm the Software Engineering Services Manager over the brand sites organization in our Software and Services group, which is a fancy way of saying, I help run all of our brand sites globally for GM.
One of the things we want to talk about is, hopefully what you'll learn during the session...
I think it's paramount to understand that homegrown solutions certainly have their place. There are definitely going to be instances where a homegrown solution makes sense. However, in our particular case, I think what we found is, for various reasons, the homegrown solutions we came up with put us in a situation where we couldn't be as agile or as fast as we wanted to be. And when you lose that agility and that speed, that really does eat up time, it eats up your development resources time, it puts you behind the eight ball a bit. So from a business perspective, that can also look at the idea that you're not innovating potentially as fast as your competitors either. So one of the things too is, in streamlining our operations, you get also above the table stakes, right? And once you get above the table stakes offerings, it becomes how do you prioritize optimizing for the customer experience? That's looking at who your customers are, what they're trying to do and trying to meet them where they are by providing experiences that really speak to them and reduce the friction and barrier to entry for what they're trying to do.
Lastly, I think once you start to converge on that customer experience around doing things that streamline and optimize for the customer journey, you can also then look at the next level of truly personalized experiences. How do you get to customers to further reduce the friction points? If you know who the customer is, don't ask them for information you potentially already have. And you want to be a good steward of that customer information through the lifecycle. So with that, let me talk a little bit about what GM footprint we're talking about here. We're operating in 100 plus countries. We are the fifth largest global automaker. We're in the top five of US companies. GM is an institution in America. So when I say that we have a lot of websites and a lot of web content, that is not an understatement. It is literally tens of thousands of pages, if not hundreds of thousand pages globally.
And it is no small feat, the small army we have to put together for authoring and things of that nature. But we're also looking at all ways in every place, how do we optimize to make sure we're reducing the manual effort around this? We're always looking at the various things we can do to streamline that customer experience and streamline the business operations parts of things so that we're not constantly rebuilding and re-orchestrating the same things.
Another interesting piece is, in the automotive industry, there are some industries where maybe you only have one brand. GM has four major brands we have to contend with, but that only tells part of the story. There's a number of smaller brands too, like our parts organization, OnStar.
It ends up being quite a significant footprint when you look holistically at GM's offerings.
We also have a high number of models and a huge dealership footprint as well. And dealers, being the lifeblood of what we do are the front door interaction of how we work with our customers and the sales funnel in actually being able to sell vehicles. So a vital part of the actual customer journey and purchase chain.
So that speaks a little bit about GM, but what about us from a content management perspective? We have roughly 140 what we call Tier 1 brand sites. So when you go to chevrolet.com that is a Tier 1 brand site. And those are basically OEM operated brand sites that we control. We want to control the messaging around our vehicles and talk about them. And that's opposed to what we would consider a Tier 3 dealer site, of which we actually operate 200 Tier 3 dealer websites in Mexico and 600 Tier 3 dealer websites in South America. So we've actually built our CMS solution to be extendable and supportable for these dealers as well, where essentially we know we can operate a website better than the mom-and-pop shops that are out there locally for them, and that helps create a consistent experience for the brand, but also provides the dealer with the quality of the web experience they know they're looking for, and we can converge a lot of the pieces together and how we support both.
This is also across 37 countries that we have our websites across in 9 different languages with 10 different brand themes. So when we talk about brand themes, that's usually the coat of paint we put on top of all your CSS stuff too. So CSS typography, colors, all of that stuff that actually gives it its identity, we've got 10 different sets of those that we need to support across the whole thing. So when you add up all of these things together, it gets to be a substantial footprint. This also doesn't speak to the actual types of forms. So it might not sound like a lot. We've only got six or so types of forms. However, when you math the math...
We have a lot of forms. There's 3,000 plus forms globally. And when we've been through our journey in how we look at this and orchestrating and maintaining and optimizing for this, it ends up being a significant burden to look at that overtime if you're having to do a lot of that work manually. It just is untenable.
So let's just talk a little bit more about the forms themselves, right? So GM has a number of types of forms and an example of three of them are like the contact us form. So if you want to have an interaction with a GM brand, but maybe you're not quite ready for the purchase funnel yet but you want to continue to understand what we're doing as a business, the vehicles that are coming out, maybe you want to stay close to Cadillac because you're interested in the brand as a whole, you can fill our contact us form and be entered in to receive information on a periodic basis about what GM does. It doesn't put you directly into the purchase funnel, but keeps you informed about what GM is doing.
There are also more immediate actions you can take as a customer.
You could go fill out a request a quote form. If you are ready to buy, if you know that you are looking for a specific vehicle, our request a quote experiences are actually pretty smart. So if you go through our inventory lists and you find a specific Corvette that you are super jazzed about, you can actually go ahead and ask that specific dealer for that specific Corvette and get a quote. You just enter your information, you press the button and you're good to go. So we, actually, tried to reduce some of those barriers to entry through optimizing the customer flow through the journey by saying, "Hey, we already know what vehicle you were looking at. We already know the best vehicle exist at a particular dealer." So let's remove as many of those barriers to entry as possible for the customer.
On the other side of the spectrum, you could in theory go build a brand new Corvette. Corvettes literally, the number of permutations, I think, ends up in trillions of options you could have. So it's astronomical. So you could build a Corvette that is unique for you, that has all of the options you want, then pick the dealer you like working with, and still go through the same exact form.
Likewise, you might come in cold and know you want to traverse and go through that and not have a specific traverse in mind, maybe you don't even have a specific dealer in mind, maybe you pick three dealers that you want to shop around and interact with. The same form works for all of those customer journeys. So it's really flexible in that way to provide an experience that meets the customer where they are for whatever particular route they're going through at that point.
SMART forms. So I said our forms are smart, but we actually have a thing called a SMART form, which is confusing. But in this particular instance, the SMART forms are actually looking at the customer behavior. So in this particular instance, say you go and you're looking at a vehicle and you're then poking around the site, maybe you go look at an offer. You're trying to be thinking about maybe I'm on the fence. In this instance, the form comes to you. The form will actually pop-up at a certain point in the experience when you've met a number of criteria and it says, "Hey, I saw you were interested in this vehicle. Would you want to get a quote?" And by bringing the form to the user at that point, we're trying not to be obnoxious by having-- Nobody likes the modern internet where you have 50 pop-ups come up all at once. But at the same time, we're trying to monitor you for when you've met enough criteria where we say, "We think you're interested." And at that point, we can push you a little bit. Ironically, these forms are actually some of our best converting forms for that reason. People want that little nudge after they've gotten in the right direction. So in our forms world, this illustrates some of the most popular flows.
So just out of curiosity, who's gone through a vehicle experience where you've had to go fill out a form like this on an OEM website? Anyone? I see some hands. Was it a good experience? I'm going to guess probably not in some cases. You usually get bombarded by dealers and what not afterwards. So it really comes down to trying to get to a customer and meeting them in the right spot where we're sure they're engaged. We know they want to go through that perspective, that relationship with a dealer at that point where we can hand a qualified lead off to a dealer for them to complete the transaction. Hopefully, that also explains a little bit about why dealers might contact you so much because they are independent businesses that definitely would love to close a sale.
So let me walk you through a little bit of the journey and how do we get here, right? At various points in our journey, we came from a place where, when I started with GM, our forms were a lot more rigid. We had completely Java backed applications where the forms themselves and the styling and the business logic, it was all mushed together, right? And they worked, and it worked fine. There was nothing wrong with it.
But you might not be able to innovate or change as rapidly as you'd want to because all of those pieces were tightly coupled together, right? So GM looked at revising our strategy and we got into a room and said, "Hey, if we could go do this again, what would we do?" Right? And we looked at the opportunities we had, we developed a new system, we said, "Hey, we're using AEM, let's figure out how we can use the pieces of AEM Insights maybe to build our own forms." And we built a solution and we launched it, we realized we had a significant problem.
Authors were putting some form fields maybe where they shouldn't be, and that's because there was no contract between the UI and the services that we had decoupled from the broader application.
And in that moment, we realized we had-- I don't say made a mistake, but we hadn't considered all of the potential problems when our authoring team wasn't necessarily informed about the full capabilities of the forms themselves. So this ended up having us pivot where the development team took control of the actual form layouts themselves and the form capabilities in the form of a static manifest of JSON information for those forms. So more broadly speaking, the development team had to get involved again and didn't really want to.
And it slowed things down, didn't really get us to where we wanted to be and was cumbersome. We made a lot of strides in where the UI was, and it still had more flexibility than where we had been because we had decoupled the services layer. So the services layer could now incrementally innovate independently. But on our UI side for how the CMS was actually putting those forms out, we still didn't have the flexibility we were looking for.
Enter in AEM Forms.
AEM Forms is where we took another crack at it and we said, "Hey, look, we know what the problem is now." We know we can't give all of the freedom to the authoring team because if we give too much freedom, somebody is going to put a piece of data into a form and because the backend's not aware of it, it drops it on the floor. So we didn't want to have that. So just to give you an idea of the various problems we had. When we originally started, the frontend and backend were tightly coupled. We didn't really have responsive experiences. We were still dealing with M. versions and full-blown things, and we required code changes every time we want to change a field. Well, it's an idea, right? But a lot of the web was like that then. I don't think it was anyone's fault. It was just more of a maturing exercise that I think everybody probably in this room has gone through with their own applications.
When we took our first crack at it, we realized we ran into some problems here also, where we didn't have the ability to create an intrinsic contract between the frontend and the backend fields. So if the backend needed a field, there's nothing, and it was required, there's nothing that required the frontend of the form to collect that information. So you could have a form that never actually successfully validates on the backend. Likewise, if the frontend of the form includes a piece of information, and the backend's not ready to accept it, it drops out on the floor. So that was a huge pain point for us. I mentioned the JSON authoring configuration thing and never again, we will never go back to that.
We also had to go build a lot of our own custom form elements on top of that. So to speak the language of forms, the HTML standard has a forms set of parameters that you should use, what an input field is, a form wrapper, and we had to go write these up ourselves and that took time to speak the native language of the web in regards to forms.
So ultimately where we got to is, then when you think about these in terms of the scale we had to operate at, we ended up, actually, where multiple of these solutions were, actually, coexisting at the same time on top of each other, which wasn't great. And we realized we needed to do something significantly to draw a line and innovate for where we were at. So I'm sure I'm not alone in it. Everybody who's probably had ecosystems that are similar. So we took a step back.
We had to define what we actually wanted to do. Our pain points around ensuring data integrity, giving freedom to authors, and being able to adapt our experiences to our brands, and at the same time, also, taking the development team out of situations they didn't need to be involved in, freeing up development resources for other tasks that we needed to go complete, and to do this for 3,000 plus forms.
And that's where we got to AEM Forms. So when we chose AEM Forms as a Cloud Service, it mapped to the things we wanted to do. So for example, ensuring data integrity, AEM Forms has something called the Form Data Model. So if you have a REST endpoint that has a particular schema, you can actually use the Form Data Model in AEM Forms to generate a series of, essentially, the schema for you on the authoring side that has the components that map to each of those form fields. And you can define that mapping and create this piece. But what this does effectively is it gives your authors a palette to paint with. They can't go create any color they want. They can't go use any component they want. But now because there's a contract between the frontend and the backend, you have eliminated both the risk of an author including a field that isn't captured by the backend, and the backend requiring a field that the author hasn't put in. So that Form Data Model creates an integral binding contract that makes sure the data integrity is there across the board. It is essential to making this work.
A result of that though is we've now given the business and marketing teams and authors a way to manipulate those forms. If they want to add additional instructions inside of the form or move the form fields around, they totally can do that. We are not dictating through the Form Data Model the order the data needs to be collected in. We are just saying this is the data you can collect. And any of the data that's required needs to be marked that way in the API.
By also doing this, AEM Forms brings you those standard HTML form components, right off the bat, out-of-the-box. Functionally, they all just work.
So that serves multiple purposes of one because they're all functionally the same. You don't have to go reinvent the wheel. That allows you to bring your brand's identity and styling to it without having to worry about rebuilding an entire set of functional UI components for the forms.
On top of that, it also reduced some of the burden on the development team around those pieces of not having to build the HTML pieces, but at the same time, forms also can be complicated organisms, right? You might have instances where you have branching logic, where people need to make decisions, and then you have new fields that open up based on what happens. In the old world, you'd need a developer to go code that logic. Probably have some JavaScript on the frontend or worst-case scenario, maybe you're backing it to the server when it sends the form as giving you different variations. But it's a lot more complicated, and again, absolutely needs a developer involved whichever way you go.
With the Rules Engine that AEM Forms provides, you now have a way to create those simplistic rules that are based off of the outcomes that a customer takes. So you could say, if in field 1 I say A, and field 2 I say B, I now get an entirely new set of forms options that have information I could collect. So it creates a more dynamic experience that allows you to maybe obfuscate some of the pieces of information you want to collect until you actually know that they're relevant to the customer to collect them. So the Rules Engine is extremely important. And what we found is as we were doing this that, "Hey, migrating this for our 3,000 forms." I don't say it was easy, but it was easier than the solution we were living with at the time.
So let's talk a little bit more about each one of these things independently. So we talked about the Form Data Model a little bit and that contract.
One of the things that this also does too is, you can have multiple authors working against these forms because your authors don't need to be experts in what the data is, the contract does that for them, right? So whatever type of information you're pulling in, that schema, that data model is basically making sure that the form will always submit. And that is like gold right there. Because what you don't want to do is have a form you think works, you go and fill it out, you get a success message, and then you find out from the person who's running the reports on your data that, oops, the data's all gone. It never actually made it anywhere. Or your error log is now flush with all sorts of bad data.
So there's a lot of things that are about the Form Data Model that I can't summarize all up here, but it is vital for teams that are trying to make sure that you have a connected platform between your services engine that is collecting your data and the UI.
And this is just a show of what this looks like under the covers. So one thing you'll notice is this form is not pretty.
And there's a reason for that. We actually apply the styling after the fact. So a lot of this, you can actually now gym the form up to have the data in the right spots, the UI in the right place, and then you apply your coat of paint on top of it, right? Now you can use the same form structure across all your brands. And it scales up really well and really nicely. You plug in an extra few couple data values that define the brand or define the dealerships you're working with, and bam, you have a working form. So now by templatizing this, we've cut down on the initial barrier to entry if we need to launch in a new region, for a new brand, so on and so forth. So saves you a lot of time, and then if you need to tweak that template, you could totally go in there and do that.
But on that left-hand rail, you'll, actually, see that they have fields and the different components they're tied to that show you all the things in that data model that are all the possible things that the author could pick.
I mentioned the out-of-the-box component library, but this is it in practice. So in this world, a select box is a select box. A radio button's a radio button, a button is a button. These things that are intrinsic to how forms work, you just get them. And our forms then can look as similar as we want or as different as we want, applying that coat of paint as necessary to introduce colors, typography, layout, where we determine it's worthwhile. And that reduces the burden on the dev team, accelerates our time to value. We don't, actually, need to worry about building components. The big asterisk on this.
You can build a custom component if you need to.
There are times that it might make sense. So for example, the first component in this page, on each of these pages, is actually the same custom component, and it actually lets you pick a make, model, year of a vehicle, and is communicating with a data service to facilitate that transfer of information. And the reason we chose to build it that way is there's a very specific set of business logic that also determines when certain things need to show up too and also pulls in things like image and price. So we determined the overhead for this repetitive task for an author didn't make a lot of sense. And the development team decided that they wanted control when that logic would change. So the goal is get to 80% reusability. You're going to have your 20% edge cases. That's okay. Getting to 100% out-of-the-box is almost unrealistic. But if you can reduce your overhead to the most important things to your business, then you can focus on them. Picking a vehicle's pretty important for us. The other custom component that's on these ones is picking a dealer, which is also really important to us. So those two things as being custom components made a lot of sense, but we also wrote them in such a way that, again, we decoupled services and UI and styling so that we could reuse the same component for authoring and bake it into our templates. So for authors, it became a seamless experience. We still have the data contract we need to have and everything is right as rain.
So that out-of-the-box component library-- If you haven't been there, AEM, I think it's again aemcomponents.dev has a full list of all of the components there that are possible with the AEM core components, but they also have the form components. It's worth checking out. It's really cool.
And then on the component insert list, you get all of these things that you would expect a form to be able to do for you. Right out-of-the-box, no questions asked, done. And that is really nice because then you don't need to go write all the HTL for it. You don't need to go write a dialog. But at the same time, if you want to inherit those components and build on top of them, you totally can do that. So it isn't one or the other or 100%. You don't need to go all-in on custom or all-in out-of-the-box. You have the flexibility, just like you do with traditional AEM in a lot of ways, to inherit what you want, build on top of it. You get the benefits of what Adobe has done to stand on the shoulders of giants, and you're able to implement these things really quickly and easily.
So yeah, at that point, you only need to build and bring your own styling. And this is where the magic happens, where we're able to basically take that brand agnostic form and add a layer of paint on top of it to make it look like the brand. And we can do that for each brand. If all of a sudden, tomorrow I got a phone call that was like, we need to spin up an entirely new brand, we would just need to add in a new style sheet.
That's it. So it ends up making it really easy and it makes a lot of sense for how we need to scale as an enterprise.
Rules Engine. So the Rules Engine is extremely powerful. I mentioned the vehicle make, model, year thing before. That's more of a complex thing because we're also changing things on the UI as a result. But if you have branching logic in your forms, things that are relatively simple, and they don't have to be simple, but you want to make sure you make the right decision around repeatability. This is where you could have something as simple as like, "Is this a personal transaction or a business transaction? If it's a business transaction, I'd like to know more about you." So we uncover a number of fields that are, again, they're in the Form Data Model that are then available for users to enter. We can even then flag those new fields as required...
Conditionally. So that provides a really powerful experience where we can begin to tailor the experience a little bit more for the customer around what they need to do, when they need to enter something, really making it feel organized and adaptable, and at the same time, sustainable with the API system we have in place around what data we know we need to collect.
So a really crucial bit for contextualizing experiences for your customers in order to create that branching business logic or conditional behavior.
So yeah, this goes into a little bit more of specifically what that looks like for authoring. So as an author, you can go ahead and select the component, it can be one right out-of-the-box. You create a visual business rule so you don't need your authors to know programming or your marketers to know programming. Use a visual rule set that you then go and put in, and then the form fields change depending on your answer. Pretty simple.
Overall, AEM Forms for us has enabled a lot of creativity for our business units. It's made it easier for us to streamline the operations we have and rolling things out. It's made it easier for non-technical folks to make forms and have those conversations in the organization to really rapidly turn around changes when they want to see them. There's a big thing, as long as it's in the Form Data Model, that's the big asterisk, it has to be downstream compatible with the data, it really makes it easier to get through the process and spend more time thinking about the customer experience.
We talked a little bit about the future, right? This is where I'm going to read the tea leaves a little bit, so the full speculation hat is on here about what we might do in the future. I have some of my product folks in the audience, so I definitely won't promise anything. But we're trying to think about what do we want to do next? Where are we going with our forms implementation? And for our forms implementation, we're talking about refreshing the component library. We started our journey with AEM Forms a few years back. And this was prior to the core components really being a big thing. So at the time, they had what were called Forms Foundation Components. Very similar idea but different. And in that notion...
Adobe came along and did the right thing and built a more unified, more current robust library, which is, actually, with the components you will see on aemcomponents.dev Those Adaptive Form Core Components are the new library that everyone's going to use going forward, and we want to update our library. And the actual reality is a lot of it's really easy if you follow the component inheritance model and never pick up a component out-of-the-box directly. You should proxy your components always.
It makes it really easy to switch from one to the other because you just change where the proxy's pointing to.
Again, for your AEM developers out there, that's something that should be hopefully pretty easy to understand, but the long and short of it is from a business lens, you're not locked in if you have a good implementation.
So refreshing that component library brings us up to the most current tech that Adobe has created. It gets us fully supported by Adobe. Adobe stands behind the core components completely. The original Foundation Form Components use JSPs, whereas the new ones use HTL. So there's a lot of modernization things that are happening around it, and they're what Adobe is using going forward into the future. So there's a lot of really great reasons that if you're not using the Adaptive Form Core Components, take a look at them. They're pretty great. It's relatively straightforward because the HTML underneath hasn't really changed, but this is where you might get a small performance bump from the AEM side. You're certainly going to be more compliant and it's going to be easier to overlay and extend those components as you need to.
We're also looking at form intelligence being a big thing. We want to make sure our forms are smarter.
Smarter about knowing who you are. In the automotive world, the account space is relatively new still. We've only a few years into our journey of trying to create really personalized, rich experiences around knowing who our customers are and creating a relationship with them that extends from the websites to the vehicle, to their phones, and across the board.
So we would like to get to a point where, with our forms, we extend out from those capabilities that we have around what's in our account lifecycle and experience. How can we extend what we know about the customer into that relationship? So I think there's a lot of opportunity there too.
Integration with CRM around dealer appointments. This is a big one. There are some regions in the world where we are testing things with different providers, but the overall goal should be to get to a point where we can actually say, you don't just want to test drive and then get a call from a dealer, right? We actually figure out how to make that make sense. We'll talk a little bit more about each one of these things independently, but here's the example I would give around that last one. So Sally is looking to buy a new Corvette. She's got one already, it's awesome. Okay? So she has decided though, that the brand new shiny C8 Corvette absolutely has to be in her driveway. She's got an account. She's already signed in with her phone. She goes to the website, she logs in.
We would like to get to a point where we actually pre-fill the information we know about Sally. There's no reason we shouldn't. We may not lock it in, and there's a little bit around the UX that you have to be careful with because somebody might be borrowing Sally's computer or whatnot, or maybe Sally's filling in a request for their spouse. But at the same time, we want to take the information we know into that experience and try to build out something that makes sense for Sally because we are under the assumption that it is her. And at that point, we also then want to facilitate that test drive that Sally can do. And depending on how she's gone through the experience, if she's coming in cold, maybe we actually get to a point where we pre-select the Corvette, then latest Corvette for Sally. We know which trim she had before, maybe, she wants the same trim. So we personalize as much of that experience as possible using the information from our account system to actually drive that.
And then on top of that, we want to make sure that if Sally has a preferred dealer that she bought her Corvette from the last time and really likes working with them, she can connect with an advisor, have the times that advisor is available, and actually pre-book a slot. This actually does something interesting too because GM's customers aren't just GM's customers. GM's customers are also dealers. So the dealers look to us in our unique relationship to help give them leads and pre-qualified leads that actually generate sales. But in this case, we can actually do something really cool for the dealers too where we can tell them exactly when Sally is going to come in, and they can know to have a Corvette gassed up in the lot, ready to go when Sally pulls up. That's powerful. And if you're Sally coming on the lot where the advisor greets you as you get out of your car and says, "Hey, are you ready for your test drive? Here are the keys." Has that ever happened to anyone here at a dealership? No. But it's possible. And we can create those experiences. It's within our grasp. We just have to connect the dots.
So hopefully, by this point, a lot of this journey makes sense of why those homegrown solutions don't quite work. They're great when you're doing the table stakes. If you need something that works and you need to build it and you need to build it fast, you can totally do that. But will it scale? That's the question. And that's where we often, as developers and marketers and business folks, we often struggle is the scaling part. So by transitioning away from our homegrown experience, we got to a place where we could reduce that development cycle. We got to a place where we could figure out what parts of the experience we actually want our authors to control and be able to manipulate. Where we needed to ensure the integrity of the experience and make sure that that would go all the way through and work end-to-end.
And once we did that, we were able to get from a table stake solution to something that scaled really well. And that enables us to think more about prioritizing, improving the customer experience. What are the next things we can do? And that's where all of those entry points from different applications where if you build a Corvette versus finding a Corvette at your favorite dealer are different. And we can make it smart, but it can always be smarter.
Likewise, the next horizon is those personalized experiences, the ones that feel like they were built them for you.
That improved customer experience is something you can't place a dollar tag on because once you get to being feeling like you have a relationship with the dealer or with the brand, that feels like you've made that connection. It isn't just a car anymore. It's part of the thing you do every day. It's something you interact with. A vehicle, being the second biggest purchase you will, likely, make in your life, that is something that you want to feel good about. And we should be wanting to make you feel good about it. So anywhere where we can drive those connections, those personalized experiences where we're reducing the friction and making it feel better for you, that has value. It has value to us as an OEM. It has value to dealers as the facilitators of the transaction. And it has value to customers who want to feel good about a very large purchase they're making in their lives.
So with that-- Thank you so much, Ron. That was extremely helpful, extremely interesting. - Thank you so much. - Yeah.
So before we go with questions with the audience, I have three questions for you. The first one is about GenAI. Being such a key pillar here at Summit, how do you envision GenAI in your forms management? So this is a great question, and I think GenAI is one of those things of, regardless of how you feel about it of whether you like it or not and whether you'd like it to go away, it's a reality, it's here to stay. I think at that point you then have to start to tilt shift your mindset to how are you going to make GenAI work for you, right? In the world of forms where conversion rates are everything, this does something interesting. I mentioned that whole thing around getting past the table stakes to where marketers and authors and business folks can try and play with those experiences, right? They can move fields around. They can decide what language helps convert the best. But what if they didn't have to do that? What if the system did it for them? What if they put in the outcome they wanted to see and the system generated three, four variations of it and then said, "Hey, let me put 20% of your traffic to each one of these and see whether the original or which one of the four variations perform the best." And then once they see a noticeable uptick, that becomes the new master variation. And now, not only do you roll that out in one spot, you apply that same mechanism at scale across the board. That's the power of AI. So in that world, I think from a forms management perspective, AI is a force multiplier for marketers and business folks to be able to look at something and be able to figure out how to scale those experiences in a really meaningful way that creates new opportunities that wouldn't have been possible just because of the sheer number of people that would have required to do it manually. Yeah. Thank you. I agree. New levels of productivity and time to market. Yeah. So now on the other side of your customers, how do you see GenAI impacting their experiences? Yeah, so for GenAI impacting customer experiences, this one gets interesting because I think it challenges-- You could get to an interesting perspective here where-- Who uses ChatGPT? Just out of curiosity, show of hands.
Would you call ChatGPT a form? Kind of is. You type information into it, right? You get a response. Well, what if we took what we know about you and tailored that conversation to gathering the information we needed to get from you to facilitate the transaction you needed? I would like to schedule a test drive. Hey, what's your name? Where are you from? What vehicle you're interested in? Do you know? What things are important to you about a vehicle? And you can have a conversation with the customer to essentially in the background almost fill that form out, but instead have that conversation lead people to the answer and then in the background as you're filling out that essentially that piece of data you would need, you can then say, "Hey, are you ready to talk to a dealer?" This is what we do. By the way, I also found that Corvette near you already. It's only this amount of money. It's right there, you can go have it. It's about pushing people in that right direction. And in a similar way to the way our SMART forms work, it's meeting the customer where they are. Maybe that experience for that form doesn't engage them as a unique experience, but it's tailored in the journey. Hey, I saw you were looking at Corvettes. You're looking for a good deal. There's an incentive right now. This dealership's offering it. Would you like to go test drive one? There's an appointment at 1 o'clock today.
You might just have to say yes if you're logged in. So it's about rethinking, I think, what that customer experience could be rather than what it is today.
Playing 20 questions with your customer is not at the most engaging experience.
But if you could turn it and turn it into almost human-like interaction, that's a far more interesting thing you could do. Yeah, agree. And getting you faster to those dollar revenues, right? - Yeah. - So last question for you, Ron. You talked about integrations and personalization in your roadmap, but I'm curious to hear what's the future of that roadmap? Oh, the future of the future. So now we're looking like light years ahead I feel like. So I think there's an opportunity where you see a lot of these things converge and how do we empower marketers and business folks more? How do we make it so these systems can adapt in ways that we didn't expect? That could be melding the experiences together where it's more seamless across your journey. When you want to look at inventory, we talk to you about what vehicle you might want to have or even having that conversation around where you could go. I think there's a lot of opportunity around melding the changes that we would like to see in the authoring experience and the customer experience together. And at the same time then bringing the data on top of it that we know about customers and about our own vehicles to create experiences that really don't have to feel like you are shopping or in a sales funnel. They feel way more organic.
Thank you. Very excited about your future of the future with forms, Ron. Okay. Thank you, everyone, so much for joining. Tomorrow we have two more sessions on Forms Hands-on Lab in the morning and later at 2:30, our Top Innovation session, we're going to show great things with GenAI in the forms world. And finally, please remember to take the survey in the Summit app to win either of these two great prizes. And with that, thank you all so much for joining us.
[Music]
