 So today we're going to be talking about relationship advice and how to get more out of your technology partner. And so I'm Jenna Dillet. This is my contact information, also with Square. And the way I like to describe myself is that I like people and I happen to work with software. And I think that really is a true summary of who I am professionally and how I show up to the work and why the focus of this is about relationship advice, which when we think about contracts and vendors and consultants and just everybody who we work with as part of the organizations we're in, but at the end of the day, those are all people and we have relationships with people. And even if it's bad, it's still a relationship. Relationship is neither a positive nor a negative. It is just something that does exist. And this is about having better relationships with every vendor, individual organization that you're working with in order to live out your mission. We do have a smaller group today. I will be monitoring chats. I welcome everybody to put in their questions or their comments in real time. I'll try to stay on top of that and then happy to adjust or modify this presentation in response to the specific questions or comments that folks may have as we go through the content. And so just a little bit about Square before I jump into the content of the presentation, as Mark already mentioned a little bit, we are a technology company. Our vision and purpose is that we help others and we do that by providing strategy consultation, website hosting system development and ongoing support. These are a variety of the software that we work in and you can learn more by visiting our website at square.com. Our specific focus is on the nonprofit sector and we also work a lot with membership associations and university systems. And so even though organizations may look really different in terms of what their mission or focus or audience community is that they work with, at the end of the day, they're likely tracking first name and last name and email address and have email groups and events and so they may do a lot of the same things even if that force has a different purpose out in the community. And that means that those systems that they operate their organizations from can have a lot of similarities. So that's the joy that we get is working with all kinds of different organizations and being specialized in a certain set of software to then build out those mission critical tools that they use on a day-to-day basis. So more interesting to me is who are you and why are you here? Maybe you are currently flying solo and you are managing everything in-house that your organization has from a technology perspective or maybe you were in a bad relationship with a technology partner and you'd just gone out or you need to get out or maybe you're satisfied, it's good enough but you think your relationship with your technology vendors could be better or you have seen it all and you should be the one presenting this. So I imagine that we have a blend within who's attending today that represents all those different experiences and hopefully there'll be a little something for each of you that you can take back to your organization to get more from the relationships that you already have or make sure you get the most out of relationships you'll have in the future. So why does this topic matter? Number one, money. So vendors, we cost a lot of money sometimes. Technology consultants can typically have a higher rate than what you would necessarily pay someone in-house if you were thinking about individual team members with an hourly rate but also the systems that you're using are mission critical. They are the heart of the organization, all of your donors and their email addresses and your ability to reach out to them in the future to tell them about campaigns and to tell them about changes and new programs and new staff and to celebrate with you on successes. You can only do that if you have data, if you have a hub that people can come to which is often a website. And so these are mission critical systems and tools that are used in and because of that cost money. We're also live animals. We are real people who have emotions and most of us thrive on some level of relationship and having relationships with others. And so at a basic level even going back to my own kind of personal tagline of I like people and I happen to work with software, I think that all of us spend too much of our time at work and talking with others, whether in person or in Zoom without really caring about the quality of those relationships. And so we should care about this topic because we should care about having quality meaningful relationships in our life even if that's with a technology vendor that you only talk to once monthly you should still expect and value the integrity and honesty of that relationship. The other main piece I wanna point out for why this matters is that you do have the power to choose and hopefully you are never in a situation that you feel completely locked in and can't make a change. And one of the reasons and examples I like to give for that is about my sister. This is my sister Tia and my tiny little son who recently turned five at the beginning of this month who is very much not a five year old in this picture that I think is adorable. So my sister is a nurse and when she was in nursing school then she had a professor who would talk about that you should never settle as a nurse that there's so many different kinds of nursing that if you get a job and you don't really like what you're doing then there's some other type of nursing. There's a labor and delivery nurse, there's an ER nurse, there's outpatient care nurse there's all different kinds of nursing and to never settle and I think that there's a really valuable parallel there into technology and the way we work that tech is not just one thing and having an expertise in websites doesn't mean that you know how to set up a sound system in an auditorium, that both of those involve tech systems, one hardware, one software but tech is not just one thing. And most everyone has different kinds of expertise in the example of you don't hire a roofer to be your plumber and software is the same thing. So when you think about your contact management systems or your websites or your event management systems all of those differences also apply. And so making sure that you know what you want so you can hire the right person because as my little comment of no one's a magician except a magician and so being able to expect the right things from the vendor, from the organization that you're talking to. I have some notes here about open source versus proprietary system or out of the box systems versus custom systems. There's lots of difference between different software tools that you can take advantage of. And I know from the many conversations I've had with organizations over the years who are looking for some sort of change within the systems that they have that it can feel overwhelming and it's hard to know where to start. And again, it all comes back to relationship and having relationships with other similar organizations who really like their systems and really like the options that their systems bring to the table for their internal operations. And it's valuable to understand from them what do you like about it? Why do you like it? What are the pain points? What sort of relationship do you have? Can you make those changes yourself if you have questions or do you need to contact someone to make those changes? Because every sort of system the answers to those questions may be very different. And so what you need in your organization is not necessarily the same or should it be the same thing that another organization needs. But the key point is to not feel like you have to settle that if you are frustrated that the big takeaway of this whole presentation will be to say something, ask questions, speak up, contact who your vendor is or rally together an internal conversation so you can make a difference. The first step before you can or hopefully you would even want to evaluate a contract or some sort of agreement with an external technology partner is trying to be as clear as possible internally on figuring it out what it is that you even want. And we think on the tech side, we think about things as what are the functional requirements from a functional perspective? What should the website do? An example of that is contact form. I want to visit a contact form and enter in my first name, last name, email address, my message and I press submit. And I want to get an email in my inbox after I press submit that is the organization thinking me for my question and that they will be back in touch soon. That's an example of functionality that can exist on your website, just a basic contact form. And what are the things that happen when you press submit and what sort of follow up should that person who filled out the form get upon that process? So thinking about what it is that you want and why you want it, being able to step back a little bit and identifying the answer to that question is find moments of excellence within your organization of when that you excelled as a team or you know that you excelled in your work and communication with external partners. What is that ideal organization that you have that vision for and have in sight? And how are the tools that you're looking at either improving or building out? How are those technology tools going to inform and support that journey of your organization be more of that ideal and having more of those moments of excellence in the future? What are the ways that we like to think about that on the technology side is thinking about user stories. And that is in some ways as simple as it sounds. It's that we have all of our organizations we have visitors that come to our websites and check us out and click around and read our about page and read our blog posts. What is the story that we want that user to experience? What is the path that we want them to take through our website and the sort of actions that we want them to take and how we track engagement and what we within our organizations, what we do with that information and data that then they're sharing as part of their journey through our systems. Being able to document out those expectations really from a layman's term from really that user perspective of a person visiting the site, taking actions, engaging with information can set a really clear starting point and really clear expectations, both internally for what you want your technology project to achieve. And it can also provide a very clear picture for your technology partner to be able to understand your expectations and managing expectations is a key part of all relationship cultivation and management. Another point to make is also sharing what you don't like. That could be other websites and specifically pointing out on this specific page. I really hate that this button in green on a red background or I really don't like the size of that font. Knowing what you do like, what you do expect in addition to knowing what you don't like and examples of what you don't like and what you don't want to see all adds to the ability for you internally to manage expectations among your team members and also for your external vendor, your technology partner to better understand your expectations so they can best manage their team in order to develop or support the technology solution that you're really needing for your organization. So the starting point of that is whether you're looking at cleaning up existing relationships, maybe you're new into your role and you've been charged with taking over the technology relationship with your vendor or maybe you're evaluating contracts in order to implement out a new project. It's good to start and know what's what and also who's who. So identify where all the contracts are. Someone in your organization should have and be able to quickly pull up all of the contracts that you have with vendors. If that's not within your responsibilities, it's not your problem. But as a takeaway of this of if you're taking notes or sharing this with other folks internally at your organization, it's valuable to make sure that is being done and that those don't just get lost in an email. That signed contract that comes back to you that doesn't just stay as an attachment to an email that is downloaded, that it's either filed electronically, that it's printed out and put in a folder, whatever that process looks like for you internally, it's important to be able to refer back to those legal contracts that at the end of the day are binding your relationship and what that vendor is responsible for providing to you and what your responsibilities are in that relationship as well. The second is understanding who all the people are and what their positions are. From my perspective on the technology consulting side, I like to have an understanding of our clients and who the key staff are within each of the organizations we work with. So who are the day-to-day users who are using the system? Are they the same people as the decision makers? Are they the same people as the accounts payable? Are they the ones that are signing checks or submitting electronic payments? So how are those roles the same or different? Understanding the people and the position that they have within the agencies you work with can make sure that when you have a question or when you need to follow up on something related to the relationship, you're going to the right person and you're making your ability to have an efficient closure to whatever the question is or the need that you have related to your relationship. You're able to hopefully have that in a much more efficient way than guessing at who you should be asking your question to or taking your concern to. Going back to contracts, the thing that I like to make sure and understand within all the agreements I have and I encourage everybody to make sure they understand before entering a new relationship and what is the breakup process? If you want to make a change and either add in an additional technology partner because you have perhaps a new grant which it sounds like the next TechSoup event will be all focused on writing grants focused to technology development. What does your breakup clause look like? Is it a 30-day notice? Do you have an annual term? A lot of that timing can be really important when you think about how and when you want to schedule new work. So perhaps you're building out a brand new system that's going to replace your existing contact management system. If you have an annual term on your existing contract and if you're wanting to take your new system live and say February, that could mean you're potentially double paying for a relationship for almost 10 months versus if you can understand before you engage in the timeline of a new technology project what your existing contracts and terms are, that can help you time things in such a way that you minimize the potential that you're having to double pay for services when you're only going to have maybe one system live. You don't need to pay for double maintenance on systems, one of which you may not even be using anymore. Another thing to understand of knowing what's what and who's who is understanding the communication norms. A lot of that is about is email the method for how to best get in contact with people. Is there a project management system? Is it important that you always CC certain additional team members even if it's only you and Paula that are always going back and forth in making a decision? Other people maybe need to be in the loop too. So understanding what those communication norms is also helpful in having successful relationships. And the final point I wanna make here is about emergency response. So let's think about your website and if your website goes down and it is just unavailable and you try to access it from your phone and you get an error screen. Whose responsibility is that and what is your vendor's emergency response policy? Are you paying a different rate? Because of that support is your website being down covered in the agreement that you have with them. That's part of a service that they're supposed to guarantee and make available at all time. And the thing with emergencies is that we definitely care about them in the moment when they're happening but having the plan and understanding what we need to do and what our vendors are responsible for providing makes for getting through an emergency situation just that much cleaner and with a little bit less than heart rate still probably high but a little bit more control. All of that inevitably relates to pricing structure. So all of these are likely paid relationships and hence unless you have some just fantastic technology vendor who happens to be a long time supporter of your organization and is volunteering their time. And so when you look at contracts and proposals and especially when you're setting up a new project it's very likely you're comparing apples and oranges. I know that as a technology agency there's a lot of other agencies that work in the exact same software that we do that they also specialize in Drupal development and CVCRM for contact management implementation. They may have a very different pricing structure and support model than what we do. And that's great. That's going back to that you never have to settle if a pricing structure works great for you in one model in comparison to another that's why there's so many businesses out there that then you have the freedom of choice of who you want to work with. So when you think about differences in pricing what initiation fees exist? Is there one time fees that you need to pay or are there deposits that will be on file that you get back upon a certain date or when you end the relationship? Is it retainer based where you pay in a fixed amount for say three months at a time or retainer where you pay the fixed amount the same every single month and that's billed to you or are you just being based being billed based on time spent and how is that time being tracked by the technology vendor? Are there different rates for different team members at the technology vendor or is it one fixed rate that is being charged and then it's just based on the amount of time that's spent? Are there additional add-ons where you pay an extra $500 per month for the following services of XYZ or on an added basis and going back to those emergency situations is there an emergency rate or if there's not an emergency rate what sort of guarantees do you have with responsiveness? Sometimes I think the biggest way and best way for me to run square to run the operations of our company is am I good at email? Can I respond to emails that I get? And so much of that goes to and is an important part of not only ongoing support but especially in an emergency situation how can you get in touch with your vendor? What are the expectations as far as how responsive they are? If you have it in writing in your contract that you should receive a reply within 48 hours 48 business hours and if you do not receive contact back on the request within that 48 hours what do you get for that? What can you do? And a lot of this is about with all of our relationships, accountability and when we put something in writing holding everybody that we are in relationship accountable to that. I'm a big believer in kind of the competitive nature of software development. If for some reason I'm really bad at responding to emails some week that's a problem that I need to address that is not my client's problem. And it's my responsibility of the technology vendor to figure out a way to make that right. And so because of that freedom of choice that you have I think it's really important that we fold all of our relationships accountable to what we have signed to. And if you don't like the language within your agreements if it feels too vague, if it's open-ended if there's not a commitment to a certain amount of response time that you're supposed to be guaranteed or if there's not an articulation about different rates then those are really great questions to ask before you officially sign. That way you can have peace of mind about what you're entering into and can have accountability to know what it is that you're bringing to the table but also what you're expecting from your vendor. So internally there's a lot of buy-in that needs to happen. We talked earlier about how to just figure out even what you want. What are those ideal moments that have happened? Where do you want your organization to go a year from now from where you are currently? And how does your technology system and the changes you wanna see inform and help you move along that path to be where you wanna be? A lot of that is about relationship building the whole purpose of this conversation and you do that by getting buy-in. So even within your internal team who are the stakeholders that are going to be affected by this technology project? Maybe that's different departments or different team members. Maybe it really is about getting community member buy-in and key donors or key constituents who have been with your organization over time. Maybe that's about leadership and having people sign off on budgets which could relate to board approval and board buy-in and the way that they can be ambassadors and the little diagram of the real organizational chart. I'm sure everyone has memories and experiences of when that has not been the easiest to navigate and the kind of internal politics of change can be hard. And my process for doing XYZ works already. Why do we need that to be any different? And so on the technology vendor side a lot of what in my role I look at and try to evaluate is when we enter into a new relationship with an organization and we're building out a brand new system that's going to replace their existing system. It is really valuable for me as the technology vendor to understand how bought-in is everybody at that organization or is it being really led by one person and they may not care that other people are going to be impacted internally or they may have an attitude of, you know what, they can get over it because we're stuck in the 1980s or whatever that approach may be. It's really important for us on the technology side to understand the sort of buy-in and cohesive communication that exists within the organizations we work with because it's not just about technology. The success of technology projects is informed and impacted by how well and what the state of general relationship health is within organizations. And that should be no surprise. Everything is more successful no matter what that is, technology or not if there's better more productive honest communication that happens between people. And that's absolutely the same with technology. And so I think that even taking that temperature of what are the relationships like internally within your organization, understanding that and taking a critical eye to that I think is an important step before signing on and with a technology vendor or renewing contracts. If you're especially going to launch into a significant change that will really inform and develop very different processes for you. This is an example at organization we work with. They have a variety of different departments within their organization. And one of the ways that they have helped structure their relationship with us is by having defined scope of work documents. And that's a way that they can keep their different departments organized and be able to communicate. So we have in writing the expectations of what it is that we are doing with say the marketing team and how that is different than work that we may do with their survey team. They're an organization that collects patient safety data through hospitals all across the country. And so in order to do that, like any organization you have a bunch of different teams working internally. With the SOW structure, what that has allowed them is to have better specific accountability with us related to not only the scope, but also the approved estimate. And so that work then doesn't need to affect any other department's work because they also have their own scopes of work with us. But everyone can have that visual into all the different scopes of work we have in process. And so there's a, I think an understanding that can exist between team members related to how work ends up being prioritized since scopes of work can be worked on simultaneously even if they're governed by different approval processes and different budgets. We've been talking about all these considerations that go into the process of figuring out what it is that you want within your organization, figuring out the sorts of questions that you should be asking in a way that you should be reviewing your proposals and reviewing your contracts in order to hold yourself internally accountable as well as hold your vendor accountable. And so now you've signed the contract and the ink has dried. What are some of those interaction tips? My team knows I love saying a good old timestamp. I love email and I love our project management system because I can see exactly what dates, at what time and who I sent the following information to. If there's ever questions in the future about when something was communicated, having it in writing is always the best and most trusted way to be able to refer back and note. We've all lost emails or we've all had those weeks where we just get behind, that's fine. We're humans and it's unrealistic to have expectations that there's just perfection at all times in terms of responses. At the same time, having accountability and getting things in writing and not making verbal agreements, not leaving things to just a Zoom call. If you have a call with your technology vendor, you make a bunch of decisions within that call. You talk about the timeline within that call. If none of that exists in writing between you as a follow-up after this act, whether that's an email or a scope of work that gets signed or documented within a project management system, for my perspective, it might as well have not happened that it is always a best practice, whether that's you doing it or that's something that your technology vendor is going to take on and commits to providing those recap of, this is what we discussed, these are our next steps. Getting it in writing is another way you can make sure that you and your team are delivering what you're responsible for related to the project and relationship and that your technology vendor is staying on track with what they have committed to. Another thing about getting things in writing is that means that you can loop in others. So maybe it was just you and one person from your technology vendor who were on the call. So just two people. You could have five other people internally that you wanna loop in to let them know how that conversation went. Similarly on their side, it's likely that there's a lot of other people that they may want to loop in on the decisions that were made, the timeline that was established and the next step responsibilities that are to be done. And so just getting a full sense of what's been done, keep those fun relationships, get on the phone, pick up the phone, have your scheduled meetings, but always take the time after that to make sure that when you put it in writing for yourself and for others into the future, clearly what has been decided and agreed to in that moment. We're gonna take a little deep dive quickly about troubleshooting better since this is valuable. And I think I, oh, it's after this next one. So this is an example of an organization that I think has done that really well. So one of our clients is the International Mountain Bicycline Association. And we've changed our process quite a bit with them in communication over time. And for a while, it was really valuable. We actually had two board members that were part of our regular check-in calls that we would have with them. And I think that they did an excellent job of having appropriate engagement. And the reason I say appropriate is because I know that we all probably know of stories and experiences when a board member was involved in something at a much deeper level than maybe they should have been. And in this case, they had specifically engaged and tapped two board members so there could be that buy-in and greater insight at all levels as far as the work that was currently in process, what we are approached to how we were coming to that work, completing that work, and being able to provide feedback from more of that end-user perspective of what the community would want to see based on the technology products that we were working on. And that was really valuable. The way that they did that is that they made sure that the roles and responsibilities within those calls were very clear of who the primary contact that would work with our agency was and what their responsibilities were versus what the board members' responsibilities were on that call. And that kept from there being too much of a muddle but what it did provide is I think a much better level of accountability for both of our teams to make sure that our time together was very focused and therefore the money that was being spent, the investment in that relationship and the consultancy that EMBA was paying square with always focused in the most mission-critical parts of where the organization needed change. So looping to troubleshooting, whether it's about your website or about your contact management system or your event management system, whatever software system it is that you are working with a technology vendor on, when you have problems, there's more helpful ways to communicate about those problems. And if you can do that in a better way, it's likely that you can make the time that your technology vendors spend more efficient. And that starts with just describing the problem that you had in detail. So what were you doing and how did you get there? So what were your starting point when you're on the website and you click this button and then you click this button and then you saw the screen and that's not the screen that you expected to see. So the more that you can give your technology vendors that step one, step two, step three of what your process was to get there can be really valuable for them to, one, understand the issue and then two, hopefully identify what the reason and problem was in order to then three resolve the problem. Another thing that you can do as well is test the same screen from a different browser. So maybe you typically use Safari, you could try the same thing in Chrome or you could look at the site from your phone. I know that I have supported clients in the past that they actually had a whole internet problem. And when they went to their phone and they disabled Wi-Fi from their phone and then they went to the website, then things worked in a way that they expected. And so there's lots of different ways that you can look at and verify for yourself what you're seeing, are you seeing that consistently everywhere or are you only seeing it in one place? And the more details you can share upfront with your vendor will minimize the amount of back and forth that you end up having. Depending on what the issue is that you're seeing is there some sort of timing trends? This is, I don't know why but it's always at 8 30 of the morning that I see this thing happening and it only lasts for 10 minutes. So any information like that depending if that's relevant to something you may experience is also valuable to share with your technology vendor. And what we love is screenshots and direct links to what it is that you are looking at. Statements like it's broken or I couldn't see anything. Those are statements that are really hard for us to know what to do with. And so taking screenshots, sharing the direct URL of the page that was navigated to that has problems, explaining the path of I clicked this and then this is what I saw that really makes our time so much more efficient when we're supporting organizations. I wanted to give another example of another organization we work with and just to give a shout out of what I feel like has been valuable in our work together related to this topic of relationship advice. That's the US Chess Federation that governs all rated play within the United States of Chess. And we undertook a really big technology project with them a few years ago where they had a big custom system that had been built and we were rebuilding a lot of that functionality within open source software. And one of the things that we would do together in that process is try to always stay focused on what I like to think of as like the banners. But if we work so virtually, probably all of us if we think back to big physical banners that might be hung on a wall that are this constant visual reminder to keep us focused on what is most critical. And I think that with that organization what we did well was try to identify some of those most critical components that was needed in their system. And then by staying focused and thinking of those as banners with kind of the most critical deliverables on those banners that we could visualize in our mind as we were implementing, that helped with the user acceptance testing process of them to review and validate the system and that the system functions like they expected that helped us identify and prioritize the order in which we did work. And it also helped protect the budget. I think there's always opportunities to go down rabbit trails when you're doing software development and building out systems that there's always these opportunities of and these nice to haves and it can be hard to tease out what is a nice to have and what is a must. And the more that at least someone on your team is holding that big picture in mind of what is most critical and what at a most basic definition does success look like and success must include the following three things. If you hold on to what those three things are that can be a really valuable way to then measure and grade any new opportunities that come up against. So is that in a category of a must have or is that a nice to have? Because depending on if we think back to the pricing screen and all the different fees involved and all the different pricing models of is it fixed price is it based on time spent? Is there variable rates depending on who is doing the work? The way you approach the nice to have versus the must have can have a significant impact on the cost of your system. And I think that they have done that when we thought about that initial build and the way that has continued to inform our relationship together and inform the way that we spend our time which then has a direct impact on the invoice that they get and money out the door then restricts the other sorts of things that they may be able to do. And so we take responsibility at Square in trying to make sure that we have as my team knows I say a healthy tension we wanna have healthy tension of that accountability that we wanna hold together in the work that we do. So we are spending time in an impactful way and we're keeping focused on what is most mission critical. So next, what are warning signs? How can you tell if you're in a bad relationship but you don't know it? Or if you get a feeling like, I don't know I just don't know what it is about this person every time I get on the call with them. Those little feelings where you can't quite articulate where you're frustrated or concerned. The first one is I have intimate experience with because in a previous organization where I used to work I would find myself using we statements. When I knew that we with me talking in the plural about me, myself and I and there's always going to be some sort of guinea pig every agency I know where we are doing more learning. And in a lot of ways every technology vendor in part is paid by their ability to learn and continue to grow in their skill sets. There's a balance of if you're always the guinea pig is your vendor always having to learn whenever it is that you're asking a question. And if so, are you being priced appropriately because of the amount of guinea pigness if that could be a word that is being undertaken in that relationship and being aware of we statements of is there really a we or you talking from an eye perspective and how much learning is needing to be done. Those don't necessarily mean bad things that can be fine but it should mean that your contracts and your billable rate is maybe reflective of the kind of support that you're getting. Another thing that is very easy to see is responsiveness and that being a warning sign to potentially a shift in relationship. So if you're sending emails and you are not getting a reply for weeks on end that's a problem and that is likely in violation somewhere within your agreement together and within your contracts. You have the ability to follow up on that to pick up the phone to make a phone call to send another email to in some ways demand a different level of responsiveness. Also when you think about your websites when you log in when you think about your contact management systems most systems will have some sort of alerts that can pop up if some sort of security update is needed or because you likely have administrative privileges within your systems you would see more alerts than what a regular user was. Have you started to see those recently? What do those relate to? Those are things that you can ask questions about and have opinions. And so the big takeaway the whole purpose of now 47 minutes in is my request and encouragement of each of you is to have opinions and to share those opinions. And we all interact with online systems all day every day and our interactions in those systems really informs our expectations of our own systems even when we're not aware of it. And so if you really like the way your experience is navigating some other system and you like what that user sign-up process is or you like that checkout process when you go to purchase something or you like the notification language that comes. That's great. That's a great example for you to be able to share with your technology vendor to say, I really like this. How could we incorporate some of these elements into what we do over here? So developed by example, you don't have to come up with a creative idea of your own. Just take examples of what you already like in the systems that you interact with every day because we all have opinions. And the whole point is for us to be able to be more comfortable in sharing those opinions. So this is something I have on my wall at home and it is a quote by John Adams of Let Us Dare to Read Things, Speak and Write. And at the heart of it, that is the relationship vice of any relationship that exists, whether that's with your technology vendor, whether that's with your best friend, with your mom, whoever that is, is I just dare all of you to be more proactive and honest and bold in your communications so you can ask for a different level of accountability whether that's internal accountability to your projects, whether that's accountability with your technology vendor on the scope of work or the billing process or the communication standards that are supposed to be followed, hold people accountable. And that doesn't mean that you're bossy or a bad guy. That means that you are valuing the relationship and a relationship is a two-way street that you're valuing that relationship and you're taking the time to ask for something in a way that is going to help you move your organization in the direction that you know that it should go. So I would love if anybody has any questions to reach out to me directly. If you're interested more in the services of Square, obviously you can check us out. We have about 10 minutes left and so I'd love any questions or comments. I have chat pulled up. So if anybody has any experiences they want to share or any specific questions they want to talk to and talk through now, we have that time. Gina, I've found that we have Salesforce for our nonprofit. And I feel like Salesforce just went, you know what, we have all this great technology. Let's just slap a nonprofit label on it. And it does not really work for what we're trying to do. And so I started looking at different CRMs for our organization. Yeah, and I think the way to tease out, so I'm thinking my immediate thoughts and question I would have for you is when you have identified and you just articulated that it is not working for your organization. That means you know you have pain points and understanding and being able to internally articulate what you want different. Cause it may not always be tangible. You just know that there must be some sort of better option than what you're operating with now. The way that you can specify and in detail articulate what those differences are will help set the expectations so that you don't end up with a fancy sales pitch from someone that isn't actually going to meet those specific needs. And so that can be a really great, even when you think about your proposals, having those specific questions and needs that you have and make them respond to each of those kind of forces an engagement to make sure that the end result is going to be different than what you're currently operating in. We do CRM work all day long. So that is my email address. I would welcome you to reach out if you want to talk about that further. But I think that's a really great example of reflecting on a system you have, seeing the support and yeah, the whole nonprofit label slapped on a suite of services that is provided. What other challenges have folks come across or just surprises? Because a lot of this topic too is based on the fact that you have to dot all the T's and cross the I or whatever we do with letters. When stuff goes bad, it really matters to have things in writing when something takes a turn. And often when things take a turn, it can be a little bit of a surprise and that's hard. So what experiences have folks had on the call that stand out from this topic? I guess for my organization, we're also a nonprofit and we currently are using a software that handles all of our registration feeds. And one thing that we didn't have a good grasp or understanding of was how much of, how much of our total costs that we were bringing in, the software was taking out as far as like their processing fees. So what you shared on really asking those questions is gonna be helpful for us as we move forward to look for another software company. That's great to hear. Those fees in the way that they can add up and that's often in the fine print that is not on the kind of the front page splash of whatever a product is and what it offers. But those are the things that really add up and affects the bottom line of what your overall investment is organizationally within your systems. Yeah, I've seen that a lot. And with our contracts at Square, there are regular changes that I see of, and we don't actually have that in very good writing. And all of that comes from me being asked really good questions by our clients or by prospective clients. And I think that anybody on the business side, which I'm on the business side, it is all of our individual responsibility to respond and react to that because I love that freedom of choice, that example of my sister and when she was in nursing school and the way she's even changed jobs and been a nurse in so many different ways. And I see so much parallel with how that works with technology and that commitment to not settling. And I think if we can hold that and have that as a healthy thing of striving for something that's better, whether that's in our internal operations and the way we fold our team members and our coworkers accountable, you don't have to be someone's boss in order to help hold them accountable to what the relationship is that you have together. So there's a lot there that hopefully applies to the work that each of you are doing. And I'm just grateful for everybody that took the time to join today and glad this will be recorded if you want to share with others within your organization to just pass on some things to keep in mind when you're vetting either existing relationships or new relationships that you may form. Okay, thank you very much, Jenna. Normally, and this is the weird part, I usually ask our presenter to go ahead and be sure and pitch where you are and where you're from one more time so everybody knows. Well, that awkward in this case, but let's go ahead and do that anyhow. Yeah, so hello from Southern Colorado. If you're near the Great Sand Dunes, that's where I hail from. And yeah, I'm with Square and you see my contact information was on the screen. I'll also throw it in chat if anybody has questions and to follow up afterwards to have any additional conversation. And I hope everybody who attended today got some sort of nugget that they can take back to the organization and just have better relationships, whether internal, external and just have better accountability with all the work that you're doing. All right, thank you very much, Jenna. And thank you for everyone who attended. Susanna, did you want to say anything else before we sign off today? No, just thank you to Jenna and thanks Mark for all that you've done for the organization, for the, for TechSoup to connect text to us in the past year. We appreciate you. Thank you again, Jenna, for your presentation today. Thanks everybody for coming and we're excited to see you in January. Right, have a great day all. Thanks. Thank you everyone.