 Okay, everyone, I'm gonna kick it off now before anyone else comes in. We'll shut the doors and lock everyone in here. So welcome to my session. The session is how to demo like a champ. Essentially how to sell free software. Now the story behind this kind of tagline here is when I moved into the current role I'm in now, which is as a solutions architect with Acquia, and my parents said, well, what does that mean and what do you actually do? And I said, well, what I do is I go out to different prospects and different customers who are evaluating different web platforms and sell a free piece of software. How at Earth do you sell free software? So this is really kind of a story around how you sell Drupal, even though it's free, even though it's open source, and how you be the solutions architect, get the technical win, and demo like a champ. So a little bit about me to start off with. I'm almost at four years with Acquia, and I've done a number of different roles in the organization through the engineering team, professional services, and now in pre-sales. I'm around six years old in the Drupal community and started off as a developer, and I'm Typhonius most places online. Now that was a bit remiss of me when I started off and decided that Typhonius would be my online pseudonym because Typhonius is actually a species of toad. So if you do go and Google me and try and find out who I am and where I am online, realize that these three are me and these kind of lovely pictures here of toads they're not me, so just learn that distinguishing factor. So a little bit about Acquia. We're founded in 2007 by Dries Baitat, he's the guy who started Drupal. We are around 800 employees worldwide with 35 strong in APJ, which consists of our Australia and New Zealand teams, and we cover the entire region there that we're showing in red. So all the way up from sort of Japan and China, Dan through Southeast Asia and into Australia. So a question that I often get asked through people who don't know the industry and don't know the kind of thing I do is what is a solutions architect or what do you do? So when I'm in Ubers and things, I'll say, what do you do? And I'm like, well, I'm an architect but not for buildings, for kind of web platforms. So a solutions architect is really the person who a company would go to and they would kind of piece together their web platform that their digital portfolio for them. Then understand where the CMS fits in and where which pieces of integration would work for their platform. So really when I talk around the things that I do, it's around building entire digital properties and digital portfolios, much like an architect would do to buildings in a city. In terms of solutions architecture, the kind of component parts of this are fairly nebulous. It's a little bit of hand waving, it's a little bit of coffees here and there, it's talks, it's evangelizing. There's lots of different component parts. But really the solutions architect is the person who is with the customer all the way up until they make that decision on the technology and then slowly sort of fading off after that decision has been made. So where we're sort of definitely fitting in is gaining trust about the technology, being the trusted advisor, being the technical person who they can say, well, we don't trust the sales guy, but you seem technical, we'll trust what you say. It's being that trusted advisor to customers. It's defining solutions. They're sort of saying, well, we want this and this and this, but how on earth are you gonna do that with this CMS technology? Providing a demo for where we're trying to demonstrate that capability. It's being a spokesperson for the company coming to events like this and working as an evangelist for both Drupal and the organization. So really there's a lot of different kind of component parts and it's not so simple as to sort of say, well, my day-to-day is when I go in and I fill in these forms and I do this. There's lots of kind of nebulous sort of components. The thing I want to kind of talk about though in the next few slides is that whenever customers that I work with are undergoing any kind of digital transformation, quite a lot of time no one cares about sort of a lot of things in that decision. And it could be the name of the software. It could be the version of the software, the language it's written in or any kind of jargon. You start talking to customers around nodes and taxonomy terms and PHP and traits and conditions and formatting filters and things. They're gonna look at you blankly because to be honest, no one cares. No one cares about Drupal. If we were to go in there and say, well, we've got a wonderful Drupal for you. Drupal is a wonderful system and I actually have made three code commits to the last three months. No one cares because they don't care. They're business people who don't care about the nitty gritty of the underlying technology. All of it is around business requirements. Now this actually works in our favor as well because when we're competing against non-Drupal technologies, when customers are doing open tenders and looking throughout the entire marketplace for whether they want to use any kind of technology, the name of it doesn't really matter. Quite often people care about these things here. They wanna make sure that they're on a secure platform so they don't get hacked. They wanna make sure that editors can come and quickly edit a piece of content. They can come and quickly change a piece of content, push it through a publication workflow and not have to involve a developer in that because typically what we see is, when we ask the question around, okay, how do you get a piece of content from a Word document into being published live on the website? It's this whole extraneous thing where they have to go to Margaret in accounting and she has to go and check through things with a fine tooth comb, then she emails a copy of this document over to Fred in legal and Fred prints it out and puts red lines under things and when he's put the red lines under the things, he scans it back into the system, he emails it through to someone else and it's this horrible different workflow. They just want an easy system where different people can work on things and they can publish quickly. Personalization is another thing that they want as well. Definitely now as we're starting to move towards being able to identify who users are and start changing the looks and feels of websites based on who those users are and it's all about re-use of customer assets as well. So try not to think about things in terms of nodes and entities and entity references and language like that. It's all about meeting these business requirements because at the end of the day, it's often a person in the business team or the marketing team who's gonna be making the decision about the technology and if we're gonna be making sure that we win them over, it's about making sure that they're able to win their own staff over and give them an easy ride with the technology that we're supplying. So as I was saying, people don't look for the technology. They're looking to make things safer, easier, have more governance, have a strategic alignment with what their business objectives are, have a better experience to customers on the website and reduce the effort. All in all, they're looking to get more money into the business and technology, Drupal on its own? Sure, through these things can produce greater revenue stream for the business, for the organization, but these are the things that are actually gonna be causing that. These are the things that are gonna be ensuring that developers can work faster, that content editors can push out content faster and deliver the message that that business has to their users at a far more efficient rate. If we boil this down, it's really two things. It's preventing loss of money by having secure servers, by having a secure system that people are contributing to, that gets code reviewed at all times, and it's about making more money. Whether it's customer acquisition, customer retention, it's these two things here. So when we talk around what people are looking for, they're not looking for a Drupal. They're not looking for a WordPress. They're not looking for any kind of other technology. People are looking for a solution to a business problem. And this is really where I as a solution architect can come in, architect that solution and take them on that journey from what their business requirements are to fulfilling that with Drupal as a CMS in this case. So people are looking for solutions. Organizations don't look for code. Organizations look for solutions. And much like MacGyver here, I provide a solution. It just so happens that all of my solutions use Drupal. So I wanna talk a little bit now around the sales process because as a solutions architect, we are definitely in the sales team, even though we're an extremely technical organization, the solutions architect is often the prettier and brainier sort of cousin towards the sales rep in any kind of organization. And I apologize if there are any sales reps in here, but not really. So the architect sales process often starts off with discovery. In a discovery phase, we're gonna be trying to work out what those business requirements are. We're gonna be trying to work out where the customer is looking to go. The more we can dig into this discovery phase, the more that we can kind of find out how we can customize a demonstration, how we can really meet those business requirements using Drupal and using our technology. So in discovery, we're often asking, what's the current state and why is it causing you problems? And we see all sorts of things. We see terrible kind of half baked solutions whereby people are stringing things together with all different manners of technology and they've ended up using some horrific different collaboration. This is actually a whiteboard that I made with a prospect a couple of weeks ago. And as you can see, every single line there is some kind of different convoluted way of moving content and configuration between different things. So we've got, there's SQL sinks going to push content from staging to production because they had no way of pushing content in any other way. They couldn't do moderation of content in their production service so they had to do it in staging. They've got this weird system where they have to push images up to their production server through three different applications because again, their production system can't have images uploaded onto it. And because they've grown in this organic fashion, they're left with this kind of unclear sort of CMS technology and extraneous technologies which causes them business impacting issues. When we asked what their situation was for creating content and updating content to change any piece of content on the website, took an experienced person on their staff at least one hour, regardless of what it was. Typo in a piece of content, one hour to change, minimum. An inexperienced person, it took two hours because they had to go through all the processes, they had to go through all of the kind of deployment mechanisms and they had to involve a developer at the final step of the way. So we're pretty well-versed in Drupal here. If we were to hear that, we'd say, well, why aren't you using workbench moderation and giving a person with the right permissions that the right task to do that? It's because they've grown organically, they're using a legacy system and these are causing business impacting problems. So in discovery, we're often looking for where the problems are because if we can point at this and say, this is impacting your business because you can't push content up efficiently which means if you have any kind of special offer, any kind of way of bringing more customers to your website, you are slowed down. Additionally, your editors can only work at a rate of one article per hour. Whereas me on my very simple blog site, I can push an update in two minutes, one minute, whatever. It's a lot faster, I can do a lot more with my time. Using that time that the editors sunk into this work, they could be doing other things, other things that are in their backlog and if at every step of the way, everyone is being slowed down by these inefficient technical processes, it's gonna impact the business and so this is what we're looking for in discovery. Then we ask what the dream state is. We're looking for what the ideal kind of state is for any of the editors, the developers, anyone within the system. And again, this is one that I came up with for one of the customers where they've got all of their things integrated together, anything can be easily pushed between different systems and you're effectively siphoning off the developers to do their development work and they're not impacting on any content editors. The content editors are working in their own way and they're being able to do it in a far faster method as well. And then we ask what happens if you don't change? If your editors are continually held back, if they're continually having to work with all of these restrictions on the system, if you have to take developers off their standard, normal processes where they're enhancing the system, what's gonna happen? And much like any kind of disaster movie that you've seen in the last 10 years, it's gonna be a cataclysmic state. There's gonna be issues here, they're gonna lose customers, they might even go out of business. So we like to always harp on about Godzilla and whatever the other films are that included the Golden Gate Bridge sinking into the ocean and really bring that up as kind of a problem that could happen with their system. So after discovery, the next thing we aim to do as solutions architects is gain the technical win. Now the technical win is the thing that you need to get before you move on to the business win. If the tech guys at an organization aren't satisfied with the solution, they're not gonna buy into it. If the business guys don't understand the business requirements from a technical standpoint, they're not gonna buy into it either. So getting that technical win is the thing that solutions architect does as part of the sales process. Now this could be again through demonstrating, this could be again through proving that things that we do with our system occur at a lot faster rate than the things that they're doing with their legacy system. It's all around showing and demonstrating that the way that we envisage their system is gonna make their lives easier, it's gonna make their business more profitable, gain more customers and so on, meeting those business objectives. So getting the technical win, it's really important not to solution too quickly and this is a problem I had when I first started in this role. Quite often they'd say, so we need a way to publish content to the website. Oh yep, Drupal can do that. What you do is you would take a note and you would click on publish and there it is, your content is published. Take a step back, understand where they're going with this, dig in to what their technical requirements are before you try and provide a solution. So often the discovery process and getting that technical win, there's a lot of listening that's involved there which is important to formulating that demonstration and technical win. That second stage is this Smarmy guy here, I actually Googled for Smarmiest guy I could find. He's demonstrating the capabilities of this beautiful car website here and really that's fundamental to what the solutions architect does. They demonstrate capabilities of the Drupal system. Drupal is ugly when you first download it. You download and you install Drupal 7 or Drupal 8, it's an ugly system. So really what we'll be doing is demonstrating at a business level the capabilities that the business needs. The other thing that I like to include is the so what answers and this is kind of going back to that discovery process and looking for the what happens if you don't change. So a customer could say, well, yeah, we're currently publishing at one piece of content an hour, so what? What is the impact of that? Digging into those questions and taking it from a technical discussion into more of a business discussion as well. And finally, my favorite is using the five wise technique like any kind of kid who you know, where are we going? Are we there yet? Are we there yet? Use the five wise technique on your customers to understand what their requirements are. So what is the five wise technique? The five wise technique is actually one that one of our solutions architects in our team came up with to understand any requirement or understand any issue at its base level. So quite often we'll get a customer who comes along to us and they'll give us some kind of weird requirement, really niche specific requirement. I'm sure you've all heard it, you know, we need to do X. And the five wise technique is to ask why five times and we'll get to the base requirement. So we need to, we need you to install ActiveMQ on your network on the Acquia Cloud. Why do you need ActiveMQ? Well, we need a Java messaging service. ActiveMQ is so we need that Java messaging service. Why? Well, we need to exchange data between Drupal and multiple endpoints. Uh-huh, yep, I think you see where this is going. Why do you need to do that? Well, we need to synchronize our content and our users. And in this room, I'm sure you're starting to realize that you don't need ActiveMQ to synchronize content and users. That's a very niche kind of solution that they've asked for as part of a really broad requirement. Why? Well, content and users are created on legacy systems and we need to move them into Drupal. So could you use a message queue like Amazon SQS and use the Drupal migrate module? I reckon good, yeah. So quite often, all of these business requirements, all of these kind of things where they're asking for niche solutions can be brought back to what the broad technical requirement is using the five wise technique. Once you have the base requirement, you can take them from needing something that maybe Drupal can't provide to being a very general solution that we all can implement and that we can demonstrate very easily and effectively to the end customer. So there's our technical win. The other things which I don't get involved in because they're very sales related to the business win and contract negotiation. As a technical person, I don't care about that. I'll let my sales guy do that and I focus on working for the technical win and working in that discovery process. In any kind of technical role before a customer has decided on our technology, before they've become like all of us and they're saying evangelical about Drupal and saying it's absolutely the best CNS in the world, people will object and they'll throw out objections in all ways, shapes or form. These are a few that I receive in the last six months. Open source is insecure. Get that all the while. Open source is insecure. Just point to examples of any of these different things that will mitigate those objections. You can say to them, okay, do you think open source is insecure? The White House website is running open source. The Australian government is running open source. These are some of the most attacked websites in the world. Do you think they'd be running open source if it was insecure? You know, as Troy said earlier on today, people are attacking websites at a great rate. Do you think some of the most high profile websites would be using an insecure technology? And again, quite often they say, well, okay, I guess that's a good reason. Drupal doesn't include a marketing suite. Drupal has no roadmap. There's no support. Drupal is for hobbyists. All of these different things can be gotten over by handling the objection and taking it from being this kind of thing that they heard from years ago. Drupal 4 is an ugly duckling, all of this kind of thing, and elevating it to a different level by providing real-world handling to these objections. And again, I'm sure if you've ever been in a situation where you're working with a customer who hasn't bought into Drupal yet, who hasn't decided that Drupal is their CMS, they haven't put the Drupal icon on their shirt and got the tattoo on their sleeve and things, you'll receive these objections as well. And these are some of the most important things to try and get over, because if you can get past these, you're aiming further towards that technical win. So the demo, and this is all about demonstrating capability. Why do we demo? We try and demo to prove that Drupal meets the customer's required capabilities. These are the things that the customer absolutely has to achieve in order to take their business to the next level, in order to ensure that their business doesn't fail and so on. We wanna show off what Drupal can do. We don't wanna just say, well, you can download Drupal from Drupal.org and install a few modules. I think the views module is pretty good, so maybe you can download that. We wanna show them our expert opinion of Drupal, and we wanna put together a cracking demo that will show the best parts of Drupal without all the ugliness that we've all faced as developers of trying to get that system started and understand it from a technical level. All of these sort of come in here to show how Drupal as a system will benefit their business. If we can show that content editors can work faster, if we can show that there's an entire marketplace of supported, security-assured extensions that they can bring into their system, their development time will go down by half. All of these things are gonna be aiming to get that technical win. The demo is extremely important in that, and I'm gonna show you in a little bit how to effectively demo Drupal. So how do we demo? These are some of the most important things that I've been taught as part of the pre-sales role that I'm in. Demoing isn't about teaching. People will be taught once they've bought the system, once they've decided that Drupal is something they want to do. Being taught how to use a system is vastly different from being demoed the capabilities of the system. I'll show the difference between teaching and demoing later. We've put together some demonstration tools that are all Mac with all open source, and I encourage you to use so you don't have to build demo sites from scratch, and I'll provide the links to those in a little bit. Using these demo tools, you're gonna be able to start demoing at a far faster rate, and you're not gonna be having to put together custom websites every single time you demonstrate. Final one here that I wanna really focus on, holding court. You are the guy that they are looking to. You are the person who is gonna be their trusted technical advisor. So you're gonna be the smartest person in the room when you're doing a demonstration. You're gonna be the person who is really taking them on that journey for not knowing what this technology is to trusting and understanding this technology, getting the tattoo on their arm and saying, I love Drupal, I'm gonna go to Drupal Saft 2017. So this is a shit demo. Because this is Drupal 7 out of the box, uploaded a bit of a coffee mug on there, but I've seen this demo, I've seen Drupal demoed in this capability. We don't demo like this because honestly, where are the business requirements? Where is the ease of use? Where is a customer saying that looks like it could be my site? Instead, what we'd rather do is put together a site that looks like it's an actual Drupal website that's running in the wild, where customers can say, oh yeah, I can see my content editors doing that. Yeah, no, we create articles exactly like that and we put together pages and manage our users in that fashion. So this is really where I want to stop sort of sounding over here, head over there and run through a couple of different demonstrations. So two demonstrations. So I've got up here an example Drupal 7 site that I installed earlier on today. A demonstration that I've seen where someone teaches and they don't demo goes something like this. This is Drupal. Drupal is an open source PHP system. It's currently on version eight. This is Drupal 7. I've installed Drupal 7 because there are a few more modules that are available. A module is a collection of PHP code that consists to get a piece of functionality. I'm gonna add a piece of content now and show you how editors can create content. Gonna click this button here. We've got two pieces of content. We can create an article or we can create a basic page. I'm going to create an article because that will show on my front page. Gonna enter in a title. Gonna enter in some tags. Gonna enter in a body. And I can upload an image here as well if I want. This is an image of Manila. Down here in these settings, I can create a new revision if I want. I can create a separate path alias if I want. I'm going to call this one example. I can turn comments on or off for this article. I'm going to turn them off and I'm gonna publish this one straight away. There's my example piece of content. If I go back to the home page, you can see the example piece of content is there as well. Really selling deep and all that. So that was terrible. A lot of that was teaching. You're showing the customer where to click. You're running them through the kind of process that should be later on after they've decided to implement Drupal and should be the kind of technique that you implement, maybe with a little bit more charisma, with their content editors to help them understand how to create content on the website. We're not talking to the people who are gonna be implementing the content. We're not talking to the people who are gonna be writing the content on the website in most cases. We're talking to the people who want to see that their editors will have an easier time of doing it and that's just not showing that. What I'm gonna show now is how we would demonstrate Drupal functionality at a more business level. So what we've got here is we've got an example website. Now this system uses Drupal and I'm gonna show how an editor can easily change any of the pieces of content on this website without going to a developer and without having to run through a complicated content moderation workflow that would take their time up. What you can see instantly on this website is that this top black bar is a demonstration of Drupal's strong granular permission system. Drupal will only allow people to access the things that they need to on the site to get the job done that they need to do. As an administrative user, I have access to all the different varieties of content and configuration and moderation on the website. So I'll run through this process now. Over on the left-hand side, we can see our easy content moderation toolbar. This allows an editor with one click to create new drafts of content in a safe environment so they can work on content without pushing it to production and without having that fear that they're gonna be pushing unmoderated content to production. I'm gonna create a new draft here and I'm gonna put a log message in so anyone who's looking at this piece of content, anyone who's looking at this piece of content is able to understand why I've created that draft. Now when this page loads up, what we'll see is in the top right-hand corner we've got access to a new editorial interface. I'm gonna click on this and this is gonna turn on edit mode for my site. This allows the editorial user to customize any individual aspect of this page. Again, making sure that they're able to customize the look and feel of page without passing a developer or without going into complex power user backends. I've clicked quick edit and with this editing tool, any component of the page is now able to be changed by the editor using this easy WYSIWYG. I'm gonna go and make this wheel bold, maybe change this over here with an italic. All of these at the moment, using a tracks changer system which allows any user in the system to know who's changing what and why they're changing it. All at the same time, giving that editorial oversight so you know why you're changing things in the system. By clicking save, the editor can instantly see a preview of what their content would look like on the site in a safe environment. Scrolling back up, I'm gonna pull out my editorial tool again and again, using Drupal's strong and granular permission system, me as a content administrator would be able to push this content to production straight away without again involving a developer. So now in less than two minutes, I changed a piece of content on the website, I pushed it to production, I sent it through a number of different moderation workflows if I wanted and my content's live. This is gonna save your editor's time, it's gonna allow your editors to work a lot faster and a lot more effectively and it's gonna allow them to use simple, easy-to-use tools to accomplish their job. A little bit different, right? So the idea behind why we demonstrate and the things we use to demonstrate is to say what is possible, not what is actual. The actual way of installing Drupal, adding in modules, extensions, these kinds of things, that's for the technical people to worry about and it's not a business discussion. What we wanna be doing is demonstrating what is possible with Drupal, easy editing, quick, easy media upload, the ability to have a media library, syndicated users, single sign-on, any of these key pieces of functionality, Drupal would do all of it, absolutely using the marketplace, using the tools available. We just wanna demonstrate that, this is what's possible, not what is actual. Any questions? How much time would you recommend if you did not already have a demo site that you would put into that demo site? So I use the demo framework, which is something that Acre has created for it's an open source distribution. Now with the demo framework, you get something similar to the site that we just demonstrated. If I was doing a custom demo, I would spend three to four hours putting in content for a really big sort of customer, putting in content, putting in some CSS to essentially make that site look like what their customer site would look like, make it relevant to the industry, make it relevant to the vertical, that kind of thing. I am very lucky to have the demo team and the demo framework available because if I were to create a site from scratch for every single customer, it would take a couple of days to bring in all the right modules, enable the right functionality and so on. So I typically don't spend more than three to four hours just to do sort of a standard Drupal demonstration. And sometimes it can be even less time than that because the capabilities in the system are so fully featured. Sorry, this is probably more of a technical question. I'm just curious to know, in that Drupal 8 instance that you're using there, you had sort of live and situating tools and I thought that was dropped out of D8, at least out of core? I don't think so. Anyone? I think in-page, the IP stuff is still in core. I might be wrong and I have to check that later, but I'm pretty sure that's still in core. Okay, thanks. That was Drupal 8. Yep, Drupal 7 and Drupal 8. Yeah, it might be called DF, but it's available in Drupal 7 and Drupal 8. You might also want to use Lightning, which is another open source tool that Aqua has created. Oh, sorry, I think you're right. So Lightning uses demo framework, so Drupal 8 is Lightning. Demo, yeah, yeah, yeah, yeah. For, I mean, you mentioned before, remaining kind of technologically agnostic. For customers that do come to you, that'll like set on something, you know, another platform. How do you bring them around to Drupal? Is there anything like you specifically say, or do you just run through the demonstration process? So absolutely there are things that you can say, and it's all about understanding the business requirements and where they're looking to go as an organization. If they are swaying towards proprietary software, then we can mention things like how open source does have the ability to be more secure because there's many more people looking at it. We can also mention that with the exorbitant license fees that they could be paying, they could be better extending their system and essentially making their money go further. We'd also talk around, you know, the ability of the Drupal marketplace to allow them to move faster because there's all of these tools that other people are creating and maintaining. So some people are always set in their ways and they'll never go with Drupal, no matter what. But if a customer has sort of a sway towards another system, you can always bring them around as long as you understand their requirements and as long as they're not dead set on that other system. Your demos, are they always customer-neutral or do you sometimes bake in requested features? So quite often the requested features are actually already in the demo. Quite often we'll have customers who say, we want to moderate our workflow, we want to integrate with social, we want to have drag-and-drop editing, which is one of the things I didn't show, and all of that's baked into the system. There are a couple of times where a demo will require something that isn't baked in there, and that's where myself or one of the other solutions architects will do a little bit of custom stuff and essentially put that in the system. I did one not so long ago that required Snapchat integration. That was great fun. Took me about eight hours to do, but by the end of it, they uploaded an image, they put in some text, and the image was compiled with all this text on it, it uses image magic and GD and that kind of thing to show handwritten text on an image. It was great fun, but that's more rare because quite often their requirements are basic. Just from a technical point of view there, I noticed that you're demoing with Acquired Dev Desktop locally. Would that be your approach most of the time as opposed to putting something up that would be in a shared environment that other people on your team or the customers themselves could play with? I would typically use Dev Desktop for speed issues. If we are, I mean, when you're demoing, it's like a third to performance. It's much like this talk here. If something goes wrong, you've got to roll with it. If the cloud times out, if you get a DDoS on your DNS provider like happened last week, you're screwed. So try and control the variables. By using Dev Desktop, I can control what's happening in my system. If you're starting to use external services like Twitter and things and you want to bring them in, yes, you can do that, but it's all around trying to control the environment as much as possible. So I would always sway more towards having a local environment than putting something in the cloud. Is there a good framework for GovCMS yet for doing demos? So it depends on who you're demoing to. So GovCMS, I'll take a step back. So the Australian government and the GovCMS program allows government agencies to use Drupal and public cloud. They don't have to use the GovCMS framework if they don't want. If they want to use the GovCMS framework, then by all means you could download GovCMS. And I've actually got a couple of GovCMS demos on YouTube where I run through some basic functionality of GovCMS. But we do have government customers who come to us with certain niche requirements that would preclude them from joining GovCMS. So either use the GovCMS distribution and run through a simple content editing workflow using the pre-installed themes or just demonstrate Drupal because in slide three or whatever, they don't care about the versions. Like we're not demonstrating a version if we're getting a government customer who is evaluating between Drupal, GovCMS and SharePoint, for example. So win them on Drupal and then let's make the decision about which kind of Drupal they go for. Five minutes. Any more questions or are we good? All right, thank you ever so much. If you have any more follow-up, see me outside or get in contact.