 Okay, so we're going to be talking a little bit about client management. Thank you all for coming to start. My name is Hannah Del Porto, and I am the Chief Operating Officer of the Brick Factory, which is a Drupal development firm in Washington, D.C. So at MozCon last year, they gave the statistic that only about 7% of clients are satisfied with their web development firm. And that obviously really stuck with me because that's incredibly depressing. And I think that the reason that these clients are dissatisfied isn't the code we're giving them. It's not the end product that's the problem. It's more about the relationships that we have with them, sort of the soft skills that are involved in dealing with clients. And so that's what I'm going to focus on. So when I initially started planning this presentation, I made a giant list because that's what I do. I make lists of things. So I wrote down all of the tips and tricks that we use at our firm when we're dealing with clients. But I realized that what has really made our company great at managing clients is a real change in the way that we think about it in our approach. So our company was founded about 25 years ago. A lot of the team have worked together for over a decade, including me. I've worked here for 17 years. I'm older than I look. And it's great that we've worked together for so long. We have a wonderful rapport. We love each other. We're very successful. But we've also developed a lot of habits over time. And we realize that some of the things we were doing, we were doing them a certain way simply because that's always how they've been done. And we hadn't really thought about the why behind it. So over the past about five years, we've really made a concerted effort to rethink every facet of the company. And this has been especially true of our relationships with our clients. And we've decided to focus on what I would call a more humane, reasonable approach to client management. And this has not only ended with us having much stronger, more positive relationships with our clients, but it also makes us feel better about the work that we're doing with them. So one caveat, I'm American, our firm, a lot of our clients are American or Western. So some of what works for us and makes sense for us might not make sense for you and your clients. And that's fine. What I'd really like you guys to take away from this is just the importance of being really intentional with your decisions, with your processes, being open to breaking habits that might not be getting you to where you want to be as a company. So in our approach to client management, we feel that there are three main values that are important. And these are honesty, generosity, and openness. So honesty, not lying to your clients is an excellent start. But a more common application in business tends to be transparency. So you do want to be forthright in all of your communications with your clients, but it's especially helpful in setting expectations both in price and in process. The second is a generosity. And this is with your knowledge and expertise. All of you are experts in what you do, and I know that. I read your blogs, I've seen you mentor, I've seen you present at conferences like this, and all of those are really important contributions to the community. But your clients are a very important audience as well. So I'm going to talk about sharing all of that knowledge that you have with them, educating them on the web development process and what you do. And I think that that's often the foundation of your value to them. And the third one. So this is an openness to the solutions that might not be obvious at first. Conflict avoidance is really natural, it's uncomfortable. And a lot of times you just sort of want to get past that pain point with clients. But I think that it often leads to incremental thinking where you are just trying to find the fastest, easiest solution to kind of get going with a project. We're going to talk about just taking a step back and being receptive to sort of less obvious solutions. These don't have to be groundbreaking, earth-shattering, innovative. It just needs to be thoughtful and considerate of both the client and of yourself, of your internal team. We are going to focus on conflict resolution because it is an important part of client management. But you can really apply this in any situation where you're solving a problem or just trying to improve an outcome. So those are three main values and we're going to talk about how to apply them in your daily life with clients. So being honest, transparency is about setting very clear and realistic expectations. And this applies to all facets of working with your client. But particularly, as I said, in price and process. And this includes your scope, your deliverables, and your timelines. So price transparency, what is your client paying for? We found that using a cost breakdown is really useful, even when it would be very easy and make sense to give them a lump sum. Breaking down the different components of the project not only allows them to prioritize in the event that they need to work within a budget or a timeline. But you're also educating them on web development over time. You are helping them understand what future work with you will cost. And you're making them a better client at the end of the day. Another one is flagging areas that you think will seem overpriced to the client and giving them a rationale. So one area that we found with web dev clients is sort of behind the scenes work. Your clients who aren't familiar with web development may not understand that time is required for code management, research, setting up environments, quality control. You need to explain these parts of the process and why they're adding time to the project. And also iceberg tasks. So tasks where the change might seem really small to the client, but a lot of foundational code is required, explaining to them the work that is needed to get that change made. And also any special circumstances, aspects of their particular site, their tech stack, anything about their use case that will take extra time. Just be really transparent about what is going into their requirements. And on the flip side of this, things that might seem underpriced to them. So with those iceberg tasks that I was talking about, sometimes the next iteration of them, you've already done that foundational code so that the change is really quite quick and easy. And that might lead your clients to question why you had such a high price initially. So explaining that situation to them. And in some cases, you may want to over service clients on purpose. You may be really excited about their project. It's an opportunity for you to try a new technology or to learn something. You might be really excited about their mission or think that it's gonna make a great portfolio piece for you. Which is great, your clients will love getting for your discounted work, but let them know that you're doing that. Not only will they appreciate it, but it means that you're not setting unrealistic expectations for the next time that you guys work together. So price is often the area where we have the most conflict with clients. So you want to be as honest and transparent as you possibly can with them. And if you're going to have it out with them over money, try to do it before you've actually done the work. So process transparency, this is about being upfront about how you work. And it's often your first opportunity to educate your clients, especially those who are new to the web development process. So you do want to explain your development process from the beginning. And how you work isn't the same as how every other firm works. So let them know what your process is as part of your proposal, as part of your introduction to them. What are the phases or steps involved in the work that you're going to be doing together? And this is especially important if there's a review or a beta version. You want to let them know that what you're turning over to them isn't a final product. Also, any tools that you use as a team, are you going to need the client to review in a design app? Are you using a project management tool with them? Are there multiple production environments or code branches? Explain the purpose and the process for all of the tools that they're going to be working with you. Your scope is the number one most important thing, and this is the most important tool for setting expectations with your client. You want to include every single thing you can think of, even if you think it's obvious, even if it's always been part of the scope with every other client you've worked on, even if it's always been part of the scope with that client on past projects. But you also want to talk about exclusions, anything that's not included in the scope. So if you have a redesign that is not going to include parts of the current site or project, anything that was part of the RFP or your initial discussions with that client that then later become not part of the scope of work, and any task where it may not be clear if it's your team or their team that's responsible, so maybe content migration or development. You want, this is, the scope is really for setting expectations and having a reference for the work that you guys are going to do together. Deliverables, this is a little bit less obvious, but you want to name and describe each of them so that the client knows what to expect. Some clients may literally not know what a comp or a wireframe is, so you describe that. Let them know how many of each deliverable, how many templates, wireframes, rounds of edits, review versions, if there's going to be sprints or beta products that you're going to turn over to them. And also let your client know their role in each deliverable. Are you going to need feedback from them, edits, approval? Let them know how they're going to be involved in each step of the process. Timelines, so if you read one of our proposals of the brick factory, it literally says this timeline will be thrown out. We have never seen a nine month, we've never known nine months ahead of time what the launch date is going to be. So we just tell them that, we're like we need to do a discovery process with you. We need to get to know the project better before we can tell you when we can launch it. And so we give them a tentative timeline. We say your project should take about four to five months to build or seven to eight months to build. And we just set those expectations with them and try to be really realistic about what we can deliver. And your clients need deadlines too. If you're waiting on approval from them or you're waiting on edits from them, they need to understand that if they don't supply those in a timely fashion, it can push your deadlines back. And those delays are not necessarily symmetrical. If you may have work booked in after them. So if your client misses a deadline by a week, you may need two more weeks to hit your next deliverable. And while you may not need that time, maybe your team's wide open and you can turn it around no problem. That should be the expectation that you've already set with them. So being straightforward about how you work helps clients know what to expect. And it surfaces any gaps between your work process and theirs or between your work process and previous vendors that they've worked with. So a little story about this. We had a client come to us with a really, really complicated user interface. So we spent a lot of, this is not it. We spent a lot of time in the discovery phase, obviously. And we had really good talks with them. They were really giving us a ton of information about what they were trying to accomplish. And we felt like we were on the same page with them throughout. So we were really surprised when we sent the wires over. And this is the feedback we got. Can the, why is this like not on the, can the site be in color? Can we have our logo on the site? Why can't I click on anything? It is obviously broken. So our design team was obviously like, and you know, the instinct here is to be like, oh, the client is so stupid. They don't know what a wireframe is. But at the end of the day, that is our responsibility to set those expectations with them. We should have explained to them what a wireframe was. You know, what they were going to be looking at and the feedback we were looking for from them at this stage in the process. So not only did we upset the client, they thought we sent a, I mean, I don't even know what they thought we sent to them. But it took us several weeks to just get them back on track and educate them on how we were going to move forward with the project. So this was a huge mistake on our part. So I don't want that to happen to you. We're going to talk about how we could have done better there. So we talked a bit about being honest. The second value is generosity. So clients don't know what you know. If they did, you would be unemployed. And to have a true partnership with your client, you do need to share that knowledge and expertise that you've developed. So break down what is technically involved in a way that they can understand. This not only helps your clients feel involved in the project and have ownership of the project, but it helps them make informed decisions. And at the end of the day, your client does have to make decisions. This is their project. And sometimes they don't know what they're doing. So they can not only ruin the project, but they can ruin your lives. And this took us a long time to figure out. So when you first engage your client, you've provided all of that background about how your team works, right? You gave them that process in your proposal, you outlined how you work, but you can't include every detail in there. And quite frankly, they read it two months ago. So they don't remember everything. So as you're working with them, as you're going through the different phases, reiterate those important points. Remind them of what's coming, what their role's going to be, how you guys are gonna be working together. And it gives them context in the moment. And with new clients, sometimes you don't have that trust build up. Sometimes they don't know that the advice you're giving them is from the perspective of a professional and that you do have reasons that you're making these suggestions. So one thing that helps with this is to be really clear about your reasoning. Walk through your decision-making process and just establish your expertise with them. This helps them feel included again in the process. And it also helps draw out situations where you actually did misunderstand the requirements. You also wanna make sure to talk to people on their level. So some of your clients are completely new to Web Dev. They have no idea what you're talking about. So you need to explain the wireframes. Sometimes your clients have been through this process before they're not technical, but they've done a redesign, they get it. And sometimes clients have expertise in their own right in a facet of design or development. So just get to know them a little bit and make sure you are talking to them at their level. And again, you guys have been through this before. I mean, you've seen, you've made mistakes, you've seen your clients do all kinds of dumb stuff. Take that experience and share it with your current clients and help them avoid those same problems. I also think that presenting your advice as a scenario helps them internalize it a little better to put themselves in those same shoes. So now that we know about educating our clients, we're gonna see that in action. Okay, so this is, hello. Okay, this is not a website, but. So example, we had another client. These guys have been with us for over a decade, like 12, 13 years. And we were doing a really big redesign from them moving from D60 to D8. There were thousands and thousands of nodes. It was a lot of work. We spent a lot of time on this. And this client knows us. They know our process and they're awesome. They're super hands-on. They work with us really well. They give us a lot of feedback. So after months and months of work, we sent over the beta. And we could not believe their feedback. Where is the slider? Like we had on the old sites. The font is too big. We liked it better on the old sites. There's too much scrolling. Can you just make it like the old site? So our team was like. I mean, honestly, we were furious because they had approved wires, comps, reviewed sprints. They had seen everything and agreed to it. I mean, this was a done deal. So we were annoyed. So after we bitched for a little bit, we called them up and we said, guys, the reason we took away the slider is because we looked at the research and only about 1% of people are clicking on there. It's sending them mixed messages about what direction to go in. It's pushing your content down. We did this research, we have this reasoning behind it. And we increase the font size because readers stay on the page longer, it makes things easier to read and take in more information. And that scrolling is to make the site work great on every size screen. And you know what the client said? They're like, okay, great. So we had to change nothing about this site. All we had to do was take a little time and tell them why we made these decisions. So they saw them, they approved them, but they didn't get it. They needed to know that we were making these suggestions as an expert. So that was awesome. And there are lots of situations where we do this work. We do benchmarking, we do AB testing, research, look at best practices, but we don't tell the client that. And giving them that information lets them know that we're not just pulling these suggestions out of thin air. All right. So this brings us to the third facet, which is an openness to creative solutions. So everyday life with your clients is about solving problems. I mean, that's why they hired you. But especially for PMs with multiple clients, the daily grind really wears you down. Sometimes it makes you kind of just say okay because you wanna get it over with or you say no because you don't really wanna deal with it. But to be a great client manager, I think you need to be a little bit more intentional, a little bit more deliberate and take time to really find the best solution for the problem that your client is trying to solve. And again, creative problem solving does not need to be revolutionary. We're just talking about being thoughtful and considering both the needs of your clients and your internal team. And since most overarching client issues are really driven by some fear on their side, we're gonna sort of talk about these as scenarios, as client scenarios. So the first one, the client is scared that you're gonna do whatever you feel like. Here's where the discovery process is really helpful. So I don't know if you guys are familiar with this, but there's a television channel here in the US called Home and Garden Television. And there is a show called Design Star where people basically compete to be like the top interior decorator, like decorating houses and stuff. And I saw this one episode that I will never forget because, so there's three teams competing to design for this married couple who's the client. And each of the three teams interviews the client to sort of find out what their needs are, right? So they can design a space for them. And after that first in the initial interview process, the television show talked to that client couple and they said, so how are you feeling so far about the process? And the client couple was super excited. They said, we are so excited to see what team number two has done. We love talking to them. They asked us all the right questions. They asked us how we're gonna use the space. They asked us about our palette. And I thought to myself, these three teams have done no work whatsoever for this client. But that client is emotionally invested in the success of one particular team because they asked the right questions. Like they already won and they haven't even done anything yet. And that is deeply applicable to the work that we do with clients. Another one is actually listening to them. Don't assume that you know their business and their needs better than they do. It's the client's job to identify problems and it's your job to bring the solutions. And one way to do that is to just sort of rephrase what you think they're saying, to give them an opportunity to clarify and for them to let you know if you didn't understand properly. Your specs and your scope, again, what? A project documentation is also a great way to just reassure the client by giving them a written documentation of what you're going to be accomplishing together. And it's a good reference for them. So they can look back and say exactly what it is that you're going to be delivering. And we found that visual examples are non-existent. They're really helpful, especially for clients who are new to WebDev. Give them a visual to react to. Sometimes the client doesn't even have the vocabulary to have these discussions with you. So give them a reference point to even start talking to you about these decisions. Oh, my. Okay, cool. So even if you're not agile, finding a way to loop your client in on your progress, doing just client reviews, sprints, some way for them to look at the work as you're going, it reassures them that you are building what they expect. So the second one, the client is scared that you're just gonna disappear. One thing that we found that is really reassuring for clients is to have that single point of contact, to have that consistent client manager so that the client feels like they have an advocate on your team, that they have somebody who's looking out for their interests. And your client has no idea what you're doing over there. So sometimes taking like two minutes and giving them a mid-deliverable status update just lets, it's very reassuring, especially for clients who are small, new, skittish, or hanging on every step of the process, just let them know that things are on track. And quite frankly, even if your client completely forgot that you exist, I think it still wins you points. Also having a check-in schedule, so depending on what point you are in the process, how often you need to talk to them, but also telling them upfront how often you expect to communicate with them lets them know what your version of normal is. And for larger projects, having some sort of hours burned down or status dashboard, project management software, some place where your clients can check on the status of the project without necessarily needing to talk to you every time about it. So another one is the client's scared that what you make is not gonna work. The first one is, again, educating them. So letting them know what you're doing to ensure that their project will work. What hosting and technology you're using, what security do you have in place, how are you doing monitoring, what is your SLA, your quality control process, let them know that you have thought all of this through, that you are a professional company and this is what you're doing to make sure that their project, their site, is functional. And also educating clients on how sites get broken. A lot of people don't understand this. We need to have time for quality control. We need to plan deployments, updating your CMS, great idea. And sometimes limiting access to the site. Maybe not everybody on the client side needs to be able to make modifications. Perception is a really important part as well. So sometimes you hand over code to a client and they think it's broken because they don't know how it's supposed to work. So making sure that they know what the expected functionality is. And also if you have a work in progress, a staging site or a place for your client to review without seeing work in progress is really useful so that they don't think things are broken when they're being worked on. And if you provide bug fix after launch, let them know that ahead of time so that they know you will cover any issues that come up after deployment. And likewise, if you offer maintenance contracts, let them know that as well. Like, let them know that you have a vested interest in the success of their project and you will be providing them support afterwards. I think this is the one where we have the most issues. So the client is basically scared that there's gonna be unexpected costs. Can you guys even read? I don't know why this is not fitting on here, sorry. So this is another one where your very detailed scope is going to lay down exactly what work they're going to get for the price that you guys agreed on. So this one may seem obvious, but I see people break this all the time. And especially in situations where you already have an agreement with a client, you already have an agreed upon overage rate. So you know for sure if you do extra hours, you're gonna charge them X per hour. And your client sends you an email and they say, this is like a life or death, we need this right now. It's really tempting to just do the work because you know you're covered, you have a contract with them. But I really think it's worth it to just shoot an email back or pick up the phone and just be like, just so you guys know, this is going on your overage rate, this is how we're gonna handle that, or if it's a, if you guys need to talk scope again or you need to talk separate contract, letting them know how it's going to be billed. Even when you're right, even when you have a contract and you're following the rules, sometimes clients really feel ambushed if they're just, you know, they just weren't expecting it. So just take those couple of minutes and make sure that you guys are both on the same page. And when locking down the budget is risky, don't. You know, ask for discovery or research time. Tell the clients, we have no idea on earth how long this is gonna take. You know, we need three hours or 10 hours or whatever to even look into it, and then we'll let you know. And sometimes that's not enough. You know, sometimes we have to go back to clients and say, we spent three hours, it's a total rack, we need 10 more hours, and then we'll come to you with a budget and timeline. This is really useful for troubleshooting or maybe working with code that is not yours. And it sets clear reasonable expectations with the client while also not locking you into a situation where you blow through your estimate. And sometimes when you have a lot of out-of-scope work with a client, it can be useful just to flag that and separate it from your initial scope of work. So doing like a loop-backs list or a phase two of the project and just completely separating out that budget and timeline so that you can keep things really clear on that initial project. So sometimes you do everything right. You were honest with your client from the beginning. You set reasonable expectations. You were generous with them. You shared all of your knowledge and expertise. You solved their problems with creative solutions. But no relationship is perfect and sometimes you still end up throwing down with them. So we're going to apply those same three principles, honesty, generosity and openness to managing relationships that are already in trouble. So the first one being honest, you wanna jump in front of bad news. Sometimes sitting on information is actually worse than the actual problem. So admitting that there's a problem and if you can proactively offering a solution. Also give your client an opportunity to be understanding. I mean, there are people too and sometimes if you just come clean with them and say what happened, they completely understand. Also, you know, be candid about your feelings. Like sometimes you or the client have made a mistake or one of you is being unreasonable and just taking a minute to have a conversation about it to actually bring it out in the open and go over it gets you past that problem and the rest of the project can be a lot smoother. Obviously, obviously you wanna bring your experience into resolving conflict. All of that, you know, all of that experience that you guys have on other projects dealing with other clients. Use that to give them solutions. Use that to offer explanations of how you can solve these. And if you can't or you won't do what the client's asking, just take a little bit of time to explain the underlying issues. And sometimes it can help to come up with an alternative. So I'm sure this doesn't happen to you guys but occasionally clients come to us with unreasonable timelines. And instead of just being like, no, we can't redesign your website by next week. We say, well, what are you actually trying to accomplish? You know, do you have an event? Is there a campaign that you're launching? You know, what can we do to solve your problem right now through building you a micro, a landing page, solving your problem in the moment without putting our team in an unreasonable delivery situation. And being open. So try to be flexible with your clients and accommodate, you know, small unexpected needs but do let them know clearly and immediately if you don't feel that a request is reasonable. And some relationships with clients are genuinely negative and sometimes even abusive. And not every client is for you and that's okay. So in situations like that where you're really not working together, your process isn't working, your personalities aren't working, think about a way to get out of that. So that might mean helping them find another vendor to take over. It might mean finishing out your current project with them and then not continuing to take work from them. But doing good work and being successful at this means being respectful of yourself and your team as well as of your client needs. And also sometimes you just need to let things go. So think about how the conflict will affect your relationship with a client and who the client is to you. And sometimes it is better just to let small things go and even when you're right. All right, so, you know, whether you're getting to know a client for the first time or working through an already troubled relationship, try to be as honest and transparent as you can to set clear, reasonable expectations with them. And treat your client as a partner by sharing your knowledge and educating them on the work that you're doing together. And both with everyday challenges and when you get into real conflicts with clients, take a moment and really think about ways that you can solve the problem where both you and the client end up happy. And everyone wins. Thank you so much. Thank you. So I left a load of time for questions cause clients. So what do you guys wanna talk about? You do have to go up to the mic cause they're recording the session. So I had a question on what you call the overage approval. So do you have someone in your proposal like how you're gonna handle overages? We do. Yeah, we talk to clients about that from the beginning of our relationship and normally it's an hourly rate but it sort of depends on the work that we're doing. So if it's a small thing, we just run over hours and we charge them hourly. And like I said, we always let them know before that happens. We say you are at the end of your scope, these changes will be out of scope. We will charge you hourly this rate that we already agreed on. If it's more involved than that, we will separate it into another project. And that can sort of, like I said, keep the timeline and the scope more clear. On your freelance, my question is regarding sort of technical infrastructure for project management. What do you do about clients who refuse to work with you with your ticketing system and any sort of like workflows or anything that you have implemented sort of manage that process? Okay, so we have not had a lot of problems with that for the most part our clients go with the flow. We did recently have one and we are, we're babing them. I'm not gonna lie, we're doing it their way. Okay. So, I mean, Katie, do you have something to add? Like, oh, I like that. Okay, there's an idea. Do what she said. That's a good idea. Thank you. Todd Ziegler, my boss also, do what she said. I'm wondering if you have examples of times you've had to not take on a client because of certain red flags. For example, I'm dealing with somebody right now that wanted me to rework my entire contract, all of it and throw out half of it. And I'm wondering if I should have just said, nevermind, it's been sort of a nightmare ever since. I mean, I can't answer that for you, not knowing the particulars, but we do that all the time. We have a stop go process where we actually have several members of the team on larger projects who give their opinion on several sets of criteria. So, you sort of say, is this person a match with us? Do we think we have the skills? Can we turn this around? Is it someone we want to work with? Does the budget work? And so, we actually give numbers for each of those. And so, several people on the team do it and we sort of look at the average and then decide whether or not to take the client. But that note, not every client is your client, for sure. And there's the sort of, there's the number side of it, like looking at whether that their budget is going to cover all of the pain and suffering that they're asking you to go through. And there's a gut part of it, too. If they seem crazy, maybe you don't want a part of that. I'm gonna do two questions since there's no one behind me. So, my first question is, currently, our process doesn't include having our clients actually integrated into the process itself, in the tickets or what have you, but I've been in a couple of these seminars or these sessions and they've talked about that. It sounds like maybe your team has some experience in terms of that integration process and we're looking at that and what is your advice to avoid the pitfalls that might come from bringing in your clients into your actual process as you're going? Do you have any specific, we have not really had big problems with that. The only thing I would say is that we are very careful, obviously, to keep our internal communication separate from our client communication, so that's a big one. Yeah, I guess that's where I'm sort of coming from. If you're including them on tickets, there was one session where they were talking about actually bringing them into JIRA and actually including them on tickets itself. We don't do that. We have a totally separate, what's up, oh. Yeah, come on up here. Microphone it though. Here, yeah. You guys can do a duet. Hi, my name's Olivia. I work at ZivTech as a project manager and we use JIRA and we have some clients participating in JIRA projects and some clients not participating in JIRA. And so the clients that do participate in JIRA, the developers can see work logs so they can see the comments and so we tell the developers that the client is in JIRA and those need to be work appropriate. All of that stuff is kept separate if there's anything internal communication it's kept in hip chat or in Slack somewhere else separate from the client. And we set up specific client guest roles. So they're only allowed to do certain things. So they're not usually allowed to move a ticket through the workflow. Yeah, that would be bad. Yeah, but you can set those up very discreetly in JIRA. And they're also usually not allowed to see other people's projects. Is the other one? Good one. We have one client that has two separate types of guest roles. So we have one client who where the product owner is allowed to move things through the workflow but the stakeholders are not. But they are allowed to see what tickets are where. They're allowed to comment on tickets and add and contribute that way. But they're not allowed to move anything around or mess anything up. But they are allowed to see what's happening and where everything is. So you've gotten included in this branch too, that? Yeah, we do. What do you have? You haven't implemented that, but you. You helped us plug in for JIRA. Your developers can make internal comments to each other with client window receipt. Gotcha, cool. Microphone, microphone, I cannot hear you. You're so far away. I'm on the client side and we're in on the tickets and we can reprioritize things and that kind of thing. So it's very transparent for us and we really like it. And we've been trained a little bit so we don't touch anything we're not supposed to. Cool. That's great. Awesome, thanks. At Acquia we also let our clients in JIRA. I'm curious as to people who don't have your client's in JIRA, how do you UAT? So typically when we're having client's in JIRA we put the tickets through, they go through QA process and then we hand them the UAT to sign off or it shouldn't be closed. So we have like a parallel process. We basically talk to clients about the sort of more superficial part that they, well actually that's not true because we do have a more technical client that we work with directly. So I guess it depends on the client, yeah. But for the ones, some of them we have sort of, we talk about the work sort of on their level and then we have a technical thread where things, the problems are actually getting solved that only the developers are involved and the project manager are involved in. And so those things are very separate and the project manager sees both the client side and the developer side. But we do have a more technical client that gets things where we work directly with them. Hi, I just wanna go back to the original question. We don't actually use JIRA but we do use another project management system called MavenLink and in that, we do have all of our clients on the projects but we have private messages. So every single task can actually have a private message that your entire company can see but the client won't. So that way, yeah, it's just a private comment on that specific task. So as a project manager, we can do some internal QA, put something up, have our designer put something up, send a private message and tag just our team members. The client has no idea but when I go back, I can see client messages and my developer messages and I'm not checking five different things. So I don't know if JIRA has something like that with private messages but MavenLink definitely does and I like it as a project. Yeah, so you may need to check out different software options and see what sort of makes sense for you. Hey, yeah. Hey, nice shirt. Thank you, I like it. I was just gonna add to the conversation. Oh, we've had a lot of experience, a lot of success doing kind of a similar approach. Oh, we don't use JIRA but we have a similar kind of bug tracking software but we, there's a lot of love, hate relationship with Basecamp around so but we've had great success having Basecamp being kind of like the client facing side of the project and really like, you know, do to-dos, we'll assign work to the client, we'll set meetings to all the recaps in Basecamp and then all of the developer or even designer facing items go into our case tracking system. Yeah, that's how we've been doing it as well. Yeah, yeah, it's kind of like, it's two sides so you as a project manager basically have to balance between the two. But it helps you kind of like, you know, you- Segregate things. You're kind of like making sure the client's happy on one side and they're only seeing the communication that they need to see and that the team has all the other two set up so I just wanna offer that up. Cool. Hello, it's you again. Hi, hi. So with all these people that have this experience, you had talked about earlier about that client integration, like when you're first putting together your proposal and the tools. So when you did this, did you talk through their workflows on their end? How that process works on their side? Like how they work through- Absolutely, I mean that is one of the most important things because we try to the extent possible to not force our clients into a workflow that doesn't work for them. So that is something that we talk about and I mean we have entire teams, we have a structure internally to how we work and so there's only so much flexibility we can give them but we talk to them and if it's something that doesn't cost us anything to make adjustments to make it easier for them, we absolutely do that. It's a conversation for sure. Okay, thank you. Anybody else who doesn't wanna talk about projects management software, anything? Really nobody with estimates or overages, your clients are all nice, can I have their phone numbers? All right, I'll jump in for you there. So we do some complex projects and oftentimes the client will not have a product manager on their side who can really make those good business decisions when we try to set them up as best we can but do you guys have people that fill that role on your side where you will sort of consult on a product and make those decisions for them in a sense? I mean we do do that if the client doesn't have the internal knowledge, absolutely but we still have to get information from them because frankly the likelihood is they're working on a business we don't understand so there still needs to be a process where we talk to them and get information from them and make sure that we're making good decisions for them but of course it's our job to consult for them, it's our job to make sure that they're making the best decisions possible for their company for whatever it is they're trying to accomplish and in our case it's a lot of nonprofits so there does tend to be, at nonprofits a lot of times people are wearing a lot of hats, they have a little knowledge in a lot of areas so they do need a lot of extra help there and we love that, we love helping them with that and we care about their mission so it's something that we enjoy doing and we do a lot. You try to include that anticipated consulting time in the original contract? Absolutely, yeah and you can tell based on the RFP how that's gonna happen. Sure, well thank you. Yep. Hi. Hi, yeah. What is your polite way of telling a client or the way that you deal with a client that constantly changes what he asks for? I mean, I've never heard of that before. Yeah, so we, we try to be pretty accommodating with people, in fact my boss is sitting right in front of you and he's always like, we don't nickel and dime people, like just, you know, if it's easy and we can make them happy, we just do it but we do try to set boundaries from the beginning. We say, we are going to turn whatever over to you, you can give us two rounds of edits, they have to be consolidated, we need to see them in written form so that we can discuss them and make sure we understand what you're saying and then after that, we're gonna be in an out of scope situation where we'll be doing the hourly overage or if this is catastrophic and we need to start over, we'll need a new scope. We try to be, we try to set those expectations before we start working with them so that they know what's coming and so that they feel like we're being fair with them and I think that's really important and honestly we try to be fair with them so. And if you didn't do that beforehand? We, ah. We do, we do occasionally, yeah. And you're going back and forward and back and forward. So it depends, if it's small, we will just eat it, we'll just do it, we'll be like, that was our mistake, we will just suck it up and make it. If, but next time, yeah, people are getting yelled at but if it's a really big one, we will try to talk to them and be like, look, we just don't think this is reasonable, we got this far in the work, we agreed to this point, what you're asking is really a total rework or it's not realistic for whatever reason and what I said here in this presentation, this is real, this isn't like some marketing stuff. We really try to be very direct with clients and very open with them and we treat them like real people, we act like real people and that goes a really long way. It really does. So just be honest with them about what you can do and what's reasonable for you. So one of my favorite interactions with a client is when we have given them advice and they decide to not take it. Oh yeah. Sometimes for budget reasons, for completely understandable reasons. But my question for you is, when it's a serious problem like a security issue, what's your favorite way of telling a client that they're going against your advice? Again, we're just really clear about it. So we do, I mean, that comes up and we just document it. We say, look, these are the ramifications of this decision that you're making and we understand why you're doing it but these are the reasons that we think it's important and in that situation, there are very clear consequences to those actions and we do try to scare them a little bit on the security one. Like we did have a site that we didn't host get hacked and we were like, look at this, look what happened to them. It took them months to unravel this total disaster because they didn't update their CMS. So a little scare tactic, not a terrible idea. What do you do when they still say we're not doing that? So it depends. Is it something that you feel really strongly about and you don't wanna work with these people because they're making a terrible situation for you? Sometimes that's true. It's okay for you to not wanna work with them. Just be clear about that. Their process doesn't work for you. If you still like them, awesome. Find them another vendor to work with. If you hate their guts, be like Anne Seen. I sort of have a follow-up question to my original question. If you do need to end a relationship with a client and fire them or whoever you wanna say it, how would you go about that and would you kind of write yourself an escape plan into your original contract? We have that. That's pretty typical for you to have an out clause. Or as I believe it's like 30 days notice. Like if we're out of this, we will say in 30 days from now we don't work with you. Here's all the stuff we've made that you now own. If we need to return money, so be it. We, again, try to be really reasonable with people. And we would never put a client in a situation where they were in really big trouble over that. We would never drop a project like right before launch. And it's a conversation. And we would have tried very hard to work things out before it came to that. So the client would already know multiple times that we had a problem. It wouldn't be like a surprise. I don't recommend that. But again, if it's not working out for you, that's okay, there are other clients. And those people are probably going to be happier working with someone else as well. Thank you. Sure. Very small question. I know this probably depends on the client, but what is the reasonable time for answering when they call you for something? I don't know how busy are you? We try to do it, so we try to do, it depends on how urgent the thing is, right? So if they send you something critical, we respond right away, even if there's nothing we can do about it. We're like, we saw this. We cannot help you because of this. This is what you need to do. Or we saw this, we're working on it, but we have no idea what's going on. But we just let them know that it is registered on our side that there's a problem. For things that are not for run of the mill, we respond when we see it. Again, we see this, we're on it. And then we'll get back to them with the timeline or whatever it is they need. For us, we try to turn everything around in 24 hours with some sort of response that we're on this. Hi. Hi. So when you're working with someone who is not the most technically literate, what are three tools or resources or methods that you will use to help them to get on the same page? Whether that's like training videos, writing them guides, using like graphics and visual representation, just what are some good ways to kind of help them get with the program and actually be able to work with something whether they want to or not? So I would say the project manager, the client manager is the number one resource because they've been through this already and they know how to explain things non-technically. And while they are technical, they're not developers. So to some extent in their own mind, they've already translated very technical concepts into non-technical ones. So they are very good at explaining to clients in a non-technical way what it is we're talking about. Another one are visual examples, as I said. So that could be sort of mock-ups from internal projects that we use where we're like, when we made our website, this is what we made and so this is how this works to help them sort of visualize what it is we're going to be doing with them. And number three, what's the third one? Oh, Katie, go. Go to the microphone, go faster. Gave us, because Drupal updates are very hard to explain to clients why they need to do it. They just look at it like, well, my site isn't any different. So we like to use metaphors from their everyday life. So we explained that Drupal updates are like an oil change. You don't have to do it right now, but if you ignore it for a year, you're going to be in trouble. You wrote that. I love it when people quote me. So you mentioned something about overages before and wanting to alert the client. When you guys have maintenance contracts, do you have a number of hours where it's like, if it's over X, we got to do a change order? Yeah. What is that number? It depends on the client. So we have a minimum, right? Microphone, microphone. Like we don't do all of our retainer relationships if we're doing an hourly situation, it's like we have to buy a minimum of like 20 hours of support. And then we also try to fix our cost on the Drupal maintenance. So it's like X amount a month and we'll do kind of critical security updates and software updates once every quarter or something. And just try to fix that fee so we're not constantly having to ask them to pay for, you know, for the updates. So it's like a block of 28 hours? So the kind of, we try to separate hosting and maintenance, have that be kind of a fixed fee where they pay an X amount and we just do it. And then kind of have the ongoing development design be chunks of hours they buy with an overdrate if they go over, basically. But yeah, we do blend it, right? Yeah, we do blend it. Yeah. And I think that's been easier too. We used to do it based on team and it was just, it's hard to, you'd spend a lot of admin time just keeping track of it. So that's what we get. Woo! Anybody else? All right, well have a good rest of your day. Thank you very much for coming. Thank you.