 Hello, welcome to our session about getting the technical win or how to position Drupal to a skeptical audience. This isn't a technical session, it's a sales session, so we won't go into detail of which system is better. We won't go comparing features or functions between different systems, but we'll look at it from a sales perspective and how we can leverage the technical features of Drupal to win a deal. So maybe before we start by a show of hands, who's on the sales side, who's on the technical side, who went to the pub crawl yesterday, I saw that. So maybe a little bit about ourselves, so can you hear me without the mic or do I need a mic? Okay, cool, so I'll try to stand still. So a little bit about us, we're a very eclectic bunch. We have Cameron, he's a Kiwi living in London. We have Raphael, he's from France, Paris and myself, I'm from Belgium. Dale introduced himself later on in the session and what we do, we do all sorts of stuff. So we're pre-sales technical consultants at Aquia, so we own the technical part of the sale. We help salespeople position Drupal to customers and prospects and we handle objections and suggest solutions based on Drupal. But before we go any further, I have some really sad news before we can start our session. It may be a bit harsh, so it'll get better. The next slide will be very, it could hurt a little bit, but we'll put it into context. I'm sorry. But looking at this conference, we all know that this is not true. We all are very passionate about Drupal. We know it can do a lot of cool stuff, but if looking at from a customer's perspective, they don't care about Drupal, they only care about certain other stuff. But on the bright side, nobody cares about Adobe either. Don't take a picture of the slide. It can't leave this room, right? So nobody cares about Adobe, nobody cares about Sitecore and nobody cares about WordPress. So it's a level playing field for everybody. The only thing that people care about is solving their own problems. That's what we need to achieve. So how can we make people care about Drupal by solving their problems? So we need to dig into what their problems are. So it could be doing stuff cheaper, could be doing stuff faster, better, easier, or they have a, the market is changing, they need to increase revenue online. So different needs, different itches that we need to uncover. And Drupal can handle a lot of that. So we will try to make people care as much about Drupal as we do, or the 2,200 people that are around here. So we need to make other people care about Drupal. So we'll go a little bit into the sales process and how we can uncover needs or problems and how we can match Drupal onto that. So a lot of stuff is happening. So people on the sales side know this inside out, all the steps of a sales process. We won't go into detail of all of them, like lead to qualification, which is pretty important. RFPs, let's hope not. I think we all hate them, right? RFPs. Okay, cool. We'll go into the needs analysis, so discovery and trying to learn what they're trying to solve. And a little bit into the presentation, demo and proposal phases on how to handle objections. So Cameron and Drupal will be dealing with those. So first thing that we need to do, even it's called getting the technical win, we still need to talk about business side because that's basically where the money comes from and they have a problem. So we need to uncover what the business wants to solve, basically. Once we have that established, we need to remove the technical blockers. So notice how we don't say convince people of Drupal, we just take away the technical blockers. Once we establish a business case, there will be certain blockers that we need to take away for them to agree on Drupal. So convincing people is very hard, removing blockers is easier. And then third part, Rafael will talk about demo and how it could be important in a sales process and what to watch out for and if it's needed, yes or no. So first of all, about the business case, we need to uncover a lot of stuff. So we need to do research, we need to talk to a lot of people, we need to get the pain points from different stakeholders, in a enterprise you'll have different people having different pains and they all trickle down. So let's say, for example, a marketer can put pages up quickly enough, which leads to less revenue or less leads, that's the CMO problem. So they all have a different problem. So by uncovering all those problems in the different areas of the organization, you can actually build a map of what they're trying to solve. Mostly it's not about one problem, it's not about we need a new CMS to generate pages, that will be a very hard win. But if you can uncover why they need a new CMS by asking the right questions, you can actually map your solution onto those problems. Doing some research, what is their competition doing? What is the market evolving to? If you look at newspapers, they're all running to a new digital roadmap. So by knowing that, you can actually help them solve their problem as well. And take a step back, that's our favorite sentence in pre-sales, because if you look at a problem, us as technical people, our brain starts working and we're trying to solve it immediately. So once in a while, we kick each other just to take a step back and to look at the whole picture. So uncovering more than just a problem at hand. So Drupal can be more valuable. Let's say, for example, a company wants to do blogging, for example, if you only see that problem, then Drupal might not be a good fit, because maybe WordPress will win. But if you can uncover that digital roadmap, then Drupal could be a very good platform to do all of that stuff. So how do we do that? Ask them the right questions. Doing a lot of research. What is at stake? So will they lose money? Yes or no? This is a very important driver for new CMSs. Also by asking the right questions, by knowing they're vertical, you can really establish a trusted advisory relationship, which is really important, because they'll start listening to you. You can give them suggestions on how they should look at problems. Drupal will go into detail, but not always saying yes, and being a hard ass about some stuff, and not just going with everything they want, because we all know that customers don't always know what they need. So helping them there is a very powerful driver as well. Some questions to ask. To different people in the organization, what are your three major pain points? That will uncover very explicit pains that they need solved. Asking those questions to a CMO, to a CIO will give different answers, enabling you to map the problem. Very interesting question that we like to ask is what does success look like? It enables people on the customer side to think about what their ideal situation is, actually giving you almost a blueprint of their ideal situation. So we can use that to move to it. So we can leverage that knowledge and build Drupal and make it fit into that ideal situation. And another very powerful question is what happens if you don't do this? They could go maybe bankrupt, they could lose a business unit, whatever. So that will give you a sense of urgency or how big the pain is to solve. That all helps you in the sales process and will help you map the technical solution. So some common mistakes that we encountered that we probably did ourselves as well is basically not talking to the people that can make a decision. Because they only see maybe 10% of the problem. You might solve their problem, but their boss doesn't have that problem so he doesn't care. So he won't sign off, no deal, and we're done. Not understanding the pressure to contract, is there a compelling event? So do they need to go live by a certain date? If that person can't answer that question, he might not be the right person to talk to. You need to go higher up. So you could be wasting your time as well. Rafael will talk about demoing. Really important not to demo too early. So like carpet bombing, coming in and showing everything without understanding what they actually need could hurt the deal and you could actually just look ridiculous at some point. So that's very important. Another one is about credibility. So balancing what they actually want and what the market is evolving to. So helping them understand what they should need to, not all customers know about the digital roadmap or what's happening on the internet. So you can help them and really establish that trust relationship. So that on the business side. So we uncovered the pain. Now we go into why they should use Drupal. My friend Cameron can talk about that. Yeah, so I guess the reason we're all here is the pesky tech. I'm just going to quickly introduce myself. I am a solutions architect like Fred and Raf from New Zealand. I live in London and responsible for the UK and Ireland region. In fact, where if you're a partner I may have worked with you. And I've been at Acre for about two years. Before that I was a developer for seven years. So a lot of this sales stuff is really new to me. But now I've found it really fascinating and a lot of things that happen in technology are because of human factors. So I'm sure I don't need to convince you of that. So I'm beginning to learn in detail. So what are the technical themes that we see in pretty much every deal or customer scenario? Drupal is not the strongest tech, but there isn't actually a strongest tech. There's no magic bullet. There's only something that's appropriate for the time. And there's a lot of ways that you can pick holes in Drupal or any other tech. You'll often go into situations where people will have a favorite technology. So if you go into an incumbent who's a Microsoft house or a Java house or they really like hacking on Python or they love Ruby, you just need to recognize that and answer why Drupal can do what they need to do and solve their problem. And it may not compete directly on particular things, but you don't want to get into that game because you'll always lose. You're removing technical objections. You don't want to waste your time. Can you do one step forward? Oh yeah, sorry. That's better? Sorry, guys. Yeah, so you're trying to remove objections. You're not trying to convince people. When they say, you know, Drupal doesn't scale. Well, yes, it does scale and we can demonstrate why with strong examples. You don't want to spend your time arguing about the minutiae of technology when there could be much more important things at play, for example, if someone's asking you about reference counting in PHP 5. But the whole project depends on connecting to a CRM, which is never going to be opened up over the internet. That's where you should be spending your time. You want to try and identify those things very quickly. And there's a bit of an art to that, which you grow. You know, you grow that skill over time, but identifying those high impact questions and activities is very important early on. So kind of on the more positive side, I think we can agree that Drupal has the biggest community and it has huge technical resources. So that speaks to, in real business terms, you can find developers relatively easily. It's a lot easier to find a Drupal developer than a CQ5 developer. There's a huge module ecosystem, as we all know, 30,000 modules. And you can guide people through that, which adding real value. I think that we often say at Acquia, with our wonderful marketing team, is that you can innovate at the speed of the web. So you're not locked into a roadmap if there's a module for that. You know, there's some way that you can find a solution to the problem that's mature, it's tested, it's secure. But it's all very well-seen intellectually, but you must learn on your examples. So it's very important to have some stories, maintain a narrative of technical problems that have been solved with Drupal, preferably in the customer's vertical or in someone they know, and there's a lot of resources around to have that. So if you're lucky, whoever you work for, whatever work you've done, you can talk about that directly. If not, there's a lot of resources available. So there's a DrupalShadeCase.com, Acquia has a lot of case studies and resources on the website. And you know, there's a lot of sessions here, but Drupal is not short of success stories. And this thing about practical objections is really what I was talking about earlier, that you need to think about the actual end result. Don't get stuck into the detail where it's not necessary. And the whole thing is building up to view being credible and trustworthy. It's okay to say that Drupal is not the best. It's okay to say, no, we can't do that, or there's better ways to do that in other technologies, because that builds you up as someone who's not there to bullshit them. You're not there to act like a yes man. Saying no can be very, very powerful. So things you should remember during that process. Focus on the achievement. When they say, can Drupal do this thing? You say, yeah, it can do that. We can do it with views, or we can do it with a module, or we can look at how NBC did it. But don't dig into the detail. It's sticking to the bigger picture at all times. It's often a mistake that I, as a technical person, and I've seen other technical people do, is to dig right down into the detail. It goes to what Fred was saying about being passionate about the technology, digging into the fine detail. Generally, most people in the room are not concerned about how things are done. They wanna know that they can be done. The how will come later. You'll find that there'll be people in the room that will wanna dig, dig, dig into a particular point. That's your opportunity to build a relationship with them and say, hey, I don't think this person's speaking for the whole room. Answer them respectfully, but offer to go into more detail later. And if you can build up that relationship, that's something that's on your side for the future sale. These haters are gonna hate. There's people who wanna stop you succeeding. You might threaten the credibility, or their job security. They might like their own tech. They might dislike your tech. You have to respect their position, but you need to align yourself with the people who can make the decision and who aren't gonna kind of waste a lot of your time. So there's no point getting into the argument with the lead developer if the lead developer is a contractor who's gonna leave next week and the CEO really likes Drupal and he's got a roadmap that's stretching out for the next year based on an open source technology. The kind of things that I see getting challenged a lot. There's a lot of things, but these are sort of very common. Security is a big one. I think that really goes more to hosting in most cases than Drupal. And there's references that everyone has on the tip of their tongue like the White House, a lot of US federal sites, there's a lot of financial services sites, the New York Stock Exchange, Will Pay. These are companies for whom security is of the utmost importance. I think we all agree that Drupal's very secure. And you just need those references. There's the Drupal security report, which is open and available, which will go into more detail. And the hosting provider that you choose, I'm sure, can stand behind you on that. In the larger incumbents, particularly on the non-technical side, we'll have a mistrust of open source. Someone who's been working in Microsoft for the last 10 years doesn't like you coming in and saying, oh, we've got no license fee, we're gonna take away your recurring revenue based on commission, whatever. Or people just don't, they've haven't worked with open source, so don't trust it. That's an argument that I think we should all be able to make. And there's lots of resources around about why open source is a great solution. Similar theme is that we're the underdog, perceived maybe not always actually an underdog, but we can be perceived as an underdog compared to incumbent solutions or big organizations. And failed or poor implementations. So a lot of that comes down to a place where projects fail, no matter what the technology is. A lot of it comes down to project management, but this is a point where you can really demonstrate your value. You can say, yeah, Drupal is a huge open source community. There's 30,000 modules. It's very hard to pick your way through all of that to find where the sweet spot is in terms of quality and reliability, but we have that experience. We know what we're doing with Drupal and we can demonstrate that with example A, B and C. So this is a really good position where you can differentiate yourself as opposed to Drupal. Support and long-term viability I think is a very valid concern, but I think it's demonstrated that a community of this size with this much momentum is not going to fold away tomorrow. And there's a lot of commercial organizations that can provide support and maintenance with an SLA attached. And I'm sure you know some of those names. Drupal can demo poorly, but I think RAF is gonna cover that with great skill. Just remember, this is what people wanna hear. Can we do it? Yes, we can. So people are gonna argue with you. You just wanna remove those objections so that they have no reason not to say yes. So my name is Rafael and I'm based in France as you can hear with my thick accent. Sorry about that. So before actually talking about demo, I'm just wondering how many of you guys actually do demos in the sales process? A few, okay. So do you guys, who amongst you have prepared demo and that you run all the time to the customer or who build custom POC each time? So who build custom POC each time for demoing to customer? Not a lot. Okay. So let's talk a little bit about demo. So for pre-sales like us, sometimes we are sales guy saying, okay, I've just heard that customer on the phone. He wants to hear everything we have, everything we can demo. Let's have two hour demo meeting and show them everything. So in this case, well, no, that's not a good idea. And as Fred said, our favorite sentence in the pre-sales is let's take a step back because what you want to do with the demo is not demoing the full power of Drupal or the full power of your product. What you want to do is insist on a few key points that really impacts the customer decision and you want to stress these points and not just saying, look, what Drupal can do, everything. Yeah, but if you start that, you will never end the discussion because you can do everything with Drupal with any other tool. So you really need to find what the customers wants and just build a custom demo that fits this requirement and will speaks to him. He will understand what you want to show and understand that Drupal will be able to do all the other stuff that all the CMS does but he wants to have the proof that some of his concern will be answered with Drupal. You want to do the demo only to get the technical win and not to try to sell something. You're here to propose a solution to his problems. As Fred said, he wants to have solutions. You're not here just to sell all the products you have. So that means that you really have to push back all the demo you are asked to do. You really want to do the most, a lot of meetings with the customer and try to really understand what he wants because at the first time he will say, I want this and in the end, you will be demoing something completely different because you find out that he wasn't really sure of what he wanted. So try to really understand him, ask a lot of questions and once you think you really know what he wants, demo that and show him that you understand him because that's the main point. If you understand that you understood him, he will trust you even more. And don't depend on the demo to win the deal. So there's a lot of people here that didn't raise your hand so you don't have to do a demo but sometimes that can do the real deal, that can really help you sign the deal at the end. So having prepared demo, so not all of you do custom one, so we really think that having a prepared demo with a beautiful theme that the customer can relate to a real-life website and not just the basic Drupal theme and with contents and scenario pre-baked in the demo with a lot of user and being able to demo workflow and stuff like that, all that matters to him and not only just a few modules that you put together and say, look, you can do all that with Drupal. Don't forget that people like pretty things and especially in the business and marketing area, they want to see stuff that is good, that is very easy to use, then can do stuff like drag and drop and beautiful hijack stuff. They want to be impressed so don't forget about the work effects that can really help you during the demo and try to have stories around your demo, just not just saying, this is feature A, this is feature B, et cetera. So as you can see here, it's just what I think is not a great example of what you could demo. So I'm not saying that it's not a good website. I'm saying that if you want to demo stuff on this page, there is way too much information in it. So the audience will be losing trying to find out what are you talking about, which feature are you demonstrating, et cetera. So try to separate all the features in different pages so you can just navigate and have a clear discussion with the customer of what you're trying to show them and not just say, look, Drupal can do everything. So it's always the same, you have to know your audience. So if you have technical people, you can deep dive into technical stuff, but if you have business and marketing, you just want to tell a story that relates to what they want to hear and what they want to achieve. So don't, how do you say that? So really try to figure out what their key user story that they want to do in their new website and try to make them into the demo. And to do that, it's the good idea to have a very powerful demo with a lot of stuff in it, but you don't want to show them everything you have in the demo, but during the conversation, if they want to see other stuff, you have all that stuff built in a good demo. So have a big demo prepared, but just want to show them just specific facts. And as it's a conversation with the audience, then you can just move around on the website and show other functionality that you have. Don't forget to look at them and don't be mechanical. I know that some of us might do the same demo over and over, and at some point, you can just do it like a robot, but don't forget that this is a discussion more than just a presentation. So yes, you have the demo behind you, but everyone wants to keep the conversation open and built on that trust that Fred and Cam talked about and just saying, yeah, this is how it works, this is how we've done it. And if you have that trust, that means that when you have demo effects, you don't have to panic that much because if it trusts you, if you demo a lot of stuff that are currently working, if you have some glitches in your demo, that's not bad. Try to just do a joke and get out of it. It's not always easy depending on what was the bug. Hopefully it was a small one, but yeah, in the end, it's more, it's a lot about having a discussion and getting a good relationship with the customer. Try to say, try to stay simple and not to just say, everything that we can do, this is very complex, we build that, that, that. No, just say, it worked like this. This is what you wanted, right? Yes, so have big impact with simple sentences and simple example. Don't forget to have backup plans. If you don't have internet, you want to have a local version of your demo and maybe your local demo won't work for any reason, so you want to have backup on the internet. Have a checklist of what you want to do. Some people love to have full scripts with all sentences and rears that and why not, but try to not read it and just, it's still the same, having conversation and making people interested in what you're saying and what you're demoing. So that's why you have to keep it at the very few key features that will still interest them. If the demo is two hour long, in the end, no one will care about what you're saying and what you're showing. And remember that there is a lot of way to do a good demo, but a really bad demo is, can be just worse than no demo. You can lose deal because you just messed up with the demo and after that the customer is just, he doesn't understand what you're saying, he doesn't understand your product anymore. So he's just saying, okay, your product is not good. So have simple one or don't have one. And just a few words about building a large proof of concept when you do custom demo every time for the customer. I would strongly advise to be aware of what the next steps are, meaning that you want to know that the customer really wants to go further on the project and it doesn't just want to see that it works and after that it's a stale project. So you really want to clear the expectation and know that if you succeed in the POC maybe you will have a clear deal after that with him. Try to get the customer budgets as well. It's very easy to say it's hard to do, but don't waste three weeks on development if you only have a very small budget, if the customer have a very small budget. On the other hand, if you know that it's a massive project for a few years, you might want to spend that two or three weeks building that POC. Don't go to the common pitfall of doing the full project. I have customers that ask me or ask us to do a POC but it was in reality the full projects. So don't do that. I know some of us might have done it, so try to avoid that because in the end it won't help you that much more than if you have just done small proof of concept just to show that you will have what you want to have. And why we do custom POC? It's because Drupal is awesome and I really believe that thanks to Drupal, the community and all the modules that we have we can spin up demo way faster than a lot of our competitor and we can demo stuff more powerful and a lot more different functionality than any other CMS. And if you want to have some specific functionality for that customer, it's really easy to develop. We all know that here. And I'm pretty sure that you will be able to spin up a demo way faster than any other competitor. And for that, Camon will talk us about an example. Yeah, so I just wanted to talk about a recent example that we had a very successful engagement with a longstanding customer who expanded their business with us in the UK. So they're a very large media company. We're aware we've had a big successful project with them earlier, but being a large company, those teams that were involved in the project that we had been successful with, we're not informing every other team in the company. So we knew there were other projects going on. The particular project that we had an interest in was around a video-on-demand platform, somewhere like a Netflix or a Hulu. They had a bit of a hallway conversation between teams and said, why don't you come and talk to Acquira about Drupal, because we think that Drupal could be a fit here. We knew that Adobe had a presence in the deal, but we agreed to meet and turned up myself and another technical person in the sales guy. He walked into a room that was plastered with whiteboards all around us, and all we could see was Adobe AEM, Omniture. All of these Adobe products, and a huge architecture diagram that someone had been whiteboarding out, and we thought, well, then this is a hostile environment. But we came in and to their credit, they were very good about explaining from that ground up what they were trying to achieve. They had a pressure to deliver this by a certain date because of certain political environment within the organization. They were a long way into the scoping of the project, assuming that Adobe would be the technology that they chose for the web client and front-end. And they said, okay, well, this is what we're doing. This is the user journeys we're trying to establish. This is the revenue that we're trying to see, and these are the technical things that we need to achieve what we need by given date. And so we went through that, and they said, why don't you come in next week when we're gonna present the whole stack from top to bottom, and you can go away and come back to us and tell us where the Drupal can do all this stuff. So we're looking at the stack, and it's like 50 components of this huge platform, really a very big platform. But when we began to realize that we had a real chance, I mean, we were working with them directly and talking to them about these technical issues, and talking about how we could solve them or how we could try something different. And we really began to build up a very trusted relationship. So myself, a colleague of mine, someone in a non-sales role, but technical role, all had a direct line with people at this organization talking about these issues, presenting alternatives. And they said to us specifically, we really like the way you work, because with Adobe, there's a huge organization, everyone's trying to get a license fee, we don't have the level of response, they don't have the level of responsiveness that you have, sure. So that was good, we felt positive about that. The other thing that you couldn't really argue with is that Adobe was gonna charge a million pounds a year or something like that for a license fee. We could say, look, you can take that money and you could put it into improving your product. That's all well and good, but we got to the point where we wanted to demonstrate that that was actually possible. So we ended up going to doing something that we don't like to do unless there's a really compelling reason, which was the POC. And this speaks to Drupal's ability to be very flexible, dynamic, and have a very quick time to market and to be able to integrate a lot of functionality very quickly. So we built a proof of concept with a very limited subset of features, but that demonstrated the things that they wanted to see around editorial experience, look and feel, how different stakeholders could influence different parts of the site and be separated from one another. So we spun that up in two weeks and they were really impressed that we could move so quickly, that Drupal was such a flexible platform, and meanwhile Adobe was still trying to work out how many licenses to sell them. So I think that this, you know, the demonstration here is that, you know, Drupal has got this big advantage over a lot of the proprietary competitors and that it is open and it is free and you can move very quickly, but the thing that really sealed it for us, although there was a huge cost advantage, is that we built up that relationship, that they felt that we were technically competent and could be trusted to advise and we had the references to back us up. So yeah, we were happy with that one. Commit me, Jim. Yeah, so Jim's our fearless leader and our team in presales, we had a problem a couple of years ago where we would be asked to build demos or build proof of concepts and what would happen is someone in our team or maybe we'd draft in other people from Acquire would build those Drupal sites from scratch every single time. And that was unsustainable. So just from a amount of resource we had to assign to that, it didn't work. But it also meant that we were not building with each time that we gave our demo or built our POC, there was no, we chucked out everything we learned every time. So a couple of years ago around the time that Fred and I started, we decided to sponsor a project in the open source community on Drupal.org called Demo Framework. So we have like two and a half people working full-time plus other people coming in who are building a framework to demo Drupal and some of the best features in Drupal 7 specifically for a sales context. So we show some of the really wild features that Raph was talking about, drag and drop with Pinnopoli in place editing with edit module. We use workbench moderation. We do is a responsive design and it's designed in such a way that you can have what we call different content scenarios. So sitting underneath Demo Framework we have something called Lightning which is the underlying code and information architecture. We then have an interface to plug content on top of that. So you can take the Demo Framework and put, if you specialize in a particular vertical you might put, for example, we have a partner who specializes in what they call membership organizations. So they make the site instead of looking like one thing look like another thing but the underlying technology is the same. So we're really trying to encourage people to use the Demo Framework. It comes with scripts and videos that allow you to tell the story and the narrative attached to the Demo and we would really like people to contribute. So, you know, as Acquire, we contribute a lot in terms of resources both technically and sales narratives but we'd love other people to join us. There's no obligation to push your IP back into the community of course but, you know, the more help, you know, a rising tide lifts all boats. So we have got that in the resources section, so when we put the slides up on the website after the session, you'll be a link to the Demo Framework slash project slash DF on Drupal org. It's worth looking at. So, how do we get the technical win? We build trust and credibility in the trusted advisor relationship. For me, in my role, I think that's almost the key thing that I need to do. The sales person will work on the, you know, making the commercial case and getting the operational stuff around the sale done but for us to be in a position where we're trusted technically to deliver, that's huge. You don't wanna get put into an adversarial position so you don't wanna be fighting against the customer or at least members of staff with the customer because you're gonna lose and even if you win sort of logically, you're gonna lose emotionally and that's not where you wanna be. If a customer puts up a whole list of things that technology can do and you attack those points, if you get one of those points wrong, your whole argument goes out the window. You're not an expert on other technologies, just stick to what you know. We know Drupal's fantastic, let's position it that way. And the biggest thing, as always, is just solve the problem, you know, whatever their problem is or whatever their opportunity is, be there for them so you can help them with that. I think that's it. So there's a link of resources that we're speaking about. Demo Framework. We've got a lot of case studies on equa.com, Drupal Security Report for Security Conscious Customers and Drupal Showcase, which is an open list of compelling Drupal sites that people wanna use as references. So, any questions? Yeah. Do you have any experience selling Drupal to folks in like the Stara community? Oh, I wish they had been homeless here. Um, do you wanna talk about that, Jim? No. I don't understand. Yeah, I know. I don't personally have a lot of experience. There are members of our team. For example, we have people on the West Coast who do a lot of that. I think we've had some major startups that, you know, we reference, that maybe aren't so small anymore, the Pinterest, you know. But I think the... Is Pinterest on Drupal? It does use Drupal with Drupal, too. In some places, yeah. I think they have an internal support community on Drupal. Yeah, we've done similar things at Twitter. I guess it's not a startup so much anymore. Can you think of any good examples? So, what sort of startups are you... Just like software and service oriented web applications. Sure. I don't, no, no. It might be more of a West Coast thing. I don't have any personal examples to draw on. Yeah, sorry. If you do have a... You do want to talk about that in more detail, come and find us and we can put you in touch with someone who has a lot of experience in that area. Yeah. Do you have any other questions? Okay, so, government and higher ed and those kind of verticals are quite different in the way they do things. They're very documentation heavy, very process driven. Usually, they're quite open to the idea of open source, but what we get bogged... Well, I find I get bogged down in the contract and the procurement process. The best thing you can do, and if you have these resources available, is to have sort of like, if you've done those deals a few times, the same questions will begin to come up again and again. So, we tend to have, for example, we have a big paper on security that we send out often and we say, look, we can't divulge everything about security, but here's what we can say if you have any questions, come back to us. Because if you get into a sort of, what about this, what about that, what about that, you'll be there all day. So you want to flush out the things that they think are going to stop the deal happening early, rather than wasting your time, well, spending your time on things that they just sort of are interested in. Yeah, part of the Australian deal is also building that trusted relationship. We've been working very hard with them, so being honest and helping them, basically, that was a really big part of the win. Andrew Klopp, of course. It's not a loss. A live demo. We didn't put that on the slide, that's very dangerous, that's very dangerous to do a live demo, but we have it on the laptop. I might have it. Yeah, yeah. Let's do a non-best practice doing a live demo. So this is actually a... I need to give my master plan a bit. On my private... Any other questions while Cam sets up his laptop? He's asking what he needs to say. Everything, he wants to say something. Let's show him the whole piece, and that's enough. The other thing I think we have on the booth, don't we? People running. So if you want to dig into any of these things in more detail, let's kill that, and I'll kill that, and I'll kill that. No. You can go to the booth, the Acquire booth, and we'll have people running demos against these things. No, so we've got the demo effect and full effect. You have to make a joke now. Yeah, I have to make a joke. So this is a demo framework. It incorporates a lot of things around responsive design and scenario. So the particular scenario we show is a travel site, and one of the interesting things about having a travel site is that we can do what we call content community and commerce. So we have content, you know, standard Drupal nodes with fields, images, and those sorts of things attached, but we also have the ability to check out an item through Drupal Commerce, and we have comments and social media integration that does the community aspect. And so that can be quite compelling to a lot of prospects who are used to buying, I'm going to buy my social system, I'm going to buy my content system, I'm going to buy my e-commerce package, and this is trying to package that all together. Just do a time check. We also do responsive design from the ground up, so you can use this theme and you can edit it, even the admin menu is responsive. And what else can we show? We have, you know, so if I was to create a... Yeah. So this is the wrong way to demo everyone. No dead nodes. But I think they're probably the best, like you can find any of us to demo in more detail or, yeah, come to the Acquire booth and we can show the demo. There's a lot of resources around this. I think the key thing for agencies and development houses is this concept of having demo scenarios so you can import your own content as and when. So this is the demo. So, yeah, this goes into the detail and you can find the videos that will take you through how to run the script and the actual documents that you can use to base your script on. So we're going to help you with this and we're very happy for you to help us with this. Maybe you're interested in it. No more questions? Thank you very much. And rate the session, please, on the website. Thanks. Yeah. Thank you very much.