As per the many series we have written on this over the years, this is often the hardest RFP to write, because it’s really hard to specify what you need when you don’t understand software, what’s on the market, what it can do, and when it can’t. Especially when you’re inundated daily with marketing about why you need SoftwareSpectacle Version Seven with the latest and greatest self-sealing AI technology to solve all of your function X business processing needs. And then vendor Y comes along with Binary BitBlaster Release Bravo with the new and improved board-based AI-backed BI technology that will do even better!

As we’ve said again and again in our many series on technology selection and RFPs, which include:

• Software Acquisition Insider Tips
• Enterprise Software Buying Guide
• Solution Provider RFX Templates Suck
• RFX Creation: Kicking You When You Are Down
• Best Practice Vendor Selection for True Multi-Nationals: 2025 Reprise

Unless you are a tech expert, you can’t truly know what you want. We’re at the point that even most analysts, especially those who work at the big firms and who need to spend at least half of their time on client advisory to justify their positions, don’t even know half of what’s out there (as evidenced by the maps they publish year after year with the same 20-ish vendors when, in some areas, there are over 100 providers, as can be attested by the Source-to-Pay Mega Map).

As with services, the only way to get close to what you want is to focus on specifying what the software has to do, who it has to do it for, what outputs are required, what systems it needs to integrate with, where it fits in the ecosystem, and how the affected individuals are expecting it to make their job better. The vendors really need to define the specifics of how the software will accomplish its tasks and how they will deliver it to do that.

Keep that it mind, along with the best practices we outlined in Part I, and you’re well on your way to writing a good Tech RFP, as long as you steer clear of the “Free RFPs” (as there is no such thing as a FREE RFP). For more best practice advice and insight, see the prior series.

This concludes our initial series on how do you write a good RFP. Hopefully you found it useful.

When it comes to services, many buyers think this is the easiest RFP to write, because you just have to specify what you want, right (wrong, but more on that later), but it’s really the hardest, and not just because, until recently, no tools were ever constructed to help with this.

It’s the hardest because the instinct is to specify what you want when the reality is that you have no clue what you want (because if you did, you wouldn’t have a problem or a need that required you to go out to market for a service). You know what is not being done, what problems need to be solved, and that if you don’t take care of it, things will get worse, but if you knew exactly what you wanted, that’s a specific resource to fill a specific role and an RFQ for contingent worker/contractor worker rates and possibly one or more products or tools to get the job done.

As with indirect and direct, if you are going out for an RFP, you are looking for a solution, but unlike indirect and direct, you are looking for an inclusive solution where the vendor will identify all of the resources required — be they personnel, products, or software — and put together a solution that will meet your needs and do so at a price lower than your organization attempting to do everything in house, either because they have the expertise to do it better, the resources to do it faster, or the scale to do it cheaper, or all three.

It’s absolutely critical here to focus in on the processes you want implemented, the problems you want solved, and the deliverables you expect. Not on the personnel you think you need, the systems you think should be put in place, or the reports that should be produced. Clear descriptions of what you are doing now, why it’s not working, what kind of improvement you are looking for, and what outcomes you desire (metrics, etc.) are a must.

It’s also critical to focus on what type of operation you are, how you run the processes you are not outsourcing, your organizational culture, and how you would interface with the service provider on an ongoing basis. This defines the what you are looking for because it’s not just what needs to be done, but how it needs to be done to support your organization.

As with indirect and direct, the who, what, where, when and why is more critical than the how.

This is not so easy, right? After all, the number of sourcing platforms out there that support direct is about ¹/₁₀ of the platforms that support indirect, and they tend to be over-the-top suites, new startups still building out complete solutions, or over-customized to particular industries. The exceptions to these rules are few and far between and you have to look. But this isn’t why it’s not easy.

As per our last post, the platform alone doesn’t make writing a good RFP easy. If you don’t have the knowledge of what goes into a good RFP, and the platform doesn’t provide it, it doesn’t matter if the platform is the best one out there.

And when it comes to direct, since you’re usually looking for a component, part, or raw material to support a product or system build, you need a lot more insight into what the (end) product or system is as well as the requirements for the component, part, or material.

Again, if you need grade 5 carbon steel bolts for your bus frame, that’s an RFQ, as you are going out to market for a very specific product. You’re going out for an RFP when you’re doing NPD/NPI, and you’re trying to figure out the best component, part, or material to use in your new design.

The key here is to be specific about two things:

1. the intended use and goal of the product or system
2. the form factor, durability, capability, and integration requirements of the component, part, or material being sourced

For example, in the first case, if you are building a power transformer, is it a DC to AC converter to allow people to run small appliances off of their truck battery or is it a stepwise transformer to convert power over a long distance transmission line (that can be over 750,000 volts) to a local substation to power a 460V distillery. This makes a big difference in the required durability and design of any component you plug in.

In the second case, if you are looking for an FPGA, you’re going to specify the preferred and maximum dimensions for that power transformer, the durability (based on expected lifespan), capabilities required (simple display to dynamic stepwise current recalculations based on fluctuating power in the lines to give forewarning of a power drop or cut-off if it predicts a surge that will flip the breaker), and integration requirements (pins, bus speed, etc.). You’re not going to specify the entire design, materials, etc.

Again, it comes down to specifying the need more than the actual design or product. Because if you need a specific product, that’s an RFQ.

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!

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.