 All right, it's time to get started. Good morning everybody. My name is Jonas. We'll have the simplest session of the day. But the downside of that thing is that it's the hardest one to implement in real life. Let's start off with a couple of questions of you. First of all, the most important one since it is the morning of the last day of the Drupal Khan. How many of you went out last night? All right, so we'll try to keep things interesting and to keep you awake. All right, other demographic questions about you. How many of you consider yourselves developers? All right, at least I have. Are there anybody here who consider them or have as a part of their job being system administrators? All right, some. Are there people here that consider them some sort of management or team leads or something else? Great, seems like we have a very good audience for the session. Okay, let's get on with the actual stuff. First of all, a short introduction about who we are. We are Jonas and Eli from Wunderkraut. Wunderkraut is the largest Drupal consultancy in Europe. We operate in nine countries. The most recent one isn't colored yet because we just signed the contracts with Estonia this Monday. We only do Drupal as a technical platform. We only do agile projects when it comes to software projects. But of course, what we do in the maintenance and support stuff, it's also agile, but not agile as in scrum agile, but different kind of and smaller kind of agile. And we're also a very agile company. I've been on Drupal.org for six and a half years, I think. Why are you looking at me? I don't know. Just thinking. Well, since 2007 anyway, so that's five and a half. I don't know. Six and a half. I'm the managing director of Wunderkraut Finland. We're 35 people in Helsinki and Turku. And I'm a part of a lot of our projects. I do steering for them and try to get myself away from the kind of not disturb the actual valuable people too much. Okay, and as Jonas introduced me, I'm Eli. I work currently as a service manager. And in my job description, actually, is all three that mentioned here development as this admin and most of the times nowadays more of the management side. In the previous life, I work at the University of Helsinki, started at the low level of help desk. So I know what it's to do in the client, getting all the nice stuff from the clients. And before I started working with Drupal around three years ago, I worked and I still currently work with WordPress also. So it's still an open source site. That's the thing about us. All right, we have kind of a humorous topic in a session saying that we want to create vendor lock-ins. And of course, as you know, in the actual open source world, that doesn't happen. In the traditional world, vendor lock-ins is when evil proprietary systems are not necessarily evil, but proprietary anyway. Customers get stuck with certain companies, certain vendors, certain service providers because the service provider owns the software or they're the only one to support that. So sometimes that's a bad thing since the vendor may produce really bad quality, really bad customer satisfaction. And the customers are paying too much and they're not able to be happy with the service that they get, but they're stuck. They can't switch away at least anytime soon. The stuff that we are aiming at being open source vendor lock-in is trying to get into a position where our customers are so happy with us or they trust us so much, or they kind of feel emotionally or mentally addicted to us so they can imagine switching away, but of course they technically always can. Websites evolve for years. So from the user's point of view, even if you did a big project, then finally got your service to the public and your project ends. The website is zero days old at that point. It means that as the website evolves and runs for years, the whole customer satisfaction or the whole experience about whether the service is able to serve the needs of the users and the owners is made during that longer period of time. Not the first couple of months, but the upcoming years. Those of you who admitted to being developers and not so much the other two kinds of people that I asked might think that they don't want to do hosting and support and maintenance stuff because they want to create new things. That's fine. We have a lot of those people as well. We probably have even some of those guys from Wundercraft in the room. That's fine. Not everybody has to, but of course that's even more reason for creating a system where you have a team of people that are dedicated for that, that are motivated for that, that are really good at that. From the company point of view, maintenance is really important because it's really good for your business. It's steady cash flow whereas projects start and end and then you're kind of unemployed again. They're a great thing to create upsell opportunities because you're in contact with customers all the time. You know what's happening at the customer organizations. And one very important thing is that it's kind of the only tool, only powerful tool to control your brand value as a triple company or even as an internal team of developers. Because as I said in the previous slide, when you do a project, when you finish a project and the service launches, it's zero days old. And if you would do a great project that would bring a lot of value to the customer, but then it would be maintained by somebody else hosted somewhere on a crappy server, it wouldn't be a good kind of showcase for you. So it's best that you're the best one or the go-to company for hosting and maintaining the sites as well. Other aspects to having a great support team is that it's great for internal support. It's great for the people in your company or in your internal teams that don't do the life cycle parts or the support part in your project. Since they are the kinds of people who get what you did wrong in the project or what somebody else failed in the project when they forgot to put caching on views or whatever. So they can help the developers not repeat the same problems that previous teams or previous projects have done. So in that sense they're a quality assurance factor in the company. And of course our support guys are present even before we start actual implementation projects because they are already in the RFPs. We're selling them as a part of our offering. So having good support, having good continuous development is a competitive edge for us. And of course we want to keep it that way. All right. It's stupid to try to invent all wheels yourself. So we're proudly saying that we've stolen some of the ideas that we have in our maintenance from other industries. This is a quote that I stole from Zappos.com. Zappos is a really well-known online shoe store basically. And what they say in their about.zappos.com is that we've been asked by a lot of people how we've grown so quickly. And the answer is actually really simple. We've aligned the entire organization around one mission to provide the best customer service possible internally. We call this our wow philosophy. And this is something that we've tried to adapt to Drupal services as well. And now I'll turn the mic over to Ilari to show how it's actually done. So basically what we have at the moment in Wunderkraut, we have this theme called Hymö, which means actually to smile. And this is the thing, the tool that we use to handle the hosting and the continuous development, all these tasks in our company. The beginning of all this was so that in the beginning it was just me doing all the stuff. There was no Hymö team. And of course you all know when business to start, one person can do certain amount of stuff. But when you get new clients and the clients, the projects end, you get more and more stuff. And at that point one person isn't enough anymore. We came to that point at some point around I say a year ago or a bit over a year ago. And that was the crossroad where we also decided that we want to do this as a competitive advantage for us. So at that point we decided when we added one more person to the team, we also decided that we are going to roll out a whole new philosophy for doing things. So at the moment, as I said, we have a five-man engineering team. So it has grown up from the one-man and the only purpose that we have, even though we all are technical persons, we have sysandlings that like to be terminal and do tinkering and stuff. And we have performance addicts who likes to see if it's one millisecond faster or slower and so on. But the most powerful tool that we want to do is to make customers smile with great communications. If you don't have great communications, it's something that even though you would do excellent technical things, if you don't communicate it right, the level of happiness of customers, it can't get up enough so that you get a competitive advantage of your hosting and maintenance and continuous development. As I said, the great communications, the communications is something that's really, really, really hard. I would say that Jonas is very good communicator, but he has every day, every day he has to learn new things. He isn't perfect either, even though he thinks so. But it's a true thing, even though you are really, really good, you need to understand that you need to constantly learn in communications. You meet new people, you meet new organizations. None of them are the same. They have maybe same stuff in there, like in the organization. They may have same kind of management, but then again they have whole different kind of things underneath that. Another great and really important thing, as Jonas already mentioned, is that we are in the whole process starting from when we meet the clients and so on. We start also introducing that we have this very, very great continuous development hosting maintenance team. And the actual idea is that our team, one of the members or several of the members, are in somewhat involved in the project from the whole beginning. Because if we wouldn't do that, it would be like day before launch. Where are we going to host it? Where is it? Where is the server? What are we going to do? And that would be the case with the development team. Instead, we are there, we see okay, now they are in this phase or something, and we help them like okay, now we have to think about this, we have to communicate to the customer and these are the things that we need to do. And at the same time when we are there, we are also doing internal QA. So you might say that we have seen all the bugs that you have done before. And we don't want you to do them again because we have to fix them. So we will say that they don't do this again, this is bad because of this. And happily our developers are smart enough not to do those bugs again. So that's a real compliment for them. Thank you. And the thing is also our philosophy is to fail fast and fail cheaply. So that's also part of the philosophy that we bring the information back. Also like as I said, we provide the value to every stage of the project and customer partnership. We provide it also to the customer. We say that hey maybe we could do this way or something so we can actually affect things already in the project phase that affect normally start like week before we are going to production. We can already start affection in the beginning of the project phase. And that's really, really important also. So basically if you are in a phase that you are in the same crossroads thinking about that okay now I need more people here. It's just me or it's just me and my buddy Joe or something. We need to think about this is something that you need to think about. The team has to be involved from the beginning. Okay and this is actually something that the whole human team started off from this example. Yeah, before actually going into the example I'd like to point out one more thing that Ilaris team is very, very valuable to us and the customers alike. They're protecting all the development teams from interruptions. So whenever there's an issue or there's a bug or there's a change request or whatever that comes from other clients or other services that are already online in production and there's a ticket that comes in and something needs to get done. Ilaris team will be the buffer to handle that and nine times out of ten they can handle it without ever going to the original development team so that they can focus on whatever they're doing at the moment without being interrupted and without having those really costly context switches in their work. But going to the server class example, as Ilaris said this is actually the kind of exercise or talk that we had the very day when we decided to form this human team. And we actually constantly still have it like when we fail in something we remind us by this example what's the actual point of the whole team. Yeah, the idea is that there are two websites, two identical websites on different parts of the internet but they are managed a bit differently. What happens is that both of these sites crash because let's say PHP, FPM, Jams and Monit can't bring it up healthier again. Whatever, the site just crashes, it becomes unresponsive. Both of these cases there are monitoring in place so both of the teams managing the sites get for example SMS alerts saying that example.com is now down. The first team stops doing whatever they were doing starts fixing the problem, sees that all right, I'm going to log into the server or first verify that it's not working, logging into the server, doing whatever needs to be done. I think the customer calls and hey, our site is down, it's been down for at least 15 minutes. We say that yeah, yeah, okay, we know that we're already actually fixing it. So be calm. The customer hangs up the phone and we fix the issue and the downtime is in total it's 30 minutes. All right, here's the second team from other side of the internet. The site goes down, the development or the maintenance team goes to verify that it is actually down. All right, there's a 503 on the page. They SMS the customer saying that hey, Markku, there's a problem with your site, it's down, we're fixing it. Then they start fixing it. It takes 30 minutes, they fix it and then they call the customer saying that yeah, there was a problem with the server but it's now back up and we actually change the configuration of the surveillance software so that it can now be brought back to life without any human interaction. At the end of the day, both sites were down for half an hour. So technically they were very similar cases. But the first case made the customer first notice a problem themselves. They had to call us to make sure that we're actually doing something and we didn't report. In the second case, the customer didn't know that their site was down but they knew or they noticed that we have surveillance systems in place. And after the 30 minute downtime, they felt even more comfortable with us than they did the previous morning because they knew that we fixed the problem, we fixed it really fast, we told them in human terms what the problem was and we made the server environment better. So even though the site was down for 30 minutes, the customer satisfaction in us is actually probably higher than it would have been without the crash. So communication is the key. And for the next exercise you might want to dig up your pencils and pads because there's the important thing. Okay, so this is really important to be ready. This is one of the key elements. So as we talked about, as Jona said, recovering failure, you might write this down. It's really, really hard. Actually it's really hard to implement, but very hard to think that, okay, I will do this. So the idea is basically, as Jona said, before you do anything. Of course you can go and log into the site, it's actually down. Then communicate to the customer. Then you can act and start doing this. And actually if it's going to take long, just repeat the number two and three. Act, communicate, act, communicate, act, communicate. Because this is something, if you don't, if you communicate in the beginning, then you act and then you are silent for three hours. The client is again, are they doing anything? Are they on a coffee break? Are they on the lunch? Did they go home already? You need to communicate constantly on that one. And of course, as we have the fourth point, victory. I think that every time there is a failure on a customer's site application or whatever, that's a possibility to get your customer more happy. Your reputation up actually. You don't have to fear those. Of course you have to, when you're fixing it, you have to fix it so that it doesn't repeat. Because that's another thing, that's repeating failures and that we don't want to do. But single failure isn't bad in a sense that it's an opportunity to make everything better. And of course, a very important part of this is also that you, every failure you do, depending on the size of the failure, you do retrospective after that. What happened? Why happened? What are we going to do to prevent this happening again? That's also really, really important. It doesn't have to be more than five minutes if it's a really small thing. Don't spend too much time. Don't blame people. Try to find solutions. Try to go forward. Another, as I said, the communications is a very, very big part in our organization and in the client communications. It's not the technical tools. This is more in the continuous development side, not that much in the hosting and maintenance. But you know customers, they have these, they think that they want. And we all know that those things, most of the time they sound in the beginning, they sound ridiculous because we shouldn't do it this way and so on. That's why you should and always ask why, to actually understand what the customer needs, not what the customer wants. It may be irritating for the customer in the beginning if it's a new customer and you start asking like why, why, why, why, why. And they have used to the things that they send a request to the technical company and they implement it, know how stupid the idea would have been. And they might say okay, we got something or okay, this wasn't useful at all. But when you start asking why, why aren't they just doing like the other companies. But also the idea behind asking the why is to educate the customer to think more thoroughly and then your job in the future will be more easy also. When you ask why, you can repeat the why. To understand the actual, the business value, the business reason behind the request. And this is also, as to the topic for the window locking, this is very, very addictive thing. When you start doing this and the customer notices at some point, hey, these guys actually they care about our business, not about just their paychecks and the things that they can build from us. It's a whole nother like atmosphere in the communication. And there you can start building the window locking, open source window locking. And it requires certain kind of mindset. You have to be patient. It doesn't happen in one week or even in one month. But it's when you started, you started from the project phase or if you get it just for hosting, you started immediately doing before you even sign anything, you start doing this. So it's more easy for you, more easy for the customer to adapt this new thing because I think it's a very new thing. Not many companies do this. And as I said, as many companies don't do this, you can position your on top of those companies. Be the next level company. Be the one that understands the client's business needs. Because you are the one who understands, is the expert in the technical part. But the client is expert in their business. But you need to understand their business to provide the right technical solutions. As I already said about this fail fast, fail often. It's our methodology, not just in our continuous development team. It's our methodology in management, it's our whole organization. Whatever we do, we don't fear failure. And you might think that, hey, why to fail? Why just not, you know, always succeed in everything you do? Well, first of all, that's impossible, we are humans. And second of all, I think that if you don't fail, ever fail, you are not trying hard enough. And if you are not trying hard enough, you are not going forward. And if you are not going forward, somebody is at the same time passing you as a company or as an individual. And that's not a good thing. One thing, as I said about the retrospective, is about also about failing. So we try to fail transparently inside the company, but also outside the company. So if we fail in something, we are very open to communicating to the customer in a way that we don't put ourselves low in the level. But we try to be open and say that, okay, we are humans too. We made a mistake, but we have fixed it. And we have also made the things that it won't happen again. That's just positive influence if you are open about that. Then also, that's a part of the building, the relationship, building the trust between your client. You are open to them, and at some point they will start being open at you too. And the fact is that at least in our environment, and I think in every environment, like if you don't, like every time somebody fails, you don't like pinpoint. It was that guy who failed, or that one failed, and it was his fault. But you say that, okay, you are allowed to fail. But remember just fail once in that subject, learn it, fail fast, fail cheaply. And that encourages productivity in your company. You may start making new things, new innovations. People actually are with their whole heart in the business doing that because they know that they are cared for. They are not playing for every mistake that they do. They proceed further with their experiments. So you get all the cool new things and get the business advantage compared to other companies. And as I said about openness, we have actually a tool for this. We call it fail of the month. And it's basically for this, the biggest failures that we have. We kind of like cherries and in kind of way celebrate these, but also try to make other people learn out of them. All right, great. Everybody still seems to be pretty much happy. I don't see anybody snoozing. Let's go through the tool of fail of the month through an example. This is a customer of ours. It's called Usuomi. It's an online only newspaper in Finland. It's one of the biggest online newspapers that Finland has. And it's the only professionally run online only newspaper that the country has. And they had an issue, or like most newspapers, or all the big ones had an issue between Christmas and New Years last year. There was some group of people that did a series of distributed denial of service attacks. And a customer of us, Usuomi, was one of those. They got hacked on the, or not hacked, but did us on the 28th of December. And there was an issue on our part with that. And that's of course not the fact that the site went down, but the communication that followed. This is an actual document on how we managed that failure last December. So, with all the typos and all the names and all the company names and everything in there, it's an actual document. So, the background. I said on 28th December after midday, Usuomi's site was did us. Like many other media sites during the couple of days around that. Site was done for 30 minutes for regular users. The issue was solved when the internet service provider who hosts the servers started restricting foreign traffic to the sites. Some minor issues existed still one hour after this. But basically the site was done for 30 minutes. We couldn't access them, nobody could access them because of that. All right, then in detail what happened. We got an alert like two minutes before one in the afternoon that automatic monitoring notified our support about an issue. Five minutes after that, we confirmed that the server was unaccessible and started to find out what the problem caused us. Four minutes after that, we called the service provider, the hosting service provider and told them that we can't even access the servers. We can access via SSH to find out what the problem is. And whether could we access the management consoles of the servers. So we kind of thought that this is probably a network issue. So we called them and asked them to have a look at what happened. 13 minutes after that, the internet service provider gave us information on that there's a lot of traffic coming to the sites and they're seeing what they can do about it. 14 minutes after that, the service provider had restricted foreign traffic which made the site accessible within Finland. And then probably we can see the next part of animation. So what went wrong? The customer contacted us 11 minutes after we were contacted by the SMS from the monitoring service. The customer told us that there was something wrong with the service. We replied, I think they filed a ticket in our ticket system, right? Something like that. So we responded six minutes after that, that we were working on it. The problem that was wrong with this was the whole server crash example thing that we started the whole team with and then we failed in that thing. I think we've learned now. That hasn't happened since. So communication was the problem. Customer contacted us instead of us contacting them. We've already been working on the stuff for 10 minutes. We could have told them that yes, there is a problem. Yes, we're working on it, but of course in the heat of the moment it's really easy to forget that there are other people in the internet or in the universe as well. As said, there is a four-step guideline. Remember the act to communicate victory. The first step stating that we should communicate the situation to customers right after we confirmed the issue and we failed to follow that. We managed the failure after initial delay in communication. We informed customers regularly about progress. Lessons learned, even if it sometimes is to forget. Here in the customer service business, not solving technical issues and making sure this never happens again. Mistakes do happen, but it's important to acknowledge the failure and acknowledge the failure and learn from that. For our team, writing this is one of the steps on learning about this. We also share this so that others can learn from this. For more information, contact Henry and Janne who sit there actually. We sent this out to all at Wunderground.com and to the customer. That's what we usually do. Inform all the people that need to be informed including the customer. Usually what happens when we send this out to customers? What happens when we send these reports? The customers at this time, even though for example this time the customer actually was really happy that we did and they were like, we were really happy even though we did a mistake in there but we fixed it at the time. After that, the customer actually said, hey, this is really good idea. We are taking this into our internal use. It's the same thing that happens with most best practices that you transparently show to customers. We've had reports on them saying that this daily meeting is a really good thing. We have an internal daily meeting in our communications department now or that sort of thing. So be very transparent on the good things that you do or how you do them well and people will steal them proudly. Okay, this concludes the content of our session and I'm hoping that this is at least one thing that everybody has to take away from this session. If you still drink, think, if you still drink. How many of you drinks now? If you still drink, people support and maintenance is a technical job. You weren't listening, you're not doing it, you're approaching it the wrong way. All right, do you have any questions or comments? You can ask now, great, I'll bring the microphone. You can ask now, ask on Twitter or come to a buff session we're hosting in a room right after this session ends. Yes, and I also asked Scott Massey who had a similar kind of session yesterday and he at least yesterday said that he would be coming also there so we can have good conversations there. So please do arrive. But for questions. What's the process that you use to communicate the support lessons back into the rest of the team? Like you mean like internally? Well, it depends of course like in how, what kind of problem or thing it is. Sometimes we just go and walk if the team is there and walk and talk it with them. And if the thing is important that we see that it's something that everybody should know after we have discussed with the team in Skype or face to face then we communicate it with email or in Skype or however to the whole wonder crowd so that we can, if we fail in Finland then we hope that if we say to Belgium, the Belgium guys won't fail. After that we have informed them that hey, don't do this, this is stupid. So it's just case by case. Yeah, but basically we try to do it every time so that we inform the whole wonder crowd about it. Or if it's a dev problem we don't might want to say to the management but we try to bring the message to all developers that don't do this, this is bad. All right, adding to that one of the processes that we have in place for spreading the knowledge is that we usually dedicate or nominate a person within the continuous development team to project teams. And a person that's responsible kind of follows up on what they do, make sure that when they start their project they use the right tools or the most up to date tools because the tools change every three months and make sure that all of their technical infrastructure is done right and follows up on the performance issues or whatever best practices issues there are to make sure that project teams learn from other project teams even while the projects, both projects or various projects are going on at the same time so we can kind of shorten the learning cycle. My question was going to be virtually similar. I run teams and what I found is that didn't work for me. I was just wondering whether my approach you'd ever considered it or not. So what I do is I actually tend to split my dev teams up and have a rotating rotor for the support team. So the support team is the dev team. They're the people who develop the latest release because what I found in the past is that, yeah, you can embed what is essentially an ops person into the development team but they really have to be working on the code base to even do a release or to support any issues that come up and then you still have that kind of slightly siloed approach. So what I do is I have a dev team of ten people that might split them up into three and seven or two and eight or something like that and after every release three people from the dev team kind of spin off and they're the support team for the next two weeks, four weeks or something like that and then if they want to keep doing it, it's fine. If not, they can merge back in because the other thing that tended to happen was that people sometimes got a bit demoralised about being stuck on support and it's a bit less interesting than being in development. Have you thought about that, any problems with that or comments from Wunderkraust? Well, I'll let Ilari speak in a minute but one of the reasons why it's Ilari, don't be like that. One of the reasons why we have this team, of course, one of the things is the customer facing things but the other is that we want to do this as good as possible internally as well and we have people that are really good Drupal hackers or Drupal people and they're saying the kind of thinking that if they would need to be nominated to that team for more than two days, they will probably start finding a new job and sometimes we've had issues trying to convince people who we want to be a part of the team that no, you don't have to be in the team forever and no, it's not a second grade thing. I think that's the best team we have. They are responsible for most of our customer satisfaction even more than the people that build the applications but as far as your question goes, still remember it? Some part of it. Basically, I understand what you are after that but I and we see it so that we have to have the core team that has the part of the knowledge like in everything so we don't have to, every time you get a new team inside, they have to learn it. It's the same thing like in projects when you bring a new team member inside you know that it doesn't accelerate it with 100% or something like that. It's the same thing, continuous development. But as Iona said, we do it so that we have, like now we have five people, but we still have more work than for five people. And of course, we cannot do so that people move from projects to projects to projects to projects. There are like week, maybe a month, but they are not doing anything billable. So then we use those people from projects, maybe to the old projects that they have done, because they know it already. So we circulated in that way that we get people still from the project but we have the core team that knows the current situation and the new guy who comes for two weeks or something, he knows the technical side and it's really, really fast to brief like what's the current situation, what we are doing and so on. So that's, I think, the way it could be working also for you. It doesn't have to be big in the beginning, the continuous development team, but the knowledge has to be somewhere all the time. Nice talk. I have business questions that might link with your company as well as the market of Drupal and Drupal maturity. I'm new to Drupal, I'm managing a research lab, private lab, but it's on telecom, I'm working on telecom and this telecom market has been maturing in a way that basically you cannot tell a telecom shop like you could find a Drupal shop on the market. You have, I would say, players which are segmented on different, I would say, activities for different group of users and that's the only way to survive in this, I would say, competitive market. So my question would be about the why that you mentioned. Key things for you is to understand the business of the customer. If you go deeper into this kind of question then you might have competitors on the market who come with people that would upfront understand the business of the customer and they will not only ask why, but they will also, yes, I do understand why you're doing that. Can you give me some little more details on how you are implementing this, meaning that you might be, in a way, on the market big enough or Drupal mature enough to be able to segment your offer into specialized areas like banks, retail, anyway. So do you think there's maturity on the market big enough to do that right now or it will be a longer time? No, it sounds like a question that I should answer. Whether there are really good business consultants at Drupal, well, no, we aim to be as good as we can be, but Drupal companies in general are pretty small and they're pretty generic. They build a lot of different kinds of sites. It's really nice thing to see that there are companies that are focusing on commerce and companies that are focusing on different things and there are a lot of companies in America that are focusing on not-for-profits. But yeah, if we would have a case, which would be a big case for, let's say, a French bank, we probably would seek out help from a kind of traditional business consultant and team up with them, partner up with them, try to understand the business of the customer together and try to develop that or do new ideas for that together and then just seamlessly handle that as one team. Does that answer your question? It means that the market is not still much enough in front of the US, which is maybe more advanced. Yeah, if the biggest professional services company in Europe is less than 150 people, then no, we can't be able to manage all of the different customer verticals in all of these different markets. One question, we still have time. A follow-up question for earlier regarding the support team and customer communication. So if the support team is already involved when the project is built, how do you handle a single point of contact for the customer if they have contact, for example the project manager, but also with a future support team? How do you do that? Do you want to take this on me? You can, because it's more like, again, your area. All right. How do we manage the issue of having a single point of contact? Well, from the engineer's point of view, there is no, because the single point of contact is usually the guy or one of the around two guys who first met the customer and discussed about the RFP. And the single point of contact usually is that person. But when you enter a partnership with a client and they have operational daily needs, for example fix the trigger feed thing or something like that, they don't want to contact the business analyst or that kind of a management person to say that I want this technical thing done. That's why we have a service manager. So they know that there's no single point of contact, there's actually two. So one is on a tactical level and one is on a strategic level kind of. Does that answer your question? And also additionally to that, when we do it so that we have two points of contacts, we also see very fast like, oh this question should go to the business analyst and for example if it comes to me, okay I will pass it to this guy and he will contact you as soon as possible and so we are trying to communicate and not do something that we, for example the business analyst is not the technical person and he admits that so he forwards it back to us. So that's the way how we rotate that one. I have one question. I like the kind of transparent nature of this. However, does it ever set on reasonable expectations about how you'll do all the work in the future about change requests being done immediately? Because it's great having this kind of really good relationship with your clients but would I be offending people? Not all clients are very reasonable sometimes. So is there a point where this kind of process maybe sets unrealistic expectations or causes problems in any way? Well of course like if you communicate, when you communicate to the customer you have to always starting from the project to have the expectations management every time you communicate you have to think about that. So in all phases if you, I would say it falls back to in all phases the expectation management. So you need to have when you communicate it when you are transparent, when you do everything you need to be like alert on how this would affect and you will probably most probably to see it like when you get the knowledge and this kind of thing you gradually get better and better and then you get from the smallest pieces that okay now this could go to the wrong side and we need to start communicating it differently. Did I answer at all to your question? Yeah. So it's about all the times it's about expectation management you have to see so like the thing that if you get like a layout of the company that promises something that's then you are like it's really hard to start the expectation management but when it's always inside your company it's easier and if you do it all the time it gets easier and easier and easier because the customer also gets like educated all the time like how is this done? Hi I'm Gretchen and thank you for the great presentation first of all I work for Drupal Squad and we handle a lot of maintenance contracts not all of them do we have the luxury of being the project developers on so as we transfer knowledge from other organizations as the supporting team for our clients it is often turbulent how do you have any advice or best practices to maintain client satisfaction during that sometimes challenging time? So you mean when some other company has done the implementation and it comes to you? Yeah so we need to be ready immediately to support their platform and their product meanwhile challenged with good knowledge transfer sometimes causes the client to not always be patient or happy do you have any advice? How we do it that like of course at some point you start having you have these trusted companies that you know that they do good colleague but then you have these unknown companies like small Drupal subs that you don't know before they might be really good or not that good so one thing that we do if we get a project we do a Drupal audit for the site so we can guarantee that it is and it's something that after Drupal audit we give the results to the customer and say that to be able to provide our great support and the top notch level stuff that we deliver these things needs to be done and one point can be like hey there's no documentation, high risk we don't know what has been done or like one of our developers is like very very very interested like if there are no comments in the code that could be really bad thing also so I would advise to do an audit for the site and if you cannot do the audit it's really risky business because then you are risking the stuff that you will just get the black box of something and then it will be dumped in your stuff and who knows what happens after that Yeah, in short you have to do an audit before taking an application that somebody else made under your wings and protection because you're giving them an SLA you're giving them a monthly fee in which you promise to take care of the site and you have to know the site first so if possible do a Drupal audit with the company, the other company that's handing that over to you willingly or unwillingly but anyway do an audit in cooperation with them don't blame people just trying to find the weak points and tell the customer how to fix them or how much money they need or how much time they need to fix that then start the support contract Hi, thank you for the presentation Do you use some kind of ticketing system or support system if you do, what is it? This again comes to the philosophy or a company in the sense that we try to do things as simple as possible so at the moment we use just simply open atrium with a couple of little tune-ups there so basically clients it's like we say it's the bottomless barrel of their dreams and whatever so clients can't enter there anything that they want like help desk request, continuous development requests and for the help desk request of course we answer like during the contract and so on and for the continuous development request we have created this one nice little tool which is simply just prioritized list so there can be in the continuous development site client can enter like 100s of things that they want to develop but they have to keep it in prioritized order so there will be only one top one priority then number two priority and so on and it makes easy for the customer they will organize the list based on their business needs for the developer in the room drag a pool of use so I'm one of the difficult customers I'm managing a multi site platform and as the project manager I'm actually trying to step back and write myself out of the project a little bit and I'm trying to figure out how to be how we can continue to be a good customer a little less stressful on you and burn through our support hours a little more slowly and we're trying to assemble sort of a group of admins for the various sites that are on the platform and build some sort of knowledge base we're still working on the workflows and the procedures and what I'd like to know is how we should best interface with our vendors and our development vendors in such a way that we can be good customers as effectively and efficiently as possible so we're not burning through tons of hours with redundant requests from multiple sites do you have any thoughts on that? whether we have a silver bullet or not but I don't know just speaking in general terms when you have a cooperation with this you need to have a shared goal or vendors that you have with the site or sites so be transparent, be human, be personal and try to talk from as a person to person try to find simple ways to go around problems that seem difficult but a silver bullet no so what I would say as I'm on the other side of the fence we would say start showing about the open communication start building the trust from your side what you can do is to have some kind of if you have several sites and you have we say we could have product owners for each site a different person is the product owner of the site try to do it so that they would collaborate inside your organization so that you would have also shared goals as you said there would be multiple same requests at the same time so that helps at least or have one person they might be in your company they might be one of the service providers have some person who has a responsibility of minimizing the redundancy so watching these different development cues doing something like that having that as a part of their job so my team until very recently just like a month ago we're looking up after a bunch of publishing sites and there's a bunch of conferences the one thing that I mentioned that hasn't been said before is if you're planning that's really good what we want to build is a tool for your guys to do their jobs we don't want you to come to us all the time to make every little change but you need to start talking to your to your dev team to your vendor right now about this to make it because especially with Drupal which stores kind of configuration there's no hard distinction between content and development or not as hard as the other systems so you need to start talking to them now because what your content editors do can really step all over the dev team and then you're going to have constant battles between the two and all but the latest release blew away our thing but we didn't know that you did a thing so that's kind of it Okay, we have time for one quick question Were there any more left? And we have a ton of time in the BOV session if somebody wants to come Going back to the failure reports a little bit Do you have a system or a method to make those to consult those things especially on such a large scale as with you? Do you mean like internally? Internally, yes, so I mean the consultability of those reports or is it just like less of them and you can just consult them ahead? Well basically what we do as I said we send the failure like the whole text to the whole company and after that if we see so that we still need to explain it in for example in more developer friendly way that the developers actually need to do it then we will do it the methods are free, we do it maybe Skype, email, whatever but it's per case if the fail of the month isn't enough of course we try to do it or we do it so that we will explain it to devs so that they understand it also from their side Yeah, so basically there's no big system or policy in place we have kind of a document template that states the titles in the things like you're not just describing the problem but how to learn from that and then kind of have the culture of people stepping up and bringing up their failures Exactly, bringing together like a question Yes, bringing up the question and bringing up the kind of the solutions for putting it but hey, thank you please to en rate the session on the Ripple Concite so that the Ripple Association knows how to have good sessions and we know how to have good sessions Yeah, for those of you who want to continue we have a buff somewhere, follow us Yes, thank you