The Most Important Requirement That’s Not in your RFP

Archive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

Quick riddle this week before we dive in:

How do you pay thousands of "tail spend" suppliers at scale without:

Every procurement team I've worked with has some version of this headache.

You've got hundreds (sometimes thousands) of low-value, one-time or infrequent suppliers (Your “Tail Spend”). Each one technically needs a vendor code, bank details, tax information, compliance checks...

For a strategic supplier worth millions a year, that onboarding effort makes sense.

For a $500 one-time purchase? It's a bazooka to kill a fly. 😅

The answer to this riddle?

You stop trying to onboard them all…

Instead, you let a partner handle the onboarding, the buying and the payment on your behalf. You have one supplier record in your ERP. Thousands of suppliers paid behind the scenes. Your finance team doesn't touch any of it.

Our friends at Axiom are launching MarketPay, which does exactly this.

It connects the full tail spend process (buying through payment) end-to-end, integrated directly with your ERP. One supplier record on your side. Thousands of suppliers paid on theirs.

If tail spend gives you nightmares, this is worth a look if only to understand the concept.

Now, onto tonight's main event. A story about how a thorough vendor evaluation process (e.g. RFP)can (and will) still miss something critical... So what are you to do?

The answer tonight.

Onwards!

📰 In this week’s edition:

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

We were weeks away from go-live. Everything was on track.

The functional requirements? Check. Non-functional requirements? Done. The business case? Approved. IT had signed off on privacy assessments, cybersecurity reviews, architecture discussions, the whole nine yards. We followed the playbook. Best practice requirement lists, stakeholder reviews, the works.

Then, in a routine testing conversation with the vendor during deployment, someone asked a simple question:

"How do we connect this to our centralized identity access management (IAM) system?"

Silence.

😬

For the non-technical folks: Identity and Access Management (IAM) is basically how a company controls who gets access to what software without losing their minds…

Think of it as the master keychain for your company’s entire technology stack. Someone joins the company as a category manager? One click and they get access to every system they need, from your ERP to your sourcing tool to your HR system. Someone leaves? One click, access revoked everywhere.

It's the kind of thing you don't think about until it's not there.

And this vendor? They didn't have it.

No centralized IAM support. None. Zero.

Now, for this particular client, that was a massive deal. They manage security and access centrally through an automated process. Their user access management team is tiny by design, because they don't need to manually provision accounts across 200+ applications. The system does it for them.

Without IAM integration, that elegant, automated process suddenly has a manual hole in it. For one application, sure, you can live with it. But the precedent it sets? The operational debt it creates? That's how "small gaps" become big problems over time.

Here's the thing though. This requirement wasn't buried in some obscure corner of the IT architecture document that nobody reads. IAM is pretty standard stuff. It just... slipped through the cracks of a stakeholder-laden procurement process where everyone assumed someone else had covered it.

And that's the point.

You can run the most rigorous, best-practice-driven vendor selection process in the world, and there will still ALWAYS be gaps.

There are easily 2,000 potential functionality requirements for any serious ProcureTech deployment. Your RFP might cover 500 of them. Maybe 800 if you're really thorough. But somewhere in the remaining 1,200, there's a little thing waiting to become a big thing at the worst possible time.

Which brings me to what actually matters...

In that moment, what I know to be true became painfully clear: a vendor's "ability to deliver" and "openness to co-innovate" are what make or break projects.

When we flagged the IAM gap, the vendor didn't flinch. No finger-pointing. No "well, it wasn't in the contract." No escalation theater.

Instead, they said something beautiful:

Issue resolved. Project saved. Relationship strengthened.

Now, I don't want you to imagine the alternative... but I'm going to make you anyway.😅

Escalation meetings. Finger-pointing about "what was in scope." Legal teams getting involved. Project delays. A steering committee that starts questioning the entire initiative. Three months later, a "failed project" that was actually 95% successful but got torpedoed by a login button.

All of this, for 1 of 2,000 potential functionality gaps that could have slipped through anyone's process.

So how do you protect yourself from this possibility?

Not with more requirements. You'll never catch them all…

You protect yourself by picking the right partner.

And that starts way before go-live.

Here's something most people don't factor into their vendor evaluation: your relative importance in the vendor's client portfolio.

In our story, the vendor prioritized the fix because this client mattered to them. They weren't account #4,782 in a sea of enterprise logos. They were a meaningful relationship that the vendor was invested in.

That dynamic isn't accidental. It's strategic.

If you're a mid-market company deploying a platform built for Fortune 50 enterprises, you might get a great tool, but when something breaks (or is missing), you're in line behind 200 other clients with bigger contracts and louder voices.

On the flip side, if you're one of the larger accounts for a growing vendor, you're not just a customer. You're a design partner. Your feedback shapes the roadmap. Your gaps get prioritized. Your calls get returned.

Sometimes the "objectively better" platform is the wrong choice, because you'll never have the leverage to get what you need from it.

This doesn't mean you should always pick the small vendor. But it does mean you should understand where you'll sit in the pecking order, and what that means when (not if) you need something that isn't on the roadmap today.

"Can you provide three client references?"

Every RFP asks this. Every vendor hand-picks their three happiest customers. You schedule the calls, hear glowing reviews, check the box, and move on.

That's not a reference check. That's a testimonial reel.

If you want reference calls that actually protect you, you need to change what you ask, and who you ask about.

First, stop asking references to confirm the vendor is good. Start asking them to describe how the vendor behaves when things get messy. Here are a few questions that have saved me over the years:

These questions tell you more about your future experience than any demo ever will.

Second (and this is the one most people miss entirely): don't just check references at the vendor level. Ask vendors who will actually be staffed on your project (assuming you can respect your start date commitments 😅), and then check references on those specific people by name.

The vendor might have an A-team that closes deals and shows up for implementation kickoffs. But the people doing the day-to-day configuration, the testing, the training? Those are the people who determine whether your project succeeds or fails.

Ask for their names. Then ask the vendor's other clients: "Have you worked with [name]? What was that experience like?"

You'd be surprised how many vendors have never been asked this. And you'd be even more surprised by how much the answers vary depending on who gets assigned to your project.

When it comes down to it, picking software vendors isn't about who has "the best" tool on a feature comparison spreadsheet. ProcureTech success is about partnering with a team of humans who will have your back, be flexible (within reason), and get you to the business outcomes you're actually after.

Features can be compared in a demo. Roadmaps can be shared in a presentation. But the willingness to say "let's figure this out together" instead of "that's not our problem"?

That only shows up when things go sideways.

And things always go sideways.

So next time you're evaluating ProcureTech vendors, sure, run the RFP. Check the boxes. Score the requirements.

But then ask yourself the question that actually matters: When we inevitably discover something we forgot to ask about, what will this vendor do?

That answer is worth more than every line item on your evaluation scorecard combined.