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.

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.)

But before we continue with the modules, here are two of the most common bells and whistles across all Source-to-Pay platforms that deliver absolutely no value whatsoever.

Flashy UX

A lot of startups over-focus on the UI and UX, believing that the big problem with today’s platforms is that they are too unfriendly and too hard to use (which is often the case with older generation suites, but not the case with the majority of newer, mid-market, suites and best-of breeds) and that everything can be made simple with an AI-driven workflow that makes all of Sourcing and Procurement easy-peasy (which it is if you are buying pens and paper for the stockroom, but that’s about all that’s easy peasy).

They then get professional speakers and presenters to train their salespeople on these very flashy, impressive looking, platforms to give awe-inspiring demos on the pen and paper buying process (with the promise that everything is just as easy) that management and buyers eat up, even though the buyers aren’t allowed to play with it first (and see what happens if they try to source custom built FPGAs for their control systems or specialized implementation and integration services for their new supply chain planning software that needs to connect to the ERP, the direct sourcing module, and the CRM — which is where their over-simplified flashy UX will fall apart completely as there will be no deep functionality behind it).

The reality is that it is not flash, fancy UI, or even AI-driven automation, that matters in enterprise software. What matters is the effort required to do daily tasks of moderate plus complexity, and that is often best accomplished by sophisticated workflows that are pre-configured for different scenarios and very simple, step-wise, input screens (with the current step and complete workflow highlighted) that allow a person to see where they are, why they are there, what they need to enter, and what comes next. It’s often the case that the screens aren’t minimal, aren’t colourful, and aren’t flashy. (There’s a reason that green screens lasted so long and that’s because, well designed, they made work efficient — remember, it’s not personal entertainment software, it’s business software your team might need to use 10 times a day and if the flashy software requires 30 screens because they are all too minimalistic [when it should require 10], or doesn’t support the process at all, it doesn’t matter how good it looks or how easy it is to use.) The best software is designed to ensure that all of the common repetitive tasks, no matter how variable they can be, can be accomplished as quickly as possible with as little human input as possible, and you can’t always make that minimal, flashy, or appealing to the inner artist.

Adaptive AI-Driven Automation

A lot of (over-funded) startups on the Gen-AI Hype Train (who have been Blinded By The Hype) believe that they can use the latest and greatest version of Gen-AI (which, FYI, has a 48% failure rate if we’re talking the latest ChatGPT version as of the time of this being posted) to automatically adapt to all input requests and automate every sourcing and/or procurement process they claim to cover. They can’t. And they never will be able to because hallucinations are a core function of LLM technology (regardless of which LLM you use).

As a result, while it will work great for most of the standard requests and processes and get them mostly, if not entirely right, anytime anything sophisticated or exceptional comes along, it will break down completely. If you’re lucky, it won’t know what to do, won’t do anything, and force human intervention — forcing you to design and build a full process by hand through it’s painful conversational interface that will require you to repeat yourself multiple times and specify the same request in six different, increasingly precise, manners until it builds the process you need. If you’re not lucky, it will assume your request to order 1000 Ford brake shoes (for your fleet of vans) is actually a request to order 1000 Nike Jams (breaking shoes) because your last order from James Ford (a sales manager who likes to abuse his P-Card and gets away with it because he signs the largest contracts and the boss looks the other way) was for Nike Jams, and the system automatically orders 1000 pairs of Nike Jams, shipped to Fords office. Moreover, you don’t notice, because it says order placed, delivery in 5 days, and you don’t bother to verify because you’re in a hurry (and it worked okay on the last 9 order requests you made).

If, in comparison, you had an e-Procurement system that you could setup with standard re-orders off of contracts, you could type re-order brake shoes in the universal search bar and it would brings up the standard order pre-filled with units, supplier, and standard delivery date and you could simply hit submit to get the standard re-order with 100% certainty, or change the supplier, delivery location, delivery time, and/or units to make a simple change. No ambiguity, and no chance of error. It’s 3 words and 2 clicks, and you’re not waiting 15 seconds for it to parse your request and 15 seconds to do who-knows-what and give you a verification.

In other words, 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.

Moreover, after 25 years in the space and 19 as an (independent) analyst, I can tell you that this correlation almost always holds true:

The more bells and whistles a product has, the less actual functionality or support for complex or exceptional situations or process is actually embedded in the tool, and the less useful it ultimately is over time.

The tool will ultimately end up as yet another piece of shelfware (that you are locked into for another year or three if it’s SaaS, and more if it’s not), and that’s why the average mid-sized and larger enterprise has somewhere between 300 and 1000 SaaS applications! (Because most aren’t used!)

Seek deep solutions that solve your problems and allow your team to become more efficient over time, not razzle-and-dazzle solution based on the wisdom of P.T. Barnum: “the people like to be humbugged“.

To make it clear how useless bells and whistles are, we will continue this series and address major areas of Source-to-Pay starting in Part III.

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.