 to sustainable support. Thanks for sticking with us as late in the day. I'm sure that a lot of you are tired, and I'm sure a lot of you guys have learned a lot today and are a little bit mentally exhausted, but I'm really gonna try to make this worth your while. I think there's some really good insight that I can share with you guys on supporting any kind of product for customers. It's applicable to themes, plug-ins, even if you've just designed sites for clients. I think it would get a lot out of this. I've been doing customer support for many, many years in many different kinds of environments, primarily production environments. And that's given me kind of like an interesting way to look at supporting products and supporting people. Probably one of the most influential support experiences that I had, I was working for a chemical company and we also supported their finance department. And I remember we got a call, this lady was saying that in her outlook, can you guys hear me okay, am I good? No, you can't hear me? Whoa, okay, I'm gonna lean down like this. So I was working for this chemical company and this user was having an issue where she was saying that every time she closed an email in her outlook client, it was closing all of outlook. And then she was also having an issue where whenever she deleted an email, it was actually deleting three or four emails at a time. And she just insisted that this was an issue but I could never replicate it. And so finally I went and I sat down with her and I said okay, so show me exactly what is happening, what is going on. And so she had outlook open full screen and she opened her email full screen and she said look, when I close the email, it'll close outlook. And she goes and hovers over the X and double clicks. So she closed the email and then immediately closed outlook because it was right behind the email. And I'm like okay, so show me this deleting problem that you're having. And so she goes and she pulls up her email folder and she says see whenever I delete an email, it deletes multiple emails. And she clicks the button for delete but she like double clicks it. So I'm like okay, so I know exactly what is going on now. So as politely as I could think to do, I said well it looks like you might be double clicking those buttons. That's actually just a single click function so you don't need to double click. And she looked at me like she was gonna murder me in that moment. And she said I have been at this company for 15 years, you've been here three months. How dare you tell me I don't know how to use my computer, how dare you call me an idiot. Which I didn't do, I was trying to be, you don't really polite. And so I'm like oh man, what do I do? Because I hadn't been at this job very long and I really don't wanna make anybody mad at me, right? So what do I do? And so I looked at her and I said okay, knowing that yes she was in fact double clicking because I heard the clicks. I said maybe your mouse is broken. Let me see if I can get you a new mouse. Yeah, it's my mouse. So I went and I got her a new mouse. I used the mouse, I swapped out the rest of my time to that company and never had an issue with it. But I learned a lot about dealing with customers that day and dealing with problematic customers especially and how you need to approach those different kinds of situations. I have this, I mean you guys, have you seen this gift before? Of the box just rolling down the conveyor belt. Right now I'm the director of happiness at the WP Ninjas. So I'm responsible for our customer support for our Ninja Forms product. But before I worked there I worked at Amazon and one of my favorite things to do was just to watch the boxes go down the conveyor lines especially around the Christmas season when it's just box after box after box. It's just this weird mesmerizing thing. Have you guys ever watched How It's Made? Oh man, is that not like the most hypnotic show sometimes? Just watching everything go down the line. I've actually seen this happen to boxes before and what has happened is there's some kind of cylindrical item in the box and it's not packed properly. The donage in the box is not stopping the item from moving around and so the item just keeps moving and rolling. The item itself is kind of rolling down the conveyor but the box stops it from actually going. And I think this is a really good analogy for support for many reasons. One, because, sorry, got ahead of myself. One, because I view support as a production queue but also because this can feel sometimes like our support queues feel like. That we're doing work and we're doing work and we're answering questions and we're answering tickets and we're not going anywhere. We're not making any headway. And so my goal is to try to give you guys some skills, some abilities, so that you know how to properly pack your box so that you're not just constantly rolling and rolling and rolling. So what is sustainable support? What do I mean when I say sustainable support? For me, sustainable support has three primary goals. Number one is to grow faster than your support queue. Meaning if you have sales that your sales increase faster than your support queue or your downloads or generally just your company's business grows faster than your support queue can grow. Generally speaking, if you do nothing but marketing and you have a product or you're just building someone's site, it should be a pretty linear thing. If it's not, if your support is growing faster than you're able to push out products then you're doing something wrong and we'll talk about that a little bit later. But generally it should be linear but sustainable support, my goal is to start to taper that off where your business continues to grow but your support queue does not grow as quickly. Another thing, another goal of sustainable support is to be able to manage more with less. I want to give you tips to free up your time so that you can do other things and you're not just doing support tickets or God forbid that you get so many tickets that you just can't manage it on your own anymore and you have to bring an external help or you have to cut other areas of your business to support them. And third to avoid burnout, if you're only looking at a ticket queue all day, like I'm one of those weird people that I actually really enjoy customer service for the most part but even I, if I'm only looking at a ticket queue all day, it can be so overwhelming after some time just dealing with issue after issue after issue after issue and it can definitely cost some burnout so you wanna try to put your time in elsewhere so that you're more productive when you're actually doing your support queue. As I mentioned before, I view support queues the same way I view production queues and I think boxes are a really good analogy for that. It can be strange in a product business or if you're supporting a site that you've built for someone to kind of try to look at all of the problems as the same thing as something that can be done in a production queue but that's another reason why I think that the box is really good analogy because you don't know what's in that box. It'd be a completely different product in every box. It can be packed in a completely different way in every single box but the process is still the same. With pretty rare exceptions, FIFO, which means first in, first out, is the best way to handle support. Meaning the first person to bring the issue to your attention with the exception of major breakages like my site is down or something else is going on, that should be the first thing that gets your attention which is another way that they are very much like production queues. For all of the tips that I want to offer you, they all have 5S as the foundation. Now I'm gonna be talking to you about some lean manufacturing methods which sounds really weird in a WordPress environment but these are things that are used in production and are used in business because they make the business more productive and it doesn't just apply in a warehouse environment, it doesn't just apply in a production environment. Hopefully I can help teach you guys how it applies even for seemingly simple mundane things like our WordPress support queue. But this is a prerequisite. If you don't have 5S down, then your other support efforts will fail or will be significantly more burdened than they need to be. In a warehouse or in a production environment, 5S is used to eliminate waste and to make the best use of your space, okay? So for example, if my job is to take a ratchet and ratchet this one bolt in, I'm gonna keep that ratchet right here on my desk at all times and when I need to use it, I can just grab it and I can ratchet what I need to ratchet and I can come back and I'm done. I would not keep that ratchet in another room if it was something that I use as a repeated tool. And 5S kind of deals with those kinds of situations. The first S in 5S stands for sorting. I think this gift is very appropriate for what sorting should look like. If you are, sorting basically means you need to go through all the tools that you have and get rid of what's not necessary. You need to only keep the things that are necessary and use those things. For example, if you are supporting a site or a theme or a product and you are accepting support requests through Code Canyon and you're also taking support requests on Twitter and you're also taking support requests on Facebook and you're also taking them via email and you're also taking them via your website, you are wasting way more time than you think switching between all of those methods and it also ruins any chance that you have at properly gathering the data that you need to improve your product. And we'll talk about that a little bit later on. What you should do is pick one place to handle all of your support requests. For us, we use HelpScout. It's basically to the customer, it's almost completely transparent. They come, they fill out our form, they get an email back from us when we reply and from the customer's perspective, we're just emailing them back and forth. But if we're supporting in multiple different places, it might not seem like much, right? It might not seem like you get a big time savings if you're not also supporting on Facebook and email and everywhere else. But if you think about it, every time you get a ticket in one of those places, it takes you, I don't know, at least five to 10 seconds to even get to that place and start reading the ticket. And when you multiply that by however many support requests you receive on each of those services, there is a massive time savings that you will find by consolidating everything into one place. And that's, again, that's something in a production environment that is always considered. Tiny little fractions of a second but multiplied over thousands is a huge time savings. The next S is set. You pick the tool that you're going to use. Now you need to figure out the most efficient way to use it. This is kind of a lame gift, but it's the closest thing that I could find to setting things in place. So let's imagine that you've got your tool and you've got your tools, you've got your ratchet. Now you need to have a designated place to put it that you never lose it. You now set up your area to hold your tools. You know what you need? Now you set everything up and when I worked at Volkswagen, they would actually take a thick piece of foam. It was about an inch or two thick and they would cut out in the shape of the tool that you were to use at that station. Just a little cut out from the foam and your tool would always go there. And whenever you weren't ratcheting something, your tool went back there. Now in a support system that's learning the workspace that you have. Let's say that you've decided to use HelpScout or you've decided to use email or whatever you've used exclusively, this is now taking that tool, looking at it and refining it, learning it well for your use case, documenting how to use your tools, especially if there is more than just you that is supporting the environment. It's also defining your support scope. At this point, you have to say, okay, we're kind of sorting, we're kind of getting rid of all the tools that we don't need. Now we need to define specifically what it is that we support. If you have designed a site for someone, how much is within your scope of support or how much will they need a change order if it pushes past a certain point? The next step is shine. How many of you guys have ever had a desktop that looked like that? I am the king of that desktop. It happens so, so often. But one thing I've noticed when I'm answering customer tickets, for example, if I need to send them a file, my downloads folder especially always looks like this. And if I need to send them a file, sometimes when I open that folder, I need to pick the file that I need to send to them. I have to scroll or I have to remember the file name and start typing in or it takes a minute for me to find whatever it is that I need to send to that customer. And it's because personally, my workspace is not as organized as it should be. And that's part of the shine step. You've got, you've picked the tools you're gonna use. You have a place for all of those tools, but now it's time to start cleaning up because the time that I spend trying to find the file that I need when my desktop looks like that is time that I could be spent getting away from the support queue and avoiding burnout. Does that make sense? It also involves the shine step would also involve using things like your calendar or drop task or Trello or something to really start to manage. Okay, you've got the tools that you're gonna use, but to keep track of everything that you need to do because it's really easy to do a ticket and realize, oh crap, man, that feature is not as documented as I thought it was. I need to write some documentation for that, but then you never get to it because you forget about it because you didn't put it somewhere else. So this step is all about personal organization, making sure that you have all of the tools that you need to make sure that you are efficient. By the way, if anyone has a desktop that looks like this, I have a really good solution. What I will do, because I'm always leery to delete everything because I don't know what I'm gonna need. So I will take every file and I'll drop it in a folder on my desktop. And if I don't open that folder within like a week or two, I just delete it. That way everything is there, but it's not cluttering up my workspace. That's my personal strategy if any of you are dealing with clutter desktop syndrome. The next S is to standardize. And standardization is documenting everything. Get as much documentation out as you can. You've picked the tool that you're gonna use, but how do your customers know that? For example, we don't monitor the WordPress.org support forums on a regular basis. So we have a sticky thread at the top that says, no, if you come to our site, we will answer you same day, but we don't monitor this place for support. If you want help, you need to reach out to us there. And it's making sure that your customers know not only where you provide support, but that scope that you decided in the shine step, the scope of the work that you're going to support, your customer also needs to know about those things so that they don't message you and say, hey, I'm trying to use your form builder product as a complete e-commerce solution. And I'm doing, I have 3,000 lines of custom code, and I'd really appreciate it if you would just audit that for me. You know, they need to know that, hey, custom code is a little bit out of scope for us. We'll support the product that you've purchased and we will give you documentation and help point you in the right direction, but we can't audit 3,000 lines of code for you. If you'd let your customers know about this ahead of time, then you can possibly avoid even getting those kinds of tickets. But it's also documenting for your users what kind of information that you need from them when they request support from you. For example, our contact form, when a user says that they need technical support, it opens up a bunch of fields and asks them for specific bits of information that if we can get those right off of the bat, right off the bat, it will really help us troubleshoot their issue in a timely manner and get back to them as quickly as possible. Another cool thing that our form does is if they pick what is a common issue or a question that we get asked frequently as something that they are needing support for, it'll give them the documentation right there in the form and we can stop them from even getting to our support process in the first place because we've given them the documentation and the tools that they need. The last S is sustain. Sustain is the most difficult part of the 5S process because it's very easy to fall back and slip into those old habits. Sustain is having the discipline that when a customer reaches out to you on Facebook that you've helped on Facebook before to say, hey, I really absolutely wanna help you but can you please go fill out a ticket over here in this system because this is where we do our official support from now on. Because if you don't do that and if you don't tell customers that and really you can phrase that in a way that's really good for the customer, right? Like say, hey, I watch this every day, I can absolutely take care of your issue so much faster if you'll submit a request here instead of doing it on Facebook. Frame it in a way that is good and positive for your customer but if you don't do that, you have undone everything that you've done in the first several steps and you're right back to where you've begun. So 5S is the most critical portion of having some kind of a sustainable support process. The next thing that I'd like to talk to you guys about is the Gemba process. Now, if you work in a warehouse or in some place that practices lean manufacturing they'll do what they call the Gemba walk. It's also called management by walking around but what Gemba means in Japanese means the real place, the scene of the crime, a reporter would say I'm reporting from the Gemba or it's also in manufacturing known as the place where value is created. And in a warehouse environment or production environment what will happen is the managers will go and they will just pull random people off the line that are working on producing something and they'll say, hey, what are your barriers? What challenges are you facing today that I can help you with? And that's one thing that I think in the product support business that we don't do a whole lot of is asking customers where their pain points are before the customer has to come to us because there might be use cases that you hadn't considered. I was talking earlier with some of our team there might be something that's just a minor annoyance for somebody and so they don't come and tell you about it. They don't wanna bother you with a support request but it's actually a minor annoyance for a hundred, a thousand different people but they all just think it's too minor to say something to you about it. But if you invite that conversation you open that conversation up to them and tell them, hey, I value your feedback. I wanna make this better for you. Then they will tell you those things that they think you can do better and some of them might not be good ideas and we'll talk about that more later but some of them might be something where you can say, yeah, I can understand why you would wanna do it that way. Let me help you with that. But basically, traditionally a gun buzz a chance for managers to interact with and understand employee challenges but I think we can use that in product support to manage and interact with our users and understanding the challenges that our users are having. One of the most important things is to learn your product. We recently pushed out a major update to our extension and when I went to redocument all of the new features I started realizing, wow, from a user's perspective this isn't very intuitive and I started realizing, yeah, if I was a user that would be a little, maybe we need to tweak this feature a little bit. Maybe we need to change the wording in this phrase so that they understand what that option is for. But also having good documentation really avoids a lot of support questions in the first place because most support questions could probably be solved by good documentation. It can be a struggle but it saves time. We say all the time never answer the same question twice. If you have to type a response for the same issue to a customer more than one time there should be a document for it or you should take other steps that we'll talk about in a moment. Also ask users for feedback. This is what we were talking about a minute ago. Send them unsolicited messages asking them how they're used to the product is going. Maybe they've submitted a support ticket to you and then a couple weeks later you reach out to them again and you say, hey, that's what I'm gonna make sure. Is everything still working okay for you? Do you have any more questions? Is there anything more that I can do to help you and help you be successful with using our tools? And third is understand the hidden use cases because users will find ways to take what you have built and use it for things that you never intended for them to use. One of the things we've talked about with Ninja Forms is we have users now who will make 1,200 field forms which is not the original use case. We were thinking, hey, maybe like a contact form, maybe like a longer registration form, but 1,200 fields, man, that's massive. And so in our recent update, we made a lot of changes specifically for those people to make the product use, A, more intuitive, but B, it runs so much faster. Sometimes between a minute or two and the back end to load the form two a few seconds, specifically because of the feedback from that subset of users that were making these massive forms. But we should always invite opportunities to dialogue with customers and understand those bizarre use cases. The next is Pokey Oak, which means mistake-proof or idiot-proof. How many of you guys have really wanted to say, hey, it's not a bug, it's a feature? Or if you remember, right, if you remember when the iPhone 4 was having reception issues and Steve Jobs famously said, well, they're holding it wrong. There's lots of times we might want to say something like, you're just not supposed to use it that way. We could have said to the customers that have 1,200 form fields, you just shouldn't do it that way. You should make nice small forms, not stress your users out. Or sometimes we can say, man, if the user would just read the documentation, they would know not to do things that way. The idea of Pokey Yoking is to anticipate those users' mistakes. If users are asking you a question, it should be a red flag for you. And I think we forget that a lot. We don't think like that. If users are asking you a question, and if you have to write documentation for a feature, then it should be a red flag that maybe something is not designed as intuitively as it could be. The three main ways to Pokey Yoking product are to anticipate mistakes. Plan on your user breaking something. You just have to plan that that's going to happen. For example, one way that we failed in recent past is we added a new submissions API for Ninja Forms so you could sort your submissions by date. And it had a field to put in your start date and a field to put in your end date. And whenever we used it and tested it, before we pushed it live, everything worked fine. But all of a sudden we had users start messaging us and saying, hey, I'm getting a PHP white page every time I search through your submissions. Why is that happening? What we found out was happening is they had two date fields, begin date and end date, and they would put the later date and begin date and the earlier date and end date. That didn't make sense to us initially when we were first testing the product, but it ended up white-paging that screen. It was a very small code fix, but that's an example of Pokey Yoking your product. Anticipate that the user is going to do something you don't expect like put the end date first. Just plan for that possibility. Your intended use case for your product does not always matter. It is the use case that your customers are using it for that matters. And I'm not saying that you have to support all of those use cases, but you have to plan in a way that your customer is not going to white page because of something that you may have missed. You also need to make decisions, not options, right? That's one of the WordPress philosophies. Make decisions, not options. Sometimes that involves removing user choice. There used to be an option in Ninja Forms where you could check a box and it would not save any submissions to your database. But what we realized is almost nobody uses that feature. Like 99% of users want a record of their submissions. And so we removed that because it was cluttering up the UI. You can still do it through a code snippet, but sometimes choices like that are more appropriate to do through a code snippet than through something in your UI because it may not be something that most users are going to use and if most users aren't going to use it, why would you clutter up all the options that they will use with those kinds of choices? And third, Murphy's Law. You have to anticipate that whatever will go wrong, whatever your users can break will break at some point. One example of this is we have calculation fields where you can automatically total things that are going on in your form for whatever reason. And you can have lots of different calculation fields and we have an option in the fields to include certain fields in the auto calculation. Because of the way calculation is working, because we don't really necessarily want to limit it, we have the option in some calculation fields to include that field in the auto total. I hope I'm making sense at this point. But what would happen is a user would click include this field in the auto total, but the value of the field was the auto total, which would kind of kick off this infinite loop. That wasn't something that we necessarily anticipated would happen because to us it just makes sense if you already have the auto total there, why would you include the total in the total? But if the option is there, your users are going to choose it. So that is the point of pokey-yoking, is taking any of those options out to help your customers have a smooth experience. Lastly, this is a key thing for support, I believe. Solve problems, solve the user's problem, don't solve the question that they asked. Very frequently, those will be the same thing, but sometimes they're not. I love this quote by Henry Ford. He said, if I had asked people what they wanted, they would have said faster horses. And we would be missing a lot of innovation that we see in the world today if Henry Ford had tried to give people what they wanted, or we'd have really fast horses, that could be cool too, I don't know. But it's important to find the root of the user's issue. And one way that they do this in production environments whenever there's variation in the line is they'll ask why. Why did that happen? If a user submits a request to you, it's always important to ask why, and to ask why repeatedly. So for example, if a user says, if a user says you've taken this, hey, this feature isn't working. Well, why isn't this feature working? Look at how the user's using it. Okay, well, why isn't the feature working the way the user wants it to work? Oh, well, it's not using, it was the user wants it to work because it wasn't an intended use case and we didn't plan for that. Why didn't we plan for that? We didn't think users were really gonna do that. Why didn't we think users were gonna do that? Well, because we failed to plan in the beginning or whatever, does that make sense? But if you keep asking why, you can drill down to what the root of a customer's issue is instead of just solving what they ask. And lastly, there's always going to be those users that cause problems and that give us headaches. So I wanna give you a couple of strategies for dealing with those kinds of users. Number one, ask yourself, is the user really the problem? And that can be hard to swallow sometimes, right? Because whatever we have created that we're supporting for this user, that's like our baby, right? And sometimes users can come off really aggressive and say, hey, I'm trying to use your product for this thing and it's not working and you guys have to fix it. And it's really easy for us to either get really defensive or even potentially kind of be a little offensive with them back or off-putting. But I think it's important to realize what we were talking about before. When your user asks you a question, it should be a red flag. At Amazon, they have this training that everyone has to go through and it's really awesome the way that I think it's applicable in so many ways, but it's called attack process is not people. If there's a variation in your process, the first thing you do is say, what's wrong with the process instead of what's wrong with the person? Instead of saying, what is wrong with the user? And I think when we start looking at our products in that way, when we attack the product before we attack the user, that that is the best way for us to innovate towards better user experience. It's also important to be vocally self-critical. Even if a user comes and they're kind of really being a pain and they're being aggressive, sometimes, even if their aggression isn't warranted, it's the best thing to say, you know what, you're right. We didn't document that feature well and I'm really sorry that that happened to you. I'm gonna fix that documentation and I wanna do something for you to help make it right because we had the oversight. What can we do? That's one way to kind of help change that conversation and turn it from something that is aggressive to saying, no, hey, you're totally right, but let me help you now. Now I know what the problem is, but let me help you fix that. You can also refer customers, refer problem users to other areas. One can be documentation. If there's existing documentation for that, you can say, hey, we've written this great article on exactly how to use this feature here. If you check that out, then you should be good. It can also sometimes mean referring them elsewhere. We have users all the time with Ninja Forms who will message and they'll say, hey, I'm trying to make this form and I wanna sell like 10 different products and they're all different clothing products and I want them all to have different sizes and I want them all to have different colors and I need to do all of those variations in like form with a dropdown menu, you know? And that's not a really good use case for that. And I really wanna help those people. I would love them to use Ninja Forms, but sometimes I have to say, you know what? It would really be a much better experience for you and secretly also for me so I don't have to support that use case. If you check that WooCommerce because we know that their software handles this perfectly and matches your use case exactly and you can do almost all of that out of the box without doing any funky tweaking. And then sometimes you just have to fire customers. You just have to fire them. I'm sorry. I heard support talks before. They're like, no, you never do, no. Sometimes you do, sometimes you have to fire them. Sometimes they're very difficult. I had a customer recently, we have an extension that is very large. There are a lot of options, but they're fairly well documented. And he came back again and again and again I submitted like 12 support tickets for issues that the documentation that I linked him the very first time had the answer to. And so finally I had to say, I said, you know, hey, we are really glad that you chose us, but if you're really struggling with using our product, we just wanted to let you know that you can absolutely get a refund and we'll hold anything against you. It's totally fine. We have no problem refunding your product if you wanted to try to find another solution because they kind of got frustrated with us because they thought it was a hard to use product, but really they just hadn't read the documentation. You know, you're just gonna have those users. At Amazon we joked if someone got fired because customer obsession is one of Amazon's top leadership principles. If someone got fired, they were promoted to customer, which I thought was a very fun way of putting it. But yeah, sometimes you just need to fire customers. Sometimes the support burden from that customer is not a sustainable thing. There will be a small number of users that will be the majority of your support. And sometimes it's okay, even if you have to give their money back to say, hey, I just can't support this anymore. This is beyond what we're able to offer. It's not something that's sustainable. Be very nice to them, be very polite. And again, in referring to them elsewhere, you can say, hey, these extra features and stuff that you're trying to do, if you would like someone to help you with that, for example, on our site, we have a list of developers who know Ninja Forms really, really well, and we'll sometimes refer customers to them to do those kinds of weird custom things that they wanna do. But it's totally appropriate sometimes to fire your customer. Some resources that I wanna recommend for you guys, if you would like to look into any of this stuff more, is HelpScout's blog is fantastic. If you are interested in any kind of customer service at all, HelpScout has an awesome resource. Greg Sciotti writes most of their blog posts, and they are amazing. Every time I read them, I'm like, yeah, that's really awesome. I'm gonna use that from now on. I'll link the Amazon leadership principles. I'm gonna tweet these slides right after the presentation, and I'll give you my Twitter in a moment. But I like the Amazon leadership principles because with customer obsession being one of Amazon's primary goals, their leadership principles are all geared towards that. And it's a really quick read, but it's just a really interesting way to look at that through the eyes of a customer service expert. And then the EPA's website actually has a really good section, which I thought was weird, on lean manufacturing methods. If you're just interested in some more of those lean manufacturing methods, like Filaster, Pokey Oak, or any of those things. Again, my name is Zach Skaggs. You guys can reach me on Twitter at WPN Zach, or Zach at WPNinjas, and the product that I'm primarily responsible for supporting is NinjaForms.com. I do have a website, don't go to it. ZachSkaggs.com. ZachSkaggs.com looks like the kind of site that a support person would have because everything on it is broke. Because I'll replicate someone's issue and be like, oh, great, okay, that's broke. But then I'll never fix it, because it's not something I maintain regularly. So that's going to be changed soon. I plan on fixing that up and starting to blog soon, but right now it's a disaster, so I apologize in advance. But thank you guys very much. I hope we were able to instill some knowledge on customer support. Does anybody have any questions? They should have asked that first before I close down. No questions? All right, good. Thanks guys, I appreciate it.