What you'll learn
- Strategic Inquiry Mastery: Learn how to identify potential fintech partners by asking the right questions, ensuring alignment with your bank or credit union's strategic goals and customer needs.
- Demo Diligence: Gain the skills to spot red flags during demos, RFP processes, and initial discussions, helping you avoid pitfalls and choose fintech partnerships that are truly beneficial.
- Problem-Solving Pivot: Discover tactics to shift focus from solution-centric to problem-solving approaches, encouraging a partnership that addresses the core needs of your customers.
Christopher Conway (00:10):
Because a lot of times we go to conferences or we get an ad or an email or something like that that comes to us and says, wow, this thing could totally make sense for us. It is a great solution, it's going to change our world. But if you didn't come into the conference thinking about that, then this is just a new solution to something that wasn't a problem. Or maybe it was, it wasn't. But coming up with a problem first is super critical. And so for us, for this fictitious organization, we needed a workflow as a service of WaaS for our digital banking solution because today the current workflow process is a mixture of automated and manual, and there's a bunch of inefficiencies and things. So this is the problem that we're trying to solve is come up with a WaaS and really what we're trying to do is improve both the backend, so making sure that our efficiencies are gained through it, as well as making sure that we have a very positive customer or member experience. So that's kind of like setting the stage for what we're trying to get to. So where do you go? You typically go to American Bankers WaaScon, right? If you don't know exactly what you need, you might go to a conference to say, let me find out exactly what players are in this space, what kind of technologies are out there. Maybe you went to a conference two or three years ago and they were all talking about low-code, no-code solutions, and now everybody's talking about ai. So you want to get your head wrapped around what that means as far as WaaS solutions. So you go to WaaSCon.
Mark Coleman (01:51):
Alright. When it comes to the actual thing with going to WaaSCom, there's one thing to really, at least in my mind you have to focus on, is that technology really is part of the equation for this here. Technology doesn't solve everything. It is. You have to understand what the actual problem is you're trying to solve and find the technology actually solves that problem for you because you can integrate with many partners, you can integrate with interesting things, but if you just have technology at its core, it doesn't solve anything. It'll solve the fact that you have this new thing, but it doesn't actually solve any member problems or anything like that. So you have to truly focus on the problem itself. Now, let's say you have a problem. Now you understand what the problem is. Do you actually have the problem? Does the problem exist for your bank, for your credit union?
(02:39):
Because just because there's a problem in the industry doesn't mean that your particular segment, your membership, your customers actually have that problem you need to solve. So you have to understand the problem, understand you actually actually have it. And I also like to say in the very end here with this is that a lot of times you get caught up in the shiny objects, the ideas of generative ai. Generative AI is very nice for things, but just because you hear it as a shiny thing doesn't mean that you need that. If you understand what you need, then you actually can focus on finding the right partner and the technology to solve that problem for you.
Christopher Conway (03:19):
And to add onto that a little bit, right? You may fall in love with that shiny object, right? You walk past that vendor booth and you see their solution like, holy crap, that thing's amazing. I really, really want that. But if that's not the biggest problem that you need to solve at your financial solution, then you're barking up the wrong tree at the wrong time. You need to find out what is the big problem that you're trying to solve today and then find the solution to fit that. So some assumptions around this is you need to have alignment between the business unit and the leadership. That is absolutely critical. If a business unit comes to you and says, we need this workflow as a service, this WaaS and leadership is not on board with that,
(04:19):
That we're trying to solve why we're trying to solve it and what are the benefits that we're going to realize out of that so that when we do get to that vendor selection, that partner, it's all going to make sense. You're going to be able to find the right one for you at the right time that's going to fit your needs as a financial institution. And from the vendor's perspective, making sure that you're a good partnership with the organization that wants to see you succeed as well. So then securing that leadership buy-in is a huge part of this. And so yeah, next.
Mark Coleman (04:54):
Alright, now we're going to get into the spot here is kind of the, I would say the most, a comical aspect here a little bit focusing on, so say you have the problem statement, you have the assumptions, you have all the context around this here, and you're actually going to the process of buying something or actually trying to go through a procurement process. So I found this interesting image here. It's like presenting something that's really old and to basically a group that's about something that should be more modern. So thinking about the bad RFP that might come out of this. So say you went through the RFI process, you go to the RFP process right now and you are getting some responses back from the here. What are some flags that kind of would show that's a bad RFP submission for your WaaS you have here?
(05:37):
So even though I talked about technology, but not the only thing, there's clearly an aspect of technology still in play here. For us, giving from an integration technology background, the fact that there's no real technical documentation at all about what the W is to me, it's a huge red flag. If they can't provide that that to you, or they say that, well, maybe not yet, depending if you sign, we can expose the developer portal to you or expose the actual information to you after the fact. That's huge because that's setting a stage up for some really bad potentially bad integrations later on because you learn about it after the fact, after things actually got executed. When it also comes to the actual response back, so say you asked a bunch of questions and everything comes back, well, it depends on what if they can't give you clear, concise information or answers back to you.
(06:30):
That's also means that they might not be mature enough in their process even to understand what their service even does correctly. So it depends is huge for me. There's also times in my personal past where we ask for references. Are there other credit unions? Are there other banks that actually use your service? And sometimes it's lack of no response at all, or they have a difficult time finding someone to be a reference. If your service is so great and your technology is so sound, why do you find it very hard to actually provide a partner that had positive experience with your service? That's something that's critical for me. Or maybe even the fact that I think about you turning in homework, you're turning in something like that and the actual responses to RFPs are delayed or maybe not even existing at all, or they ask after it's closed.
(07:24):
Why is it taking so long for them to provide those answers? They probably don't have those answers readily available to us to actually give confidence that they know what their process, their services actually do. And when it comes to the actual RFI process as well. So say that they have good technical documentation, they have all good answers, they have good references, but there's no internal participation in the whole process. As you know, everyone's kind of very busy at their various institutions, getting everyone together and also reading through the responses, understanding the different things they solve that also can make the whole process almost be a non-starter sometimes, because you might integrate or talk with your audit team. I talk with legal, might talk with others, but if you can't get everyone on the same page, you're also being set up probably for some potentially bumps in the road, maybe even failure down the line.
Christopher Conway (08:20):
So bad RFPs can get bad responses. So what are some things that you look for in the evaluation of that RFP? The criteria itself, you mentioned it earlier, the detailed information on the system. If the vendor cannot provide detailed architecture, detailed designs, schemas access to their API if available, or at least a purview of it, sign an NDA if you need to, but you need access to that kind of stuff because you don't want to be surprised after you've signed the contract and then you get access to it and you're like, oh my gosh, this is a nightmare. How am I ever going to work with this? It doesn't fit with our ecosystem. It doesn't play nice with the things, and we didn't ask the right questions in RFP, so now we're finding out too late. Well, it's too late, right?
(09:18):
Another thing you want to be looking for is can they actually provide evidence of the ROI can they actually prove that whatever it is that they're going to do for you actually has value. If the vendor comes back and says things like, well, we can save you 5% on such and such thing, that seems like a canned response that you're going to tell everybody. Tell me based on my number, ask me questions and say, how many members do you have? How many transactions do you have in a month? The vendors should be asking financial institution just as many questions as we ask them to understand how they can provide the value for you, and they should be able to quantify that really, really easily for you. And that should be evident in the RFP longevity and the resilience of the system itself. Are you the first one to jump on board this new W or hasn't been around for a while and you're the 35th customer? I feel much more comfortable being the 35th than the first. I've been the first on a few and it doesn't go well. You know what I mean? There's always hiccups. You're proving the system out for them along with them. So finding out the longevity of the system itself is super critical.
(10:34):
It's important to realize that not every solution should be evaluated the same way. I mean, it seems intuitive, right? But there are times when you send an RFP, and I was just talking to somebody a little earlier today about a bad RFP that was 72 pages long for something that really should be like $5,000 a month to implement. That's an insane RFP, and there's no way that a vendor is actually going to fill that out. So one of two things. Either the vendor's going to rip it up and say, no thanks, we're not interested. Or you're only going to get responses from very, very expensive vendors. So now you're putting yourself at a disservice because you're only getting responses from the most expensive players. You're not getting feedback from the ones that could probably fit the need, right at a cheaper rate. So if it's 72 pages, chances are that's a boilerplate RFP that they send out.
(11:23):
The first 70 pages are the same to every single thing. And then there's two pages of variance. You need to shorten that up, right? Ask the due diligence questions for sure, but shorten it up so that the core of the RFP itself is the detailed tailored questions to the solution you're trying to find. And so with that, every evaluation is going to be a little bit different. And Mark mentioned it earlier, involving that broad audience in part of the process. If you don't do that, what's going to happen is the business unit says that yes, we need a W is going to have a tailored solution to them, but it's not going to fit potentially other business units. So now you've got a W solution for the marketing team. You've got a W solution for the lending team. You've got a W solution for the combined team. Now you've got three different WA systems and none of 'em play nice. They're all different. They're all documented different. You've got different skills to support it and it's going to be a nightmare. So involving all of your teams early as stakeholders into the process is going to be really important to make sure that you're getting the right solution with the right partner to fit all of your needs and not think so shortsighted.
Mark Coleman (12:35):
So we went through the RFP process, we went through the vendor of evaluation. We found a good partner for this, and now we're actually going to start this up project inception for here. So when it comes to this here is that you have to understand the importance and commitment during the whole process. So when you're actually interacting and doing the selection, they're going to be very committed with you. They're top tier people talking with you to make sure that they are going to get that sale, get that contract signed, and have that commitment of actually basically purchasing the service. That's wonderful to have that commitment upfront, but make sure that after that happens, there's commitment after the contract signed, commitment after the actual inception of the project and the kickoff occurs because having it all on one side means the second side is going to be potentially very hard to move past because if they're not committed to you after that, that's also, it's just going to be difficult overall when it comes to the actual project itself.
(13:46):
Then two, you have to understand basically how they handle their track record of actually turning these services on for your FI. When it comes to turnover rate, there has been times where we go through a project itself and we went through in the past four project managers, six project managers. That's incredibly disruptive to the actual implementation of that solution. They're not committed to your success, which is something that you want to have is to be a true partner. They have to be committed to your success, actually growing your business, making your aspects actually a way to basically have that longevity with them as a trusted partner, not just a vendor for this. So also when it comes to the vendor selection, partner selection, depending what you get, you also might be required to have an integration partner, implementation partner to do this because maybe the W workflows of service is so incredibly large.
(14:50):
Just because you picked your partner for your WaaS offering doesn't mean you just blatantly find the integration partner to do that for you. You have to do the same amount of due diligence from there to make sure that you have the right integration partner to actually turn on the WaaS for your institution. Because if you just find the right vendor, but have a really, I would say poor integration partner, it's also going to set yourself up for failure. So do the same due diligence on both sides of selection and also integration for, and when it comes to actually the project itself, assumptions are going to be something that's going to basically destroy whatever, destroy or make. Basically what comes out of the end of this, if either side doesn't have a clear and concrete understanding about what's going to be delivered during this project being turned on, the value puts out of it. The things are being delivered to your associates, to your customers, to your members. If there's assumptions in there, it's just going to be fraught with difficult times ahead because everyone's on a slightly different page of the book. And having clear understanding allows you to articulate to your leaders, articulate to your stakeholders about what this does. And when it comes to the end of the actual implementation, you understand that you actually hit those goals. You actually basically provided those things back to your stakeholders. And there's a thing that is a benefit to all for us.
Christopher Conway (16:25):
So after the inception of the project, after it's been delivered, you need to think about what's next, right? Every good vendor selection partnership should have a support plan for afterwards. Who's going to support it? How are they going to support it? Is it free of charge? Is it just because they want to be friends with you or is there a cost to it? But having that support after you go live is absolutely critical and it needs to be part of the discussion upfront before you even select the vendor to say, how will you help me support this when this product goes live? What happens if something goes bad? Are you going to help us roll it back? Are you going to help us figure it out? What kind of communications are there for rolling this out? Do you have any kind of boilerplate templates that we could use?
(17:25):
I mean, typically as an FI, you come into it and WaaS is not my space. I don't know much about wa, but the vendors do. That's their bread. That's what they live for. Ideally, they should have plans for how to communicate this out to members. They've worked with 37 other FIS before. It's not new to them, but it's new to us. So hopefully they have some communication plans, some rollout plans. They're the ones coming to us and saying, look, we are the experts in this space. Let us show you how to do this and then let them do that. Build that trust, build that rapport with them to let them do that. And then what are the operational support plans for afterwards? And have those dishonest and frank discussions about what happens if this goes bad, how are we going to roll it back? Is it a one-way street or can we actually turn this thing off and then recoup and then figure out another plan because it's happened, right?
(18:21):
We've all had bad rollouts and you just roll with the punches. But what if you had a better plan, right? So have those discussions upfront with the vendor, be very clear about who's going to do what and when. Put it in a statement of work if you need to. But it's super critical to have those discussions upfront because a lot of times you just think about the product that you want, how much is it going to cost? When can we get it delivered? And the support plan is sort of an afterthought, like, oh yeah, we need to actually support this. Who's going to do that? Do we have the team in place? Do we have a learning plan in place for us to be able to eventually take over the development of the workflows ourselves instead of having the vendor do it for us or the agent partner do it for us? So figuring all of that kind of stuff out upfront is really important for the whole process.
Mark Coleman (19:12):
Alright, so it comes to actually, so getting past the support and say, actually you have long-term success with this to make sure that the fact that you have a good partner picked for the length this year. The port in my mind is the most critical aspect of this year. You want always, I say vendor versus partner. You want to find partners going forward, partners that help your success for this year. And I'm sure you've also worked with various other partners. They're not all kind of created equally. Some are more engaging, some are less engaging, some basically only talk to you when it comes to renewal time. That is almost kind of an aspect. I kind of laugh inside a little bit that they want to talk to you when it's time to have that next sale, extend that contract out. We don't want that. The fis, they need that partner for this year.
(19:59):
And finding ways to ensure that the relationship still is sound for the long term. When it comes to some of our partners, we do QBRs, they're great, we learn more about things, learn about what their future holds on here, but there's other ones that we don't hear anything at all. So baking that into the actual process of going through the contract, you have SLAs or on the fact of how often you meet, how often you actually engage with each other. That should be something that seems almost trivial, but it's also shocking how it doesn't play out with every single partner. For us. And since it's ideally going to be a long-term commitment with the FI and the partner itself, you have to understand that their future matches your actual future. You have particular needs of your membership, of your customers, of what the future holds, talking with them, understanding what their roadmap looks like, what their actual future of that organization looks like to ensure it aligns with where you hope to be going.
(20:58):
If you're in a space where it's like with payments, make sure they're on top of what the most recent payment services are out there. If they kind of have that fall apart and they don't provide any insight or actual development into that particular spot, that's probably a part that you want to find a way to basically change. And that's why I always say about always evaluate this year. You evaluate when it comes into the RFI, you evaluate when it comes to the RFP, you evaluate the success during the project, during the actual launch of the solution, always evaluate these partners to make sure they match your view, your customers, your segment. Because if you don't stay on top of this stuff, you'll get lost. Things will start to crumble because now you want from a partner back to a vendor, and probably a next couple years, someone will look at this system that's been plugged into the ecosystem and say, why is this not delivering us revenue? Well, no one paid attention to it. You plugged it in, you turned it on and it withered and died. You have to pay attention to stuff and constantly evaluate the needs, constantly keep on having the resources associated with it so you actually can have a long-term success.
Christopher Conway (22:13):
All right, almost wrapping up here, key takeaways. So start with a problem. Super critical. If you just go in, find the shiny object and go to implement it, you're not actually solving the problems that you should be. So understand your problem clearly, get everybody involved, involved all of the different business units, all the different stakeholders, at least ask them, Hey, we're looking for a new workflow as a service system. Do you think it could benefit you? If they say no, okay, great. If they say yes, okay, put them as part of the evaluation criteria to understand what it is that you're trying to buy and what are their needs. So you don't end up with five different WA systems. One for each thing.
(23:02):
Conduct a thorough due diligence on your partners. Again, still pretty self-explanatory, but really understand who you are working with. Who are you buying from? What are they like as a partner? Are they going to just sell you this stuff and then wash their hands and be done with you until it's time for renewals? Or are they going to help you along the way? Are they going to meet with you weekly at first or monthly or whatever the cadence is to ensure that you're set up for success, right? Are they coming to you with new ideas? Are they listening to your ideas and saying, Hey, I put this new workflow as a system in place, but it doesn't do all the things. I've got new use cases that I need. Are they going to be willing to listen to you and then put that into their backlog for future development?
(23:48):
And what kind of considerations do they have for that? And so building those relationships, building that rapport is just fundamental to having a good partner because all of these things are expensive. They take time, they take money, and to replace them with something different is just so costly. And so you want to make sure you know who you're getting your business from and are super comfortable with that because the cost of replacing it is just a nightmare. And then finally, make sure you focus on the long-term viability and the support system because the actual implementation is just a short blip of time compared to the entire lifespan of that product or service. So you want to make sure that the long-term support and the viability of the solution is in your favor because everybody looks at the need upfront and then they build it and then they forget about it, and then they just, like Mark said, it withers and dies because nobody's supporting it. Nobody really thinks about it. Now that's in because they're chasing the next shiny object, chasing the next problem, as opposed to doubling down your investments and the things that you've already got. So making sure that you have a very good plan for the support of the solution is very important. So
(25:08):
Questions? Yes, ideas. What did we miss?
Audience Member 1 (25:15):
Hey. Yeah, great presentation by the way. Thanks. The question I have is, when technology is creating consumer behavioral change, how do you attack that as a problem? So for example, we can take gen AI, everyone's thinking about it's causing consumers to think differently and how they do day-to-day activities. Is that a problem that you look to solve? How do you look at that as in your problem strategies?
Mark Coleman (25:38):
So when it comes to things like generative AI, I think it's like a learning curve for every single person on what it means to them. For me, for that relatable thing, I haven't really been hearing anything from our membership about generative AI yet more beyond just the theory behind it. But we're constantly evaluating, is there certain touch points or turning points that might make that a thing that we need to examine in on? But I think what comes with a lot of this here is you need almost expose a survey. I talked about the keynote this morning is expose and educate your members, your customers on some of these things and see if there's ways for them to basically find and sort of grab a hold to 'em and actually do something with them. One of the things I personally would love to do at the cran itself is finding ways to deliver maybe some of those things like I lapse program, a beta program to our membership where we have small, little, tiny technical spikes of interesting things that can be maybe using those services to basically see if members opt into them, see if they explore those things, and pretty much fail fast.
(26:45):
If we try generative AI for transaction searching or whatever it might be, and everyone opts into it and find great success, that's wonderful. Collect some data around there and finding ways of making that happen is using the different areas to basically try things out. But to get to a culture of organization to get to the way of failing is incredibly hard. It's not technology problem anymore. You need to basically build up the culture around the organization and your associates and membership to say that it is okay to try these things out and it's not scary.
Christopher Conway (27:17):
Yeah, I think it's a good question, right? Because sometimes you don't know what the problem is, right? Technologies are advancing every 18 months, it doubles. And so you may not realize that you have a problem, right? Gen AI might be a problem, maybe it's not. And so that that's the chasing the shiny object. Just because gen AI is the big buzzword. Is it a problem for your members? Are they asking for it? Do you know anything? They coming to you saying, Hey, look, I really want to use my natural language to ask questions about my account. Are they doing that or are you trying to solve a problem that doesn't exist just because you have the technology to do that? It depends, right? So it depends on what your members and customers are saying and saying. For Gen ai, maybe you're right. Maybe it is a better chat bot to say, okay, I'm not going to authenticate myself through the chat bot and now I'm going to be able to ask questions about my account or get advice on investment strategies or whatever it is that you're trying to do with your generative ai, making sure that it's siloed to your organization.
(28:22):
I think one of the presenters today was talking about making sure that you're not using the global language, but you're using just your financial institutions language of things. So you really have to listen to your members, listen to your customers to find out what their problems are in order to say, is gen AI a solution to a problem that doesn't exist? Or is it a problem that I don't know about that I need to address because it's coming? Good question. Who else? Anybody? Questions, thoughts, ideas? What did we miss? I am sure there's experts out here as well that have been through a number of vendor selection processes. What did we miss? Oh, hang on. Thank you,
Audience Member 2 (29:09):
Microphone. One thing I wanted to add on to references for vendors, checking them is great, but I always, I've learned recently asking more questions of if they're an investor in that we ran into an issue where they provided another financial institution as a reference, and it turns out they were an investor. So it's not really a reference. So some additional questions into that.
Christopher Conway (29:32):
Yeah, no, great point. And we all know that when you get references from a vendor, it's going to be their absolute best clients. So of course you're going to get glowing reviews of that vendor. So take it with a grain of salt, of course. But great point about that reference also being an investor of that platform. So yeah, good point. Other thoughts? Question? Anything from the vendor's perspectives? What else are you thinking that makes a great partner for a financial institution?
Audience Member 3 (30:06):
Executive sponsorship.
Christopher Conway (30:08):
Executive sponsorship. Yeah, perfect.
Audience Member 4 (30:21):
So also coming from the vendor perspective, I really loved the bullet point about once you get to the point of the primary stakeholders think they've made a selection building a cross-functional team within the organization so that it's not siloed and no one's surprised. And our most successful partnerships are when our primary or executive sponsor who's leading the initiative opens the kimono, so to speak, and introduces you to multiple people so that moving forward, you're mutually successful. So that's a really, really good point.
Christopher Conway (30:55):
Yeah, I can tell you at members first, again, we're just under 8 billion in assets in 450,000 members. I dunno. We have over 465 systems that we utilize for all of our associates for different purposes. And I think what, two years ago we had five different email systems, three different text messaging solutions because collections wanted a text messaging solution. So they went out and bought one, and then marketing wanted text messaging solutions, so they went out and bought one, and then digital banking wanted, so it's mind numbing. So we're in a process of collapsing and converging to more of a platform centric approach to things to reduce the number of vendors, to have one solution that does all these things. And I think it's just a matter of siloed thinking where a business unit comes in with a problem and says, I want to solve this problem, great. But they don't take anybody else's ideas or thoughts or needs into that procurement to find out how else can we use it, and are we getting the best partner for all the different use cases.
Audience Member 5 (32:23):
In the same building? They've worked in the same building for years, and this is the first time that they're ever meeting in person. So having that level of cooperation throughout the organization I think is really important because to your point, we're not devoid of having duplicate services in our own business, so it's annoying to us as well. So having that, hey, you can leverage this tool here, you can leverage it here, you can do that with this and bring some of your ideas to us and maybe we can fit it in here so that you're not overlapping some of those things. I could
Audience Member 6 (33:02):
Too, just to echo that sentiment also, we were talking about siloing. I come from both sides of the space. I come from the FIS for 30 years and now I'm on the vendor side, so I know it very well. Whereas to your point, Chris, that you have, someone wants texting here, here, here, and here. But it kind of goes back to the old adage, did you bring enough for the rest of the class? Why does it make sense to have this here, this here, and this department versus trying to consolidate everything in one place. From a vendor management perspective, it makes more sense and less friction.
Christopher Conway (33:31):
So one of the things that we're doing at Members first is to incorporate it into our project governance so that before anything gets procured, anything gets approved. It goes through governance committee. I think even the keynote this morning was talking about, Hey, I've got this green light to go do this awesome thing in innovate. What's the first thing I do? I bring it to my governance team. It's the same concept. So if you bring it to your governance team, they're going to be able to say, okay, that's great. You want a texting solution. But I also know that this team over here wants a texting solution, and this governance board is made up of a cross-functional team of different business unit leaders from different silos. And so they come to that and say, oh, yeah, we also need that. And so you reduce that duplication as part of the governance process. And not only that, but then they also say, oh, you want to buy a texting solution? We already have one. Go talk to them that department, because they already have one. See if it fits your needs and if it does, great. If not, then go buy something. Right?
Mark Coleman (34:32):
And that'll be truly a balancing act when it comes to governance of the actual intake is you have to have a certain level of control over the governance of what you want to do, but not have so much control in there that causes a roadblock that causes those business units to go outside of the process. Because if they see the thing as being a roadblock of actually getting work done, the business will always move forward. No matter what you put into the business or we're all over any potential process or governance board in place here, they will make their way because the business has to keep on moving. One other thing I was trying to think, I was thinking here also when it comes to the relationship aspect is that from our perspective, we do a lot of information about due diligence of the actual partner understand what they do.
(35:17):
I've also found in the past a lot of times where the actual partner doesn't do any research on the actual person that did the RFP. There's many times where I view members first is that we have a very strong technology team, a very strong development team, incredibly biased, of course, lead up that team. So I think we're amazing. But what ended up happens here is that there's many times where we talk with partners and they know nothing about what we do. They did zero research on the fact that we've built stuff internally ourselves. There's been times where we kind of view that maybe our technology might be better than that partner when it comes to stuff like that. I'm shocked our practices from a credit union that's $8 billion might have better SDLC processes than the partner itself. I looked at them as a way of basically accelerating us, accelerating our time in the market. It shouldn't be other way around. It's a random thought that popped in my head for this.
Christopher Conway (36:19):
All right, we got five minutes left. This is a great discussion. I'm happy to continue. Awesome.
Audience Member 7 (36:27):
Hey, so you talk about accelerating. So one of the things, fintechs, there's a lot of new ones out there, so this is great for those guys that have done 37 implementations or whatever you mentioned, but there are a lot of new ones out there. You could be one of the first. How does that differentiate the plan? And because we've dealt with a couple, and in order to be best in class or to truly differentiate, sometimes you need to take a risk on that, but that process kind of goes out the door a little bit when they don't have references and things like that. So how do you adapt or adjust the plan to a newer FinTech that's just coming to market?
Christopher Conway (37:08):
So I would say, well, it depends, but no, really, if that FinTech can bring something innovative that the others can't or is so cost friendly that it makes sense to take a chance on that FinTech, those are probably some of the considerations that we would take in place to say, look, we're going to be figuring out this with them, and we're going to be the first out the door with this product with them. So it's going to be risky for the financial institution who's putting a lot of eggs in that carton to say, this is something that we feel is a problem that we're trying to solve, and we want to make sure it goes right. So I think it's even more important for that FinTech to have a very, very, very strong relationship with that organization and make sure that it is successful no matter what. We have had tons and tons of implementing partners who want to nickel and dime for every single minor change order that doesn't fit the statement of work, which was super vague to begin with. If you're just starting out, don't be that partner, right? Work hand in hand with the financial institution, figure out what it is that they're trying to need and be an extension of their team as opposed to a vendor as opposed to even a partner be part of that team. I think that's going to get you in the door much more so than not.
Mark Coleman (38:46):
Yeah, I want to echo that immensely as well. The actual vendor partner extension of the team, that's the spot. That's the sweet spot for me specifically. It comes to a technology play, is that if the lines start to get blurred between their backlog and your backlog, you're actually working together in the same potential goal and they help build out things that make your services better, you're going to probably make their product potentially better so they can also find a way of capturing that other client. So it's like that extension aspect is something that resonates very, very closely with me because it's something that it truly is mutual success.
Christopher Conway (39:22):
Yeah, I would also say that I think it's also a bit of a plus for the new guy in the block because we know that you're going to be just as invested in the successful outcome than somebody who you are 35th in line, right? Not to say that the 35th in line wouldn't do a great job, but we know that you're going to be hands-on. Right? So there's that too. Anything else? Yes. No? Nope. Alright. Minute 37 back. Thank you very much everybody. Appreciate your time. Thank you.