Bells and Whistles Lead to Cells and Thistles! Part I

I’ve been hearing and seeing two things lately:

  • smaller vendors telling me they’re struggling to close / losing deals because their potential customers are telling them they are leaning towards the bigger/splashier vendor with more “Bells and Whistles”
  • vendors getting lots of (and possibly too much) funding are focussing heavy on bells and whistles (because they believe it will help them sell fast and meet the significant, and often unrealistic, sales targets of the investment firm[s])

So I have to address this because if you select a solution based on bells and whistles, expect to end up in a cell while your fingers bleed from the thistles that prick you every time you try do something that’s not the primary, simple, use case. This then leads to usage of your purchase declining quickly, causing you to end up with another piece of shelfware before you get even halfway through the initial contract subscription.

Now, to help you understand I’m not making this up for clicks and shares, we’re going to dive into some of the most common bells and whistles and why, in the best case, they’re a complete waste of money and, in the worst case, the thorn prick will end up being so painful that your team will simply stop using the software. We’re going to do this across source-to-pay.

Intake

Everyone’s gotta have it because, apparently, it’s brand new and Zip invented the category a few years ago. This is, of course, complete bullsh!t because

  1. Coupa has had full intake since Procurement Independence Day in 2006. You just didn’t know because when Robbie took over the Coupa factory, licensing switched from enterprise size to per user, and the cost was too much to give non-Procurement users a license so you didn’t see the intake that was there. (And to that effect, if Zip is pricing per user, how is this better?)
  2. Zycus had one of the first modules dedicated to intake, iRequest, over a decade ago

Moreover, everyone has to have Gen-AI intake, because, apparently, using a few drop downs to figure out what a user wants is too difficult for the average iZombie who has been zombified by ChatGPT over-dependence.

While this is useful to parse an initial request from a user — do they have a question, want a report, or want to make a requisition (and if so, is it from a catalog or do you have to go to market) — beyond that initial parsing (which will never achieve an initial parsing accuracy beyond 90%, so at least 1 in every 10 requests will have to be rephrased for the system to get it right), it goes from useful to painful to useless.

Here are a few examples:

  • Policy Question: as we’ve said before, Gen-AI has two strengths: large corpus search and summarization and natural language processing; in this circumstance, if the success rate is 90%, it’s mostly useful, but to be honest, if you know the right terminology, elastic search will work just as well, retrieve the exact clause, and never hallucinate a response. Summary: sometimes useful.
  • Catalog Buy: good luck with this because you’ll spend at least 5 minutes trying to order a box of gloves, and I kid you not — see this post where we illustrate how it will take you five minutes to explain to the Gormless AI what you want when you could place an order in a well-defined catalog in 15 seconds with 3 words, 1 number, and 4 clicks. Nothing will drive your users to maverick purchasing off of Amazon, BestBuy, and even Walmart faster than a Gen-AI intake portal. Summary: painful.
  • Analytics Request: while it’s great for a simple “how much am I spending on supplier S” (especially if that total exists in a spend cube), the fact that Gen-AI is very bad at math (to the point that you can ask the same question twice in a row and get a different answer), and not so great at parsing very specific requests such as how much did we spend with supplier S on steel products last quarter which makes it all but useless — even Gartner, the ring leaders of the Gen-AI lovefest, have predicted that “conversational analytics” will completely leave the ProcureTech vernacular in two years. Summary: useless.

… but this is just the beginning. We’ll continue with the Source to Pay process in Part II.

In ProcureTech, Stop Caring What Gartner, Forrester, or IDC Thinks!

I shouldn’t have to address this again, but every year multiple vendors reach out and ask how to get on these vendors maps because they believe it’s the only way to get more market visibility and/or be selected by certain customers, including you. It’s not the only way to get visibility and if a vendor can’t convince a potential customer from thinking that only map companies are good, I’ll tell them this right now — that’s not a customer they want (because that vendor will be out on the renewal with whatever vendor overtakes them in the map when the CPO changes in 3 years, because companies without vision to look beyond a meaningless map don’t keep real talent, and only real talent will identify and select the best solution and ensure that solution is kept over time).

But I digress — this post is about you, the potential customer, and why you need to STOP caring what Gartner, Forrester, or IDC thinks.

First of all, we’ve said it before, and we’ll say it again: It’s NOT the Analyst Firm. It’s the Analyst!.

In addition to all of the skillsets and education that an analyst needs to have to get it right, which we covered in detail in that post, the analyst needs a lot of relevant experience, and history in the ProcureTech space, to make sense of the ProcureTech world today. Ask yourself: how many of the analysts with the right education have at least 10 years in our space? The answer is very few. How many have 20 years in (independent) analyst roles? You can count them on your fingers. I know of myself, Jon Hansen, Pierre Mitchell, and Chris Sawchuk with 20 years of (independent) analyst experience in our space and a deep technical (STEM) education. Everyone else who started covering this space day in, day out two decades ago has moved on or retired. Now, of these analysts, how many have also built actual solutions in the ProcureTech space, connecting the dots between the education, theory, and practice? Two of us — myself and Jon Hansen. (But we should note that Pierre and Chris spent part of their careers on solution advisory consulting and implementation guidance, and have deep knowledge about the implementation and integration requirements, which is also very unique and useful in technology selection.)

Now remember the second point: Vendors Have Lured Big Analyst Firms Astray and that you’re not getting a map of the best solutions, but the best solutions from the analyst firm’s pool of vendor sponsors and research subscribers, where the reality is that only the big, established, cash-rich companies can afford the high-priced subscriptions that keep them in front of the overworked analysts who have to spend over half of their time taking inquiries or keeping high paying subscription customers happy. (Whereas analysts at smaller firms or independents get to focus on studying and understanding the solutions, not general inquiries or whether or not the contract [or pricing model] is good.)

This means that these big firm analysts are not spending a lot of time, if any, looking at the up-and-coming mid-sized companies that have not only been around long enough to develop mature enterprise solutions, but solutions that are more modern, more powerful, more usable, and more intelligent (with embedded analytics, RPA, and the right AI for the task at hand), and possibly (much) better for you. Moreover, if the enterprise is a mid-market company, or able to go with a best-of-breed as a bolt-on to their enterprise ProcureTech platform, they’ll never know about the majority of these solutions (as only the overfunded startups will have the money to get the big analyst firm attention, and these vendors often have more financial stability problems than the smaller vendors who are bootstrapping or taking minimal funding and actually have stable, happy, paying customers keeping them afloat).

Third, and most important, it’s not the best rated solution, it’s the best solution for your organization. Not only is it the case that this solution is very likely not on a map of only 20 companies (when there might be 100 companies that offer that solution), but it might also be the case that it is the lowest ranked solution on those maps — especially when these maps tend to rate solutions on a lot of subjective factors that match what the analyst thinks are the most relevant for an average organization, whereas you are a specific organization which has a specific set of relevant factors that you care about, with specific requirements for those factors. The more divergence between your factors and the analysts’, and your scale and theirs, the worse the map is for your needs, and the worse the solution you select will be.

The only maps you should care about are those that rank solutions solely on the tech capabilities and/or the customer rankings. But only so far as potential solution identification, not selection. Maps that concentrate on pure tech (like Spend Matters Solution Map) allow you to identify vendors that have the tech foundations, giving you a starting pool, but don’t allow you to identify vendors that have a solution — because a solution is tech and appropriate process support and integration capability and support and culture and whatever else transforms another piece of potential shelfware into a solution that will be used daily by your employees.

Note that we used the word “potential” for a reason. No map (including Spend Matters) is complete, so you will need to look at multiple sources (like ProcurementSoftware.site and the upcoming Art of Procurement ProcureTech 100) to put together a complete list of vendors to consider. Then you will have to cross reference with real analyst vendor write-ups (which can include the hundreds of write-ups here on this site if one or more of your potential finalists are included) to whittle down that list to the best starting set for your best practice technology RFP (of which we have a lot of advice on how to write that on this site as well).

At the end of the day, it’s about what solution will work for you, not about which solution is on which map!

How Do You Write A Good RFP? Part V: Software

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:

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.

How Do You Write A Good RFP? Part IV: Services

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.