5 Questions to Ask Every Vendor Before You Sign

The contract is signed, your team is excited, and that’s when the new vendor stops returning calls. Why does this happen?

Every bank and credit union has a story about a vendor that went quiet after the sale.

The pitch was polished. The demo was impressive. Someone flew in, shook hands, and made the whole thing feel like the beginning of something meaningful. Then the contract was signed, the implementation happened, and slowly things changed. Support tickets took longer to close. Calls went unreturned. When you asked about a feature that wasn't working the way it was supposed to, you got a workaround instead of a fix. When you asked about what was coming next, you got a roadmap slide that hadn't changed in two years.

Sound familiar? You're not alone. Most technology vendors are built to sell, not to serve. Their incentives are aligned around closing contracts, not around what happens after one is signed. Once you're in the system, you're a renewal conversation, not a relationship.

The good news is that the right questions, asked before you sign, can tell you almost everything you need to know about which kind of vendor you're dealing with.

1. Who will we be talking to 18 months from now?

The sales team that wined and dined you will not be your day-to-day contact. That's fine, but you need to know exactly who will be. Ask to meet them before you sign. Ask how accounts are structured, how many institutions each person manages, and what happens to your relationship when that person leaves.

A vendor with a real partnership model will have a clear answer. They'll introduce you to your point of contact early, and that person will already know something about your institution before the first call. A vendor that can't answer this question cleanly is telling you something important about what comes next.

2. How does our feedback actually influence your product roadmap?

Every vendor will tell you they listen to their customers. Ask them to prove it. How is feedback collected? Who reviews it? Can they point to a specific feature or improvement that came directly from a customer request, and tell you how long it took to get there?

The Federal Reserve has noted that the most effective bank-technology partnerships are ones where the vendor's strategic goals and the institution's goals genuinely align. That alignment doesn't happen by accident. It requires a vendor that sees your success as inseparable from their own and builds product decisions accordingly.

If the answer is a generic "we have a feedback portal," keep asking.

3. What does your support model look like when something goes wrong at 2pm on a Tuesday — not during a crisis, just a regular bad day?

Crisis support is easy to promise. What's harder is consistent, responsive, human support for the everyday friction that slows your team down. A ticket that takes four days to close. A question that bounces between three departments before anyone owns it. A workaround that becomes permanent because no one ever followed up.

Ask specifically: What is your average response time for non-critical issues? Who owns a support ticket from open to close? Is there a human being we can call, or does everything go through a portal?

The answers matter more than the SLA language in your contract.

4. Can we talk to three customers who have been with you for more than three years?

Long-term customers are the proof. If a vendor's relationships consistently end at renewal, there's a reason. If institutions are staying and growing with them over time, that's a signal that something meaningful is happening.

When you talk to those customers, don't just ask if they're happy. Ask whether the vendor has delivered on what was promised at the start. Ask whether they feel heard. Ask whether they'd sign again knowing what they know now. Those conversations will tell you more than any case study or reference sheet ever will.

5. What happens when your product doesn't work for us the way it was supposed to?

This is the question most vendors aren't expecting, and the way they answer it reveals everything. Do they get defensive? Do they immediately shift to contract language? Or do they lean in, take ownership, and tell you exactly how they handle situations where the product falls short of expectations?

A vendor that has never had a customer run into problems either hasn't been around long enough or isn't being honest with you. The goal isn't a perfect track record. It's a partner that responds with accountability and urgency when things don't go as planned, because in a real partnership, your problem is their problem too.

What a Real Partnership Actually Looks Like

The difference between a vendor and a partner shows up in the moments that aren't covered by an SLA.

A vendor responds when something breaks. A partner is invested enough to notice before it does. A vendor delivers what was promised in the contract. A partner asks how the product is actually being used, whether it's solving the right problems, and what needs to change as your institution grows and your customers' expectations shift.

Community banks and credit unions were built on a simple idea: that people deserve to be treated as more than a transaction. That philosophy is what makes these institutions different, and it's what keeps customers coming back for decades.

The vendors you work with should hold themselves to the same standard. Not because it's written in a contract, but because they genuinely believe that your ability to serve your community well depends, in part, on them.

Technology should bring people closer together. When you find a vendor who believes that as deeply as you do, you've found something worth holding onto.