In Part I, after noting that I’ve been hearing and seeing the following too often lately:

• smaller vendors struggling to close/losing deals because the bigger/splashier vendors have more “Bells and Whistles”
• vendors getting lots of (and possibly too much) funding focusing heavy on bells and whistles

I said that we were 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. (And often do so before the subscription is half, or even a third, up, which leaves you in an expensive subscription jail you cannot stop paying for even though no one is using it.)

We started by diving into Intake before addressing the general situations of Flashy UX and Adaptive AI-Driven Automation which are permeating the space for little to no value whatsoever. In our last post we continued our discussion of the bells and whistles in Source to Pay that offer little to no value and we still need to address a few useless Procure to Pay whistles before we can complete our discussion, but first we have to address another across the board useless feature.

Actual Animated Bells and Whistles (complete with Bell and Whistle Sounds) …

Along with their equivalents.

First off, let me state that this is something I should NOT have to write. Let me also stat that it angers me that in 2025 some companies still mistake flash for substance or believe that it adds any value whatsoever. Not only does flash NOT add substance, but the annoyance factor soon becomes aggravation and leads to users ACTIVELY boycotting the platform you spent hundreds of thousands, if not millions on, and in particular, the users who should be using it daily.

Let me explain with one of the worst examples of this, which is present in some of the (big) intake/orchestration platforms and upstart P2P platforms. Animated images that signal when a user has received a requisition, PO, and purchase order (sometimes complete with bell sounds). Now, to a manager, this looks cool because the system draws an animated graph from requester to purchaser to supplier back to purchaser and shows an animation on request complete (purchaser processed the request), requisition complete (and supplier received the PO), acknowledgement complete (purchaser received the acknowledgement, and possibly a delivery date), invoice received (purchaser approved and sent to Accounts Payable), etc. To an average user who uses the system once a month to make a requisition for something, it looks like it will be very easy peasy to use.

But for the Procurement Buyer who has to deal with, and verify the routings on, 50 requisitions a day and deal with 50 “where is my payment” requests a week because the supplier rep is literally too technologically stupid to both login to the platform AND do two clicks to get to the right search screen and then enter their PO # flawlessly, IT IS AN ABSOLUTE NIGHTMARE! (And not the Alice Cooper kind!)

Think about it. REALLY THINK ABOUT IT! They have to review 50 requests, deal with them, reassign them, or just verify them. After every request. they have to deal with an animated graph that just slows them down. Plus, because each request has these big animated logos, maybe they can fit 10 on a screen in a table view, vs. being able to see all 50, sort by type, drill down, reassign in bulk, and move on.

But it gets worse when a supplier accounts receivable rep or seller calls and says what’s the status of my invoice (and for some reason, doesn’t have the PO number because the PO # is in the system he can’t figure out how to get into), and you have to do multiple clicks to even bring up the advanced search/filter tab, and even when you manage to filter down to the 3 day window it’s in, because the supplier batches, them, you have 50 on that day and can only see 10 at a time — and no line item details. Vs. No animations at all, a tabular view with key line items, and the ability to quickly scroll and find the invoice, and a single, quickly scanned, word that shows the status. After a few weeks of animation atrocity, you get so angry and fed up you beg to get the green screen ERP back! I’m not joking here. Your back office people are overworked, and any system that slows them down quickly gets their ire and loathing and if they can avoid it, they will.

P2P: Consumer-Style Catalogs

Your requisitions want a one-click, but your Procurement personnel DON’T want an Amazon style catalog. They don’t want “the best deals today” popping up beside the on-contract / preferred vendor catalog items and the budget owner with catalog authority choosing that off-contract “best-deal” thinking she is saving the organization when, in fact, a failure to meet your contractual commitments negates the rebates you were counting on at quarter’s end.

Moreover, when a user wants to requisition a new phone or laptop, she doesn’t want 20 options if only 2 are company approved for her. Nor does she want a lot of fancy graphics and super deep dives on the main screen, with hard to find “add to cart” and “buy now” options because they are buried in too much text/images.

Buyers want a get-in, find it quick, buy/requisition it now, and get out experience. Procurement personnel want a system that not only enforces policy, but makes buying on the contract easier than doing literally anything else, including going to a third party site and ordering something on the P-Card. Remember, as a fellow analyst likes to say, humans are lazy and if doing it right is easier than doing it wrong, they’ll do it right. (As a classic example of this, take music piracy. It was rampant in the mid to late 90s, but as more on-line / streaming options, like Apple Music and Spotify, came online it dropped suddenly because getting what you wanted at the best quality was cheaply and easier to do legally. Make Procurement like that, and policies just get followed.)

There are other examples, but by now you should get the point. Buy a solution because it has the breadth and depth you need, NOT because it has bells and whistles, because as soon as the solution is found lacking, usage will drop. Moreover, if all the solution does is annoy your daily users with useless bells and whistles, they will do their best to stop using it entirely!

To repeat one more, and hopefully final, time, as we said in the last three parts, bells and whistles look and sound cool, until you realize that the ringing can be deafening to the point it gives you such a headache that you can’t get your work done. So don’t get lured in by the bells and whistles, focus on real solutions that will make the majority of your work easy and the remaining minority possible, even if the solution doesn’t look much better than the green screen you have now. You want solutions, not shock-and-awe where only shock remains once you realize the awe was fabricated.

In Part I, after noting that I’ve been hearing and seeing the following too often lately:

• smaller vendors struggling to close/losing deals because the bigger/splashier vendors have more “Bells and Whistles”
• vendors getting lots of (and possibly too much) funding focusing heavy on bells and whistles

I said that we were 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. (And often do so before the subscription is half, or even a third, up, which leaves you in an expensive subscription jail you cannot stop paying for even though no one is using it.)

We started by diving into Intake before addressing the general situations of Flashy UX and Adaptive AI-Driven Automation which are permeating the space for little to no value whatsoever. Today we continue discussing the bells and whistles in Source to Pay that offer little to no value.

RFX: Generation

This sounds super cool and super helpful, except, in all but one case I’ve seen so far, it’s not. The way most of these products are implemented is they ask you a few questions, create a very detailed prompt, feed it to a generic LLM, and pull back what looks like a good RFP because it’s reasonably long and really well written (compared to the average RFP written by a junior buyer who has written anything without the aid of an LLM in 5 years).

Except what it brings back is an RFP that is written to the LOWEST COMMON DENOMINATOR, not average, and definitely not the wisdom of crowds because these LLMs are trained on whatever data can be scraped from the internet, and the data there is the most of becomes the data that influences the LLM the most, and that data is the lowest common denominator data. So, you get a rather generic RFP with little to no useful specifics, which means that the RFP is okay for indirect and standard services at best, and poor for direct and complex services, if it’s even usable.

RFX: Response

You have some vendors that are building LLM solutions to help vendors build RFX responses based on their data (pretty good) and standard responses, which is not so good because, again, it’s lowest common denominator responses with absolutely no unique capabilities conveyed or any unique thought. You want a vendor who took the time to review your RFP, understand it, and come up with a thoughtful, customized, valuable solution to your problem — not a vendor who trusted an LLM to create a winning response.

Supplier Discovery

Quite a few vendors are now integrating AI, and Gen-AI in particular, into their supplier directories, networks, and internet search and promising quick, easy, powerful supplier search for any need you can think of. A few of them, primarily the industry specific solutions, work pretty good, but the majority of them give you results that are no better than a random Google search. This is because, without deep supplier profiles and deeper product and service files, you can’t do good supplier discovery.

Automated Supplier Risk Profiles

Now, this sounds really useful, and if they were reliable, they would be. But most of these platforms are pulling in third party rating data, computing risk statistics off of incomplete web data (supplier site, articles, social media sites) based on LLM/statistical processing that’s not fully accurate. This results in both false positives and false negatives. False positives because the incomplete data results in a poor reliability or performance or brand score, which isn’t too big a deal if you think you might need the supplier, dive in, identify the issues, provide the missing data, and fix the scores. (But if the suppliers who are the false positives are the best options and you overlook them because you choose to focus on the suppliers who were all green, and only middle of the road, then you end up with mediocre suppliers when you could have had good ones.)

But if the suppliers turn up green, and you trust the scores because the handful of green scores you verified when the system went live were reasonable, and you select a supplier that was on the verge of bankruptcy (because the financial ratings agencies didn’t have the data from recent events because the supplier was private) who has been turning out poor quality products over the last few months, you could end up with a supply shortage on short notice followed by a lot of returns and demands for replacements you can’t provide — and that’s not a good thing.

The best solutions are semi-automated, force the buyers to build the right profiles and metrics, compute data confidence, and force buyers to verify data of low confidence. They don’t promise miracle ratings, they promise reliable solutions.

In other words, as we said in the last part, bells and whistles look and sound cool, until you realize that the ringing can be deafening to the point it gives you such a headache that you can’t get your work done.

Finally, because we want to make it extra clear how useless bells and whistles are, we are going to continue this series and address a few major areas of Procure to Pay as well.