 Hey everybody, how's it going? I'm Scott and I'm here to talk about support. It's great to be here in Prague. I haven't been to Europe in a long time, so it's nice to be back. I am sort of irritated because I spent about three months memorizing this session in Czech and I've been here for two days now and everyone's speaking English, so I think maybe next time we should make that a little bit more clear. Unless you want to hear the Czech version, it's about four hours long. OK. Dobre den. OK. Wait, that's not right. Sorry. OK. Cool, so let me just start off with the obligatory. My name is Scott Massey. I work for Pantheon. I'm the Director of Customer Success and that is basically support. It's onboarding. It's any of the stuff that we do to help people be successful on our platform, so that's training sometimes, that's doing a lot of screencasts and telling people how to develop on our platform and be successful. Before that, I worked at Promet, which was a Drupal shop in Chicago. I built their support team and before that I worked in IT managed services, which is basically supporting Cisco, Citrix, Microsoft stuff for a shop in for a IT company in Chicago. My, yeah, so there's my Twitter stuff and I wanted to share something that I've never told another human being. These are three things that I've left in my search browser when I was doing training sessions for people on Pantheon. So hopefully when you guys come up and ask questions you can share something that you've never told another human being. I don't remember why I was looking up Chinese dog doesn't want a bath but I think it was probably a YouTube video for my wife. So here's what we're going to talk about. We'll talk about why people think support is a drag. We'll talk about building sustainable support products. I have some case studies that I kind of want to run through to sort of give you some real world examples of how to structure support that I think is good, the tools, how to hire people for support and just a little bit of sort of philosophy and hand-waving. I've done this before for people at different Drupal cons and that kind of thing and so just before we start, how many of you work for a dev shop or something that offers Drupal support? How many are looking to maybe add support? How many are end users who are looking for support? There's three guys right in the front here. So that's about the usual demograph. So this is sort of geared towards people who have it, who struggle and I've definitely experienced a lot of the things and maybe we can sort of share our experiences and get a little bit better at it. So why offer support? I think there's a lot of reasons that people sort of fall into that role maybe because they built the site for someone or they've taken over a site for another dev shop or something like that. But the real reason that we do it is why we offer support, I think, has a lot to do with credibility and especially if it sites that we've built, it has a lot to do with putting our money where our mouth is in terms of the technical debt we incur when we build the site and being able to offer the end user the promise of long-term support. So it's definitely more of a marriage than a fling and I think you sort of have to think of it like that. I also think that the benefit of doing it is, well there's several benefits, but the one thing about the fact that it's like a fixed income, instead of just doing projects, in addition to that, it moves you up the ladder of trust so to speak and from a vendor to an advisor towards actually kind of a stakeholder in the client's process and decision-making process. Before I started working for Pantheon, not all of our clients were like this but there were a couple of clients that we would meet with them manually and help them figure out their budget for the next year for their IT expenditures and to me that's a good place to be because it indicates the trust that they have in you and it also kind of indicates that you're the de facto person they're going to go to when they make choice or the de facto shop they're going to go to when they make choices about who they're going to get to build their site or who they're going to go to. So I think it's important to not just offer it because if you offer support poorly or begrudgingly I think it causes pain on all levels and it doesn't really secure you or move you up that sort of ladder of trust. So I think the first key to doing support well is understanding that what you're doing is you're building these products and you're offering service products and so there's products and then there's not really good products and so an anti-product is kind of like the column on the left where hey, just call us when anything happens or if something goes wrong and we'll help you fix it or we built your site and then say, you know, you get a phone call and it's like hey, you know, you built us that feeds integration and originally it was for Twitter but now we're, you know, we're downloading Chinese newspapers and it's not working so that's a bug and you need to fix it, you know, or if you're accepting new projects from people and you get a call that hey, I'm a Drupal developer and I have this site that I'm building for the Czech government and it's overdue by a month and there's like five things that I don't know how to do so I need you to help me fix it ASAP. Like I think those are sort of recipes for failure and I think when you build kind of your product line of support services it's a good litmus test to kind of see what, if things fit into that product list those are your strengths and if they don't then they might not be good things to take, like you might not win with them. So what I want to talk about is kind of how to build these successful products, you know, for example support development. Like when it's a product that means you can attach parameters to it, you can, you know, you spell it out for sales, what the limitations are, what you cover, what you don't cover, you specify the billing rates and if a product is successful with just changing a minimal number of parameters you should be able to use it over and over, you know, so if you sell block hour agreements, you know, you should be able to just say 50 hours or 100 hours, you know, at 100 hours the hourly rate drops by, you know, a certain amount, but essentially it's the same kind of thing. You know, there's been examples when I worked at Promet in Chicago, we had a client that had already built a site on D7 and they wanted to continue working with the dev shop that they had, but the dev shop used SVN, SVN sort of in a half ass manner and they wanted to use Git, they knew they needed to move to Git, these guys weren't going to migrate to Git at that point in time. So they hired us to basically just be their release management and we set up a schedule where we pushed things, you know, where if we saw anything that had been committed to the repo, we would push it to dev, we worked out the QA workflow to where, you know, we would let them know we pushed things and they would check on it and then we would push it to live and so forth. If anything went wrong, we would revert it and that's kind of all we did and it was kind of cool because it sort of put us in that loop of trust, you know, where if they needed decisions they kind of knew who to come to for a second opinion and eventually we sort of became more of the de facto go-to. So I think like creating products that you can support and sustain is beneficial even if they're not just your typical kind of Drupal support. And additionally like another one is doing updates for people, like just doing updates by itself may not seem like of much value but it is for a lot of people who may just need something who are happy to manage their own site or, you know, just need to take care of the minimum basics. And so what I want to do is some case studies of these three fictional people and how they made support work for them. So the first one is this girl Aria and she's a site builder. She knows a little bit of PHP. She's mainly built, you know, a few sites for people, for friends, for family, that kind of thing. And so her issue is is that as a freelancer she has a lot of stuff on her plate. You know, she has to do her own marketing. She has to look for new clients. She actually has to build the site. But in addition to that, the existing clients say 10 of them a month are calling her to ask questions. And then maybe, you know, 10 customers are calling her for five hours a day or five hours a month and maybe she's doing three hours of billable work from that. And then all together, that's about a week's worth of work. Like 25% of her month is doing work that's not really well organized. It's not bringing her in new business. It's just sort of upkeep on existing sites. So a use case for her, she goes to meet with her, you know, support consultant and this person, they set a strategy and the target is like existing clients. The client she already has on our platform is to monetize the free and kind of piecemeal work that she's been doing for the people. So the change in messaging is like prior when we were talking about like, well, you built this and now it's a bug. The messaging that has to start like really high, you know, in the discovery period is like, you know, Drupal is this great way to build sites, but keep in mind, your site is a custom site. It uses custom code. Even if it's contrib modules, your end user is really well educated on what they're getting, the benefits of using Drupal, of which there are many, but the fact that bugs exist in life, they're suffering. We will figure out a way to address these things and it will get worked out because I know what I'm doing and this is how I do it with my support products. And I think it's also really, you know, rather than wait for the first month's invoice to go where you built for the time that you've spent talking about Drupal, it's good to say, you know, as we build these support products, what I'm going to do is I'm going to set up this ticketing system, so after we launch, there's going to be a ticketing system. If we talk on the phone about it, it's going to be billable. If you give me a really complete, concise ticket of what's going on, how to replicate the problem, that's not billable and that will save you money and it will save me time and we can be much further along on this problem rather than conversing about it, which is real hard to do plus it's billable for you end user. So you create these products where you say, okay, I'm going to give you a block of hours a month. I know over the last few months we've probably talked about five hours a month, so let's just start out with five block hours recurring each month and you use them or you lose them but we can kind of knock out these things rather than piecemeal. You tell me how you want that five hours spent or we can save it for emergencies or that kind of thing and then you set up a second one that's just monitoring. Okay, here's monitoring and on the back end I set up my Pingdom account, I set up my PagerDuty account and I find a good host. I know of a really good one by the way if you want to talk about it and you have something on the back end to kind of support this product that basically just says I'm not a sysadmin, we picked a host. They'll support the platform but I'll be the point of contact. So if something goes wrong it'll wake me up but I can get on the phone and manage it and make sure that it's done. And then the final product that I would offer you as an end user is like your managed updates because there's security, there's core updates and so what I'd like to do is the way that I do it is when security updates come out we do it in a week. We do it up with a QA workflow plan where either you have a couple days to go through it or you let me QA it, I create my Selenium tests for X amount of dollars or euros up front and that's how we handle updates and then so we do security updates that week can trip updates, we do quarterly let's set something like that you work that out at the beginning in the event that you push a contrib update and it breaks something hopefully you've built a great site that might not ever happen but suppose it does you can either revert it or you can use the block hours to fix it because that's the nature sometimes bugs happen I want to be successful I want to be around forever I want to support you forever I need to make money on this as I go listen to her support consultant which doesn't really exist as a role but she does that and she comes up with these numbers just 500 units of currency for five hours a month and then just a low price for the monitoring plan because it's just monitoring it's waking up possibly in the middle of the night but the host will hopefully be handling any issues and then the updates which would be $200 $50 a month to handle all the updates and so what we have is the $500 is a block hour agreement a monthly recurring block hour agreement the 50 is managed services from the managed service world it's flat $50 and then the updates are a flat $50 or a flat $200 and so what that does it sort of puts the risk on you and puts the onus on you as the developer to be able to make that profitable but if you amortize that over a year as long as you're doing less than 24 hours worth of work you're roughly making your margins so hopefully again I found that this works because core updates shouldn't break anything can trip updates might but you're doing it quarterly so you can give them the option to hold off or it's not going to add a new feature so we can wait on it but security and core gets done so this is an example for her and so we're looking at instead of roughly 400 based on what's billable the end result for you bundle it all these different agreements together into a managed service agreement and they pay $750 a month so the next example is like in America you have to attach a number to your dev shop in order to make it real so I made this one Hodor 9 which is a dev shop in America that's been around a while and they put out a lot of sites and they're pretty well established the problem is they've been offering support for a while and it's really disorganized project managers are managing support as well they hate it devs are getting pulled off of projects to work on support issues for really difficult problems everyone's getting burnt out the devs don't want to work on support and they can they have a list of up places they could be working and maybe they don't want to be doing support they want to work on fun projects not picking up the phone whenever there's a fire because trust me no one ever calls support because things are going swimmingly and they just want to say hi so so that's the problem so the strategy we've already sort of talked about existing customers now let's just focus on like new clients the new people that come in and they're looking for support and generally and so the goal is to make it sustainable and so like the risk is is you get the call and this is a support client that I've handled before where it's like hey so you do support right I googled support and Drupal and your name came up so that's great I have this D6 site it's actually our intranet and it's actually running on WAMP a Windows NT server and so if you want to do any work I'll give you a dongle so you can VPN to a dev site and do the work there and then we'll push the changes together and so that is enough to make like your developer just you know post his resume and say thanks but I'm not going to work on this and so the message that you want to convey now is like that's awesome but we work on supportable working sites and that may not be one now that's kind of an extreme example but you may get someone that just comes in a more typical example is like someone who comes in with a laundry list of like hey you do support that's great I need a dozen things done here they are and so it sounds simple but the issue that you run into is you know you say sure we'll do it and then you look at the site and you see like um panels there's always sweet context and like eight other things that kind of do the same thing and some are enabled and there's like one panel that's active across the whole site and you know there's you know you sort of like shit what have I done you know and so so the model for handling this that I have found to be successful is you say sure we're happy to look at the site and from there we go through onboarding and from there we you know once we get things into a supportable state then we start working on the issues and so some people will balk at that and I think it's important for the success of your developers and the long term success of your company to know when to say no you know there's like um the Groucho Marks line about you know I don't want to be part of any club that would have me as a member and so it's the same kind of thing like when someone's looking for support it's almost like an indicator in itself like maybe they were fired by their you know especially if someone comes up to you and say yeah our devs were really assholes at the last place you know so um you know we know that you're good so we know you'll fix it especially if you know the devs it's a small community so a lot of times it turns out that they might be a difficult client to handle or they had some sort of weird use case that that um is difficult to solve so you have this site audit that you've developed and so yesterday there was a pretty good session on site audits uh there's many different places where you should be able to piece one together pretty quickly if you don't have one who has a site audit that they do so um really with me I've tried a couple different times the one that we use now at Pantheon is actually pretty good uh and it's available like anyone can use it it's a bunch of Drush commands that we created and it's just a project called site underscore audit and it's a bunch of Drush commands it's sort of Pantheon centric for like our enterprise stuff so it tests to see if caching is working and it to me like a lot of the site audits like you can spend a lot of time digging into like hacked encoder and things like that which are all useful um all really useful uh I also think that there's a lot of things that are uh really closely correlated with a problematic site you know the number of modules that are enabled things like that and so like the thing that we built kind of checks for that but also uh the Drupalcon uh Portland uh session that we did two uh women one from chapter three and one from ProMed in Chicago all go into detail on their site audit and what they check for you know like uh PHP in fields and things like that to sort of give a feel for like how difficult it's gonna manage or you know if somehow you know they make a small change what it might affect across the whole site so design this site audit hopefully you can execute it within a few hours I don't know depending on the custom stuff like the guy yesterday was saying sometimes it can take up to 30 days but execute it quickly and bill for it you know say because what you're gonna give them like the one that we have um it uses like the Twitter bootstrap so it actually generates like that report there you can use it from the command line but it also gives some a nice deliverable that you can say hey you may not know much about your site but after this you'll know a little bit more and it's gonna be thirty two hundred dollars and that's what we charged and it covers your time and um the resources that you put into doing it so you develop this site audit and if it passes then you just you say that's great let's have an onboarding call let's have a kickoff call let's talk about what we need to fix um if it doesn't pass then you say okay so here's here's how we handle support now that we see that there's bigger problems that we need to fix to make your site supportable um we we think we can do it you know in an agile fashion it's gonna take fifty hours and so let's start out let's take these fifty hours let's get the site to where we know it's gonna last and we can start doing the work you want some will say no you know it's up to you to kinda make the call if you wanna bypass that I would say no like I think that there's I have found at least in my neighborhood there's a lot of people looking for support and if you build a roster of supportable sites it makes life so uh for an example to project the revenue here they do this one time site audit and they charge thirty two hundred clams for it and then there's a problem and they fix it over fifty hours you know so it ends up costing ends up costing more than they thought they wanted it to cost and then they say okay so now that we're done with that let's set up a monthly recurring plan similar to what we talked about with ARIA where we do updates we do monitoring only this time there's an SLA where we actually guarantee that someone's gonna get to you within two hours or four hours and you base that on the amount of time it's gonna take for one person to not get the call and then the next person hopefully to get it and then you add some padding and you come up with a number that you feel that you can live with and offer and you tack on an SLA to that and you build a little bit more for it and then you come up you know say that they don't want to do a monthly recurring user lose kind of hourly commitment then they just buy two hundred block hours you do it at a slightly higher rate because they're not doing monthly recurring like monthly recurring is the best for a dev shop if they're not gonna go for that that's fine it's just a little bit higher and then you know there's sort of an example of what your total annual revenue is for that client and then the last one which is just sort of like kind of a thought experiment is this guy Joffrey and he knows nothing about coding or site building what he does know is about how to speak English good and he also is a you know he graduated with an English degree which in America they say is like the most useless degree to have and so this guy he really the problem is that he can't pay his rent and the bills for you know the seven kingdoms that he also happens to be king of so his strategy is to target other dev shops other C level people who have blogs and he's gonna create a product that delivers content management because in my experience I had several clients who were not computer savvy and struggled with whizzy wig and really needed someone to do that and there are people out there that do this pretty successfully and it's something that a lot of dev shops don't think about offering it's like we don't want to offer content management we'd rather not even offer support but you know we definitely don't want to be editing content for people but there's also a way to do it where if you know you teach someone how to use whizzy wig you teach them how to you know create a Google analytics report that sort of shows what happened to content for the month you give them like a QA workflow and you say this is you know you send me the ideas I'll clean it up it's gonna come back to you I'm gonna download an image from Shutterstock that I think is kind of appropriate stick it in there we'll do five a month and we'll bill 500 bucks a month for it to make sure your content is updated we kind of ride you and PM you a little bit to make sure that content on your site is always updated and so this is you know maybe not depending on what your payroll expenses are this might be pretty close to the same margins you might be able to make based on you know how you know the rate that you can hire people at so you know it's just sort of a thought so we're doing my time here okay three more hours so project mind and support mind so the important thing to think of is the biggest thing that I've noticed working with other dev shops is the usual approach is trying to approach support as if it's a project and you get really good at agile or waterfall and then you get to support and it all goes crazy because it's all these various issues that come up and then go away and disappear and then ten issues completely unrelated to come up and then the third one is a really difficult problem that ends up taking forty days and then the you know the developer has to try and estimate on a site that he's never seen before or maybe hasn't touched in months and so that's where a lot of those things get go haywire and that's why having kind of these processes in place is really important so you build these processes you know because generally what comes up you have problems like my site is doing something weird you know you have incidences my site just went away you have requests like I'd like my site to do this and then you have change management like it's time to go from D6 to D7 or whatever and so like those categories are sort of a good framework for how you build your products and how you sort of respond to kind of emergency situations and so the way to think about support is not projects but what helps me is kind of a standard in case model so standards are repeatable processes like if my wife if I come home from work and my wife says let's go out to eat that means I say okay and I change my clothes and we go out to eat that doesn't mean like I debate it or I complain about it or I mention that I just went out to eat the night before because I know my life is much better if we just go out to eat that's like a standard I don't care if I went out the last seven nights we're going out to eat again tonight easy you know that's how you build like a standard but see I'd say that accounts for maybe 25% of Drupal support related issues most of them are cases so you treat them as case management and that's where you need to do some investigative skills you need to do some troubleshooting you can gradually build the standards of the tasks that need to be done and the goal is to make as much as possible standards rather than cases so then the difficult stuff at the very least if you have like a level one and level two support person level one can look at it and say I don't know the answer but I do know that I'm supposed to get log files I'm supposed to check this and this and then I'm supposed to summarize and give level two a replicatable way to reproduce the error so you have your level one person which maybe at a lower pay level or lower experience at least they know how to build build it up and summarize it and give them like a neat gift rep package for the level two person more of like the problems incidents all that cool stuff about like service delivery framework available via itil like which has existed for a while like support is actually pretty well defined maybe as much as project management is it's just that it tends to be like on the enterprise IT managed services world but you can it's very completely dry boring reading but it has a lot of cool stuff for building support projects and then so like my onboarding thing is really important because this is where we get into really what matters with support almost as much as technical chops is the soft skills and the ability to quickly kind of build a process where people are familiar with how you do it so you have this onboarding call you know say that like we talk about you know they've done the site audit and they're ready to go you have an onboarding call and this is what you go over you go over the processes they need to know immediately like how to create a ticket how to create an emergency ticket how to call me how like what a ticket needs to have in it for us to get right to work on it what hours were available for support how to reach us that kind of thing then you cover all the questions you take all the questions that people have asked you over the last 10 months and you compress them all into a 30 minute call where you answer all those questions that keep coming up so you you theoretically kind of answer the first two standard deviations of questions and then you do it like the most important thing the weirdest thing is people actually like to see my face when we do this call so doing it on the phone is nowhere near as effective in the long run as doing a go-to meeting or WebEx or something where you're connecting and you're seeing like this is a human being so before they start you know the sort of the email furious typing at a nameless face they know that we've talked and I'm you know I'm like a human being I have feelings I ache I cry and then you set expectations and like one of the biggest expectations in support is about estimation and it needs to be for me it really needs to be explained up front that estimation is by definition what wrong it's incorrect like it's me like estimation is trainable like you can get better at it and most PMs know after they've worked with any developer for any specific amount of time like how much they need to multiply their estimate to get kind of the real time you know it might be 1.5 it might be 3 it might be 0.5 sometimes but I think that's something that management needs to help train people and you can kind of go back and look at histories and see how things really ended up taking and kind of help with the process a little bit but it always needs to be explained that it's an imperfect science the more we get to know your site the better it'll be but it's kind of inexact so let's talk about hiring and retention it's hard to find someone who is really super at Drupal and wants to do support I said it it's also hard to find someone who has the soft skills to want to deal with an angry customer sometimes or to be able to explain things to someone who gets frustrated by technical jargon and so generally my advice is to find someone who's really good at one thing and really willing to learn the other I think you can to a certain extent you can kind of teach both you can at least help people get better but only really to make the effort and I think that to help them get better at the technical side of it I think that's a good thing for bench time I think that's a good thing for level one people to kind of see how level two what kind of information they need and slowly sort of build their chops that way and also I think that you know building tools like the site audit and things like that are great tools to help a level one person kind of get more familiar with with Drupal with doing support and that kind of thing the soft skills so one thing that I really recommend is verbal judo verbal judo is like has anyone ever heard of it yeah verbal judo originally is what they teach the police to teach people to be persuasive without being violent and you can hear there's a great example like we're doing good on time so I want to tell this story because it was really amazing so I'm in North Carolina and I'm sitting outside at a Starbucks and pretty typical American scenario right so so I'm sitting out at a Starbucks and I hear a policeman like a plain clothes policeman get on the phone and he says hey I'm looking for your son and then obviously the son's not there and he said okay well this is kind of serious because there was a child who there was an incident of child molestation that was reported to us the police and there was a name given and so we ran that name through our computers and two names came up and the child described the person as being about 250 pounds and so the first person was under it was way under that so I don't think that you know it's not him probably but we see here that the records for your son says that he's about 195 so that's very different so all I need to do is I need to go by there and just give him an eyeball give him a quick look just so I can check that box just so I can show that I've done my job and we can just move on and like you know what was really going on there right and I was like verbal judo that's what's going on like being able to say things in a way to get what you want and so you won't have to deal with situations that seriously like in Drupal development hopefully there is like the dark Drupal underworld which is another session at another con somewhere but you know there are times when you are asking the client to do something that they don't want to do you're asking the client to sometimes if they call and they're pissed then the correct you know the normal response from me as a human is to respond in kind you know or maybe even level up a notch you know I'm a human being if someone's insulting me or my company or threatening my financial security I'm going to you know want to fight back but it's amazing what happens not if you I'm so sorry if you say that is unbelievable that is unacceptable let me see what we can do right now to kind of resolve this problem and you let them know that you understand without just giving sort of a blanket apology for whatever and you immediately go to get to the bottom of so verbal judo you can see like this guy on youtube he's passed away but you can also download the books on kindle or whatever and it's a good read it's a quick read and it gives it sort of helps to explain what soft skills are and how to use them effectively the next thing that we developed at pantheon is cakes and so you won't find this in google because I made it up and so cakes stands for um for uh uh what does it stand for um let's go um it stands for uh completion accuracy execution and empathy and this is how we do ticket reviews just like you do code reviews we do ticket reviews because we tried like sending level 2 tickets back to level 1 so they can see how it was fixed um and that didn't work so much um but we do find that if level 1 has a problem with a ticket they can tag it with for review and then twice a week my team gets together and they go over tickets that were solved or in progress and they review what happened and they talk about you know was I complete was I accurate um did I execute the ticket workflow like did I escalate it right that sort of thing and was I empathetic like was I a jerk was I too short did I not look at the problem enough or was I responding fine you know and so it's amazing how well these things actually work because everyone you know it's a blameless sort of area you know way to get better at something and then also using metrics like you look at metrics like to me one of the most um wall building metrics is utilization you know if at the end of the week you say hey um you are only like 30% billable what's going on you know and it might be because he was solving a problem that was so hard that you had to write off hours or something like that there's a lot of metrics you can use like one of the metrics that we use that's really valuable is what percent of tickets did first level resolve like we want that to get better we want them to resolve you know most of the tickets you know it would be great if they could resolve all of them but we know that's not going to happen but the more they can resolve on their own it's sort of empowering and they want to get better at it too you know or we look at first response resolution like how ease how much were they able to like be like Batman and just wrap their wings around the problem and think of what it might be do a bunch of quick debugging with like here's the issue here's how you resolve it you know that kind of thing like using metrics as sort of an empowering tool is a good thing to do um and then like for managers I think one important consideration this is like something you can probably Google it's called the leader detractor scale and so the leader is someone who does what's expected does something extra and help someone you know like a real sort of overachiever kind of person a contributor at the level below that someone who does what's expected and something extra and like those are the two groups that you really want to look for and nurture and hire because everything below that you know even someone who does only what's expected sometimes in support isn't enough like if you say hey check this out it might be a cron issue then you'll get a ticket back saying wasn't a cron issue you know the customer is still suffering um they've done exactly what you asked them or what they thought you wanted so it's kind of a you know a back and forth kind of thing but you really want to look for people who can sort of you know really empathize with the issue so um that's that was a really bad animated gif um I think that's kind of all I wanted to talk about um I hope you liked it and if you have any questions let's uh let's talk so thank you Nick um so email bravery was uh email bravery is when when you send an email it's also you can see it in various parts of the internet where people are willing to say something that they would not say to someone's face via email and to me the best way to combat email bravery and I am I have done it so I'm not saying sometimes customers get mad they type emotionally and that's not good for a support department to be on the receiving end of that so here's how you fight it my favorite image is like someone typing it and sending it and like take that and then they look at their phone and their phone rings like that's how you combat email bravery like as soon as you receive that email pick up the phone and call and directly say hey it sounds like you're upset you know or hey we screwed up and you know it's amazing how quickly you can turn it around sir yeah um okay so ticketing system that's a real that's a great question and um so in the IT managed services world there's a couple really good products like the cream of the crop is like a Siebel system that handles all that and it also handles like agreements and block hours and all that SLAs that sort of thing the next step down that I used at my managed services company is don't write this down because I'm going to tell you why you're not going to buy it in a minute um is a company called connect wise and connect wise also handles block hour agreements all that stuff if it handles it as a customer portal it does all that stuff you're not going to buy it because one there's like a $12,000 initial fee to just get it set up the number two reason you may not buy it is it because it requires a dot net application to be installed on your computer um which you know ruled it out for when I pitched it to the Drupal shop um so we we at Pantheon use desk which is a sales force come sales force product um it's not perfect but it works um I think the main the the thing the thing that you need to consider is you really want to get something that does billing and we ended up using a product called this is this doesn't have a very happy ending by the way um I found a product called blue folder which became packet trap as they went down the poor naming ladder that became packet trap and I was actually going to bring it up here but I went to the site and they were bought by Dell which everyone was excited about which quickly killed the product all together so um now my recommendation would be desk works okay it doesn't handle like billing and which can suck up a lot of time um consider something like desk or Zen desk or fresh desk plus maybe something like harvest um that can handle the time entry and billing and that sort of stuff another consideration is any of those most likely have a way to write something um you know you could set up another database like an agreement kind of thing that um takes billable time and we'll dev it down the hours so I wish that maybe there is a better product out there I couldn't find one or else I would have talked about it here uh so we have people using pantheon in Europe we do not have a uh Euro data center I should have started with that that seems to be a common question we didn't we didn't know you liked us no we have people using it in Europe we have a lot of people using it in Europe Australia especially in conjunction with the CDN but um but yeah we will eventually we want to we like it here sorry sir I wasn't paying attention what does the X stand for in cakes execution I sort of had to you know thank you you're welcome so um 546 so an agile approach to support doesn't always work sometimes it does it works when for me it works best when it's that initial you've onboarded someone and there's a bunch of problems you know or when there's a laundry list you know if you have a client that has like I need these 10 things that need to get done like after you've gone through that that lends itself to like an agile kind of thing again that's really hard to estimate because usually it's your first look at a site when you're handling that so it's really important to stress that estimation is going to be way off base so there's no more questions thanks a lot and it's awesome being here we'll be around oh Wonderkraut is doing a similar support related thing tomorrow at 1045 and then there's going to be a buff right after that at around 12ish so if you want to talk more about support um there are a cool bunch of dudes and we'll all hang out together and talk about support