Category Archives: RFX

How Do You Write A Good RFP? Part II: Indirect

This is easy, right? Just about every RFP platform was built to help you do this with templates, pre-built specs, catalog integration, easy supplier discovery, etc. etc. etc.

Wrong. It makes it super easy to assemble a good RFP IF you have the right platform (and most of the platforms out there are NOT the right platform [for you], as we discussed in our classic series on RFX Creation: Kicking You When You are Down), but that’s it.

And before you ask, Gen-AI does NOT fix the problem. In fact, it makes the situation first. What you really, Really, REALLY need to understand about Gen-AI and these public LLMs, is that, as you’re likely not aware (because every vendor using it tries to convince you otherwise), they DO NOT serve up the best of what’s out there. Moreover, they DO NOT even serve up the average of what’s out there, as some of the vendors who claim to be more “enlightened” would have you believe. They serve up the lowest common denominator response to whatever request you make of them. Let me repeat that. THE LOWEST COMMON DENOMINATOR RESPONSE. It’s critical to remember that no matter what label they slap on the technology, it’s still essentially a re-designed multi-layer neural network (that now disassembles a request, works on parts, and then tries to assemble the parts into a whole vs. taking one input and producing one output from a fixed universe) and these are built on probabilistic models that are trained by weighting the variables in the millions of equations. Guess what weights the variables the most? What there is the most of in the training set. Remembering that these LLMs are trained on the internet (as it’s the largest data source available, even though it still isn’t big enough), guess what there is the most of on the internet? Lowest Common Denominator rubbish!

So anyone who sells you an RFP generator built on the latest Gen-AI to help accelerate and improve your RFPs is lying to you about the quality of the result. You’ll produce the RFP faster, and the English might even be better, but the RFP won’t be. A good RFP requires human intelligence at the core, and unless that’s plugged in, it doesn’t matter what “latest and greatest” AI is applied. (Now, it is possible to use LLMs effectively to speed up RFP construction in the assembly process, but it requires the right design, forethought, and human intelligence backing it up. I’m not seeing a lot of that!)

A good RFP for indirect doesn’t go out asking for a bid on a standard catalog item complete with catalog specifications, because if you need something specific, that’s an RFQ for a new contract, possibly with a new supplier. It goes out asking for products of a certain type to meet a need. For example, if you’re an office supply store looking for a new distributor to restock the best selling brand of Dell laptops, you’re looking for a quote, not a proposal. But if you’re in the business of office setup and furnishing, you’re going out to find a vendor who can provide the basics (chairs, desks, board room tables, panel dividers, etc. in a cohesive, modern style) at the best price point that meets the functionality and style requirement for your clientele. You’re asking them to identify the products you should be considering, and the best prices they can get you based on your expected volumes over the next year.

The key in indirect is to specify virtual item descriptions based on intended use and the problem that needs to be addressed (something to sit on, something to print on, something to do word processing on), not actual products, and let the supplier propose the best products to meet your needs at the best price points they can muster. And, more importantly, to let them propose multiple products where a more expensive product might meet the need better than any peer product or a less expensive product might meet enough of the need that there is no reason for the more expensive product.

This last point is key, but even today only a few RFP platforms support the definition of substitute products in response to an RFP or bid request, forcing the supplier to pick one, and eliminating them from business if the price is too high or the product they choose is not the most appropriate one for the potential customer’s need (which they couldn’t know because the customer never specified how or where the product would be used or who would be using it).

If you remember this key point — virtual items not physical products; the best practice advice of specifying the who, what, where, when, why, and how that we covered in our first entry in this series; and avoid over-relying on lowest common denominator Gen-AI, and instead put your human intelligence first, it’s not hard to write a good RFP for indirect, and if you have a proper platform with templates and a process that walks you through this (and assembles all the standard elements of contact info, organizational Ts and Cs, standard and potential suppliers, etc.), it won’t take long either!

How Do You Write A Good RFP? Part I

This is not an easy question because it depends …

It depends on the who, what, where, when, why, and how. And every change to each of these elements changes what is required for a good RFP. While there are general rules you should follow if you want a good RFP, and a good RFP process, as they say, the proof is in the pudding, and you will need to include the right “proof” in the RFP to get served the right “pudding”.

Let’s take these basic questions they teach you in elementary school, which are often forgotten in today’s business world (and, sadly, the media).

Who: needs the product or service you are going out to bid for. This is critical, even if it is an RFP for paper. The paper an office worker needs to stock the printer is not the paper an engineer needs to print out large diagrams is not the paper marketing needs for their glossy brochures. Who needs it can have a big impact on what they need.

What: is the RFP for. More specifically, the focus of the RFP is on what problem needs to be solved or void needs to be filled, not on what is on the market. Specifications should only be as detailed as necessary as it is up to the supplier to identify the best solution they have for you, not up to you to pick something from a catalog you think is appropriate. Even if you need a micro-controller for a new product you’re designing, your focus should be on the integration and processing requirements, not currently existing last-generation catalog items.

When: is the product or service needed. This is critical to define. If you are replacing a software system and it needs to be done before the current contract ends in 12 months, you can’t accept a proposal that will take 24 months, and suppliers need to know this so they can decide up front if they can work within any absolute timeframes or not. If you forecasts are that you will run out of critical parts in 60 days, you can’t accept 90 day delivery times.

Where: is the product or service needed. If you need a physical good in a warehouse outside of Lebanon, Kansas, that is entirely different than needing a good in a warehouse outside Jacksonville, Florida, especially if it’s likely that the good will be imported (on ships). The latter is a short drive from a port, the former is a long drive to more-or-less the geographic center of the USA. Specifying this is critical if you need guaranteed delivery times or people on-site of a specialty not found in the city, or state.

Why: are you going out to market. Unless this is a brand new need, chances are the organization already has a product or service it is using, even if such product or service isn’t that great. Like the who, this puts the context into what is needed, which is not always a pre-existing catalog product or service.

How: will the product or service be used or consumed? This defines the specifications much better for most products (with the exception of components that are needed for a build) much better than any feature/function list you can come up with. In software, BI for executives is NOT the same as BI for finance people which is NOT the same as BI for analysts.

In other words, if the RFP is NOT focussed on the who, what, when, where, why, and how, no matter how extensive it is, what other boxes you tick, or what best practices you follow

(which should include:

  • References Up-Front
  • Core Solution Litmus Test
  • Third-Party Claim Verification
  • Open Book Negotiations
  • End-to-End Total Cost of Ownership Elucidation
  • Open Finals

)

you won’t have a good RFP. Where good will also, as you have figured out, be different for indirect, direct, services, and software (which we have partially addressed in our recent series on Best Practice Vendor Selection for True Multi-Nationals: 2025 Reprise).

We’ll tackle each of these in our future posts at a high level to give you some insight into how to approach the RFP and what to include.

Your RFPs, That Go To the Wrong Vendors, Suck Because CONTEXT MATTERS!

We briefly covered this in our post on how There are No Simple Answers Because CONTEXT MATTERS, but we feel we have to call it out and cover it again in its own post because, over the past few weeks, the doctor has

  • been asked multiple times for a list of the best vendors for X that just need to do A, B, C
  • been told that Gen-AI can help a client write better RFPs (and that he would like to see the new Gen-AI capabilities in the sourcing/procurement/services/contract management application, which, FYI, he wouldn’t)

when the reality is that:

  • there is no way he can give a short list of relevance without understanding at least the
    • company size, geography, and industry
    • existing S2P/ERP ecosystem and maturity
    • primary pain points

    because

    • company size can dictate minimum vendor size; geography presence, language, or cultural skills; and industry key capabilities that a platform will need
    • unless it’s a rip and replace project, the new module/solution will have to play in the existing ecosystem
    • and nothing defines what is needed more than the pain (not a random list of features that the buyer doesn’t really understand and just assumes will solve their problem)
  • as we have repeatedly explained, there is no Artificial Intelligence, Gen-AI is as dumb as a doorknob, and it doesn’t write better RFPs (although it may write better English) — not even close

Now, we really want to dive into this second point.

You can NOT write a good RFP if you don’t know:

  • what your pain points are
  • why you have them (i.e. process, system, and/or data issues)
  • where gaps need to be filled in your current system landscape (and what that landscape is)
  • how advanced your employees are in their TQ (Technical Quotient) and Procurement maturity
  • who will be using it and for what
  • when it is used in workflow-based processes

And, guess what, Gen-AI doesn’t know that, and doesn’t even know how to elicit that. For an RFP builder to be useful, it has to help you gather this. Which means experts need to encode it with methodologies and questions to elicit all this. Only then can Gen-AI LLMs be used to actually construct an RFP in natural language. So if all the vendor has is a nice shiny LLM wrapper, they have nothing useful. Remember that.

How Do You Turbo-Charge Negotiations?

Not that long ago, THE REVELATOR asked some questions around negotiations and how you could turbo-charge them for a better outcome. Of course, the doctor answered because this is becoming an even more important topic given the state of world, and technology, affairs, but its also one that needs a repeat discussion because this topic comes up a lot and the doctor fears that everyone is missing at least one key point.

What does it mean to “turbocharge” negotiations?

How about “what should it mean”. Everyone has their own answer for “what does it mean”, and most aren’t that useful.

Turbocharge should mean to back up with facts (based on organizational data) and market data relevant to every aspect of the negotiation, to go in knowing both what value there is in it for you as well as your BATNA, and the value that it is in for your counterpart, and a best guess at their BATNA.

Without all this insight, you don’t know if you even have a leg to stand on, or how to reach common ground to carry the negotiation forward. Data insight goes much, much, further than a carrot or a stick ever will.

What do you define as being a successful negotiation outcome?

A successful negotiation outcome is a win-win. It’s not a zero-sum win-lose game like a certain world famous infamous author thinks it is … unless, or course, both parties have the exact same collection of goals which they would rank and weight the exact same way, which is astronomically rare. Thus, since the vast majority of the time both parties have their own unique definition of winning, which can have some overlap, both parties can win.

What are your thoughts about AI and the negotiation process?

When it comes to AI and Negotiation, the answer is no, No, NO, ??, ??! Since it’s not true artificial intelligence, you should never, ever, ever let it negotiate as that is letting the system make a decision, vs recommending a decision, which even IBM told all its employees 46 years ago that this is something you should NEVER, EVER do!

To what degree do experience and expertise impact negotiations?

Experience and Expertise both help, but reality is that the results depend more on the differential between the two parties at the table than any scale you might come up with to measure your own. So you want both, but you should always expect to be outmatched, which is why data, facts, and insight are so critical. If you can find that common ground and give up at least some of what the other party truly wants, you have a much better chance of getting something you want and coming out okay.

Bonus Questions

“Are women better at negotiation than men?”

That would, of course, depend on your definition of negotiation and success. I’m inclined to say yes, but if your definition of success is to be a complete a-hole pre, during, and post, well, I’ve seen way more men who excel at that.

“Is AI better at bluffing than humans?”

Regular humans, or sociopaths? Since AI has no feelings, and doesn’t understand truth from lies, depending on how you define bluffing, it can be absolutely great at it … or not.

“Is AI “Genderless”

Not the right question. We know tech is genderless.

The right question is the following: Is AI trained genderless? Usually not as its usually trained on results that were predominantly created and input by men (who make up 75% of STEM). So it’s not genderless and, sometimes, it is very, very biased.

FINAL QUESTION

Is it the technology or how you use it?

It is most definitely how you use the technology, not the technology itself. Heck, you can get good results with a carrot if you are in negotiations with a bunny. 😉

And that technology must be used to get you the data and insights you need to have a good human to human negotiation. No more, no less. Because, at the end of the day, that’s the only way you can turbocharge a negotiation for success!

DEAR ENTERPRISE PROCUREMENT SOFTWARE BUYER: THERE ARE NO FREE RFPs!

This originally published June 29 (2024) and is being reprinted due to how important it is to remember as you enter a new budgetary year and seek out new technology.

This shouldn’t have to be said (again), but apparently it does since Zip has relaunched the FREE RFP madness in Source-to-Pay (that began in 2006 when Procuri first aggressively launched the Sourcing, Supplier Management, Contract Management, and Spend Analysis RFPs) with an RFP that is intake heavy, orchestrate light, process deficient, and, like many RFPs before, completely misses some of the key points when going to market for a technology solution. (Especially since there isn’t a single FREE RFP template from a vendor that isn’t intrinsically weighted towards the vendor’s solution, as it’s always written from the viewpoint of what the vendor believes is important.)

the doctor has extensively written about RFPs and the RFP process here on SI in the past, but, at a high level, a good RFP specifies:

  • your current state,
    it does NOT leave this out leaving the vendor to guess your technical and process maturity
  • what you need the solution to do
    NOT just a list of feature/functions
  • what ecosystem you need the solution to work in
    NOT just a list of protocols or APIs that must be supported
  • where the data will live
    and, if in the solution, how you will access it (for free) for exports and off-(vendor-)site backups, do NOT leave this out
  • what support you need from the vendor
    NOT just whether the vendor offers integration / implementation services and their hourly / project rate
  • any specific services you would like from the vendor
    NOT a list of all services you might want to buy someday
  • what the precise scope of the RFP is if it is part of a larger project
    NOT a blanket request for the vendor to “address what they can”
  • what regulations and laws you are subject to that the vendor must support
    NOT just an extensive list of every standard and protocol you can think of
  • what languages and geographies and time zones you need supported
  • any additional requirements the vendor will need to adhere to based on the regulations you or the vendor would be subject to and additional requirements your organization puts in place
    NOT endless forms of every question you can think of that might never be relevant
  • your goal state,
    it does NOT leave the vendor to guess what you are looking for (note that “goal” defines what you want to achieve, it is up to the vendor to define how they will help you achieve it)
  • what (management) processes you use to work with vendors — and —
  • what collaboration tools you make available to vendors and what your expectations are of them

And it is only created after a current state assessment, goal state specification, and key use-case identification so that it is relatively clear on organization needs and vendors have no excuse to provide a poor response.

Furthermore, a good RFP does NOT contain:

  • requests for features/functions you don’t currently need (but you can ask for a roadmap)
  • specific requests for a certain type of AI/ML/Analytics/Optimization/etc. when you don’t even know what that tech actually does — let the vendor tell you, and then show you, how their tech solves their problem
    (after all, there are almost NO valid uses for Gen-AI in S2P)
  • specific requests on the technology stack, when it doesn’t matter if they use Java or Ruby, host on AWS or Azure, etc.
  • requests for audits (tech, environmental, social welfare, etc.) when you haven’t selected the vendor for an award, pending a successful negotiation
  • requests for service professional resumes when you haven’t selected the vendor for an award that includes professional service, pending a successful negotiation
  • requests for financials, when you haven’t selected the vendor for an award pending a successful negotiation
    (because these last three [3] will scare some vendors off and possibly prevent the best vendor for you from even acknowledging your RFP exists)

And, a good RFP, goes to the right providers! This means that you need to select providers with the right type of solution you need before you issue the RFP, and then only issue to providers that you know offer that type of solution. (You can use analyst reports here if you like to identify potential vendors, but remember these maps cannot be used for solution selection! You will then need to do some basic research to make sure the vendor appears to fit the criteria.)

And if there are a lot of potential providers, you may need to do a RFI — Request for Interest / Intent (to Bid) — where you specify at a high level what the RFP you intend to issue is for, and if you get a lot of positive responses, do an initial call with the providers to confirm not only interest but the solution offered is relevant to your organization. (After all, at the end of the day, as The Revelator is quick to point out, it’s as much about the people behind the technology as the technology itself if you expect to be served by the provider.)

And even if you don’t need to an RFI before the RFP, you should still reach out to the vendors you want to respond, let them know the RFP is coming, and let them know you’ve done your research, believe they are one of the top 5 vendors, and are looking forward to their response. (Otherwise, you might find you don’t get as many responses as you’d hope for as vendors prioritize RFPs that they believe they have a good shot at winning vs. random unexpected RFP requests from unknown companies.)

At the end of the day, if you don’t know:

  • what the main categories of S2P+ solutions are
  • what the typical capabilities of a solution type are, what’s below, average or above
  • who the vendors are
  • how to determine your current state of process maturity (and how that compares to the industry, market, and best-in-class) and what a solution could do for you
  • how to evaluate a vendor’s solution
  • how to evaluate a vendor overall
  • how to write a good RFP that balances core business, tech, and solution requirements to maximize your chances of finding a good vendor for you

and the reality is that you most likely don’t (as less than 10% of Procurement departments are world class, as per Hackett research going back to the 2000s where they also determined the typical journey for an organization to become best-in-class in Procurement was 8 years, and that’s the minimum requirement to write a world-class technology RFP), then you should engage help from an expert to help you craft that RFP, be it an independent consultant or firm that specializes in Procurement transformation.

It is also critically important that the firm you select to help you needs to be neutral (not aligned with one solution provider who refers implementations to them in return for potential customer referrals) and that the firm does not rely on analyst maps either!

If you want help, the doctor has relationships with leading, neutral, firms on both sides of the pond who can help you, and who he will work with to make sure the technology / solution component is precisely what you need to get the right responses from vendors. Simply contact the doctor (at) sourcinginnovation [dot] com if you would like help getting it right.

Simply put, getting help with your technology RFP is the best insurance money you can spend. When you considering that, all in, these solutions will cost seven (7) or eight (8) figures over just a few years, you should be willing to spend 5% to 10% of the initial contract value to make sure you get it right. (Especially when there isn’t a single Private Equity Firm that wouldn’t invest in a technology player without doing a six [6], if not seven [7] figure due diligence first … and sometimes the firm will do this and then walk away! At least in your case, when you work with someone who can identify multiple potential vendors, you’re certain to find one at the end of the day.)