Siloed data means that teams draft and issue RFPs with a subset of the information they require to write a comprehensive document soliciting supplier proposals. The buyer’s team lacks a full sense of the problem the firm wants to solve with the procurement or its importance. They may not know the full spectrum of suppliers who can address their requirements.

Siloed people means that not every stakeholder who should be part of the procurement gets to join. This includes some of the end users or others who will be affected by the purchase, as well as people who have domain expertise regarding the space.

Siloed opportunities means that the RFP process limits the number of organizations collaborating on a problem. For example, if both marketing and finance need a similar software, they may end up running separate procurement events instead of a joint one. Companies or government agencies purchasing the same solution might benefit from issuing a single RFP but are prevented from doing so by policy restrictions or, more likely, an inability to discover like-minded partners.

Silos can be thought of as fractal; they look the same at different scales. Procurement silos can appear similar at the department level, at the firm level, and at the level of multiple companies. Divisions within a department fail to collaborate effectively, just as departments within a firm disappoint. There can be significant obstacles to joint procurement that spans multiple buying entities, e.g., cities in different states or provinces.

All of these things contribute to sub-optimal outcomes. What does that look like practically? An optimal procurement outcome is one in which the buying entity buys the right solution, from the right supplier, at the right price.

These silos emerge for many reasons including politics, organizational design, compliance policies, fear, or an inefficient approach to data. People use different language to describe the same problem, making it difficult to communicate what they want.

These silos emerge organically because they exist within the context of both internal markets for information and power, as well as external markets for goods and services.

Conceiving of these dynamics as market-based is the first step towards resolving the frictions that stand between the buyer and value-for money, between the supplier and a long-term valuable customer relationship.

MIT’s Andrew Lo has written extensively about what he calls the adaptive markets hypothesis:

“The adaptive market hypothesis, as proposed by Andrew Lo, is an attempt to reconcile economic theories based on the efficient market hypothesis (which implies that markets are efficient) with behavioral economics, by applying the principles of evolution to financial interactions: competition, adaptation, and natural selection. This view is part of a larger school of thought known as Evolutionary Economics.”

It is a radical departure from the prior way of thinking about markets as machines that process information instantaneously to reflect the correct, rational view in the price of a security.

Adaptive markets mean that markets are more like biological ecosystems that may or may not be efficient at any given point in time in the ways that they process information. Under some conditions, at some points in time, they can be very good at processing information and allocating resources; in other circumstances, they can be wildly off the mark.

Adaptive markets are made up of individuals and organizations that are themselves flawed and irrational. People are overconfident. People exhibit loss aversion. People can be lazy. People have a difficult time seeing things with a systemic perspective. People use heuristics and rules of thumb to proceed. The relative impact of different types of investor can change over time, shifting the market’s underlying structure. Strategies like value that worked twenty years ago stop working in a zero-interest rate environment disrupted by significant technological change in the economy. Ten years ago, individuals didn’t influence options markets; now they dominate them.

Things work until they don’t.

Lo’s thesis is a way to synthesize the original mechanistic models of financial markets with the subsequent rise in behavioral economics developed by researchers like Daniel Kahneman.

The efficient markets hypothesis cannot contemplate meme stocks or bubbles; adaptive markets can.

Markets exist within a broader framework in which everything is part of the complex adaptive system that is our social, corporate, and economic life.

To succeed in a biological environment, one needs flexibility; the conditions change constantly.

One needs to evolve.

This is true of procurement, too. The problems that firms try to fix with purchases are in flux. The people and suppliers who are involved in these decisions shift constantly. New technologies like AI emerge to change the landscape. Geopolitics interferes.

Buyers in markets for goods and services, just like investors in financial markets need a clear, complete picture of the chess board.

Silos are problematic in a stable environment. Silos are damaging in a dynamic environment. Silos are devastating in a disruptive environment.

If we accept the premise that a rules-based, mechanical approach is doomed to produce the sub-optimal procurement outcome, then what do we need to do for adaptive success?

• Collaboration and sharing of as much relevant data within the enterprise and across organizations as possible
• Increased participation to solicit maximum input to shape the discussion with suppliers, identifying possible solutions, and evaluating submitted proposals
• Joint RFPs within the firm and across organizations
• Standardized language that minimizes jargon to maximize the efficiency of communications

Which brings me to Figma.

Figma is the market leader in product design software. People use it to design and prototype software applications. They mockup so-called wireframes to show what the different sections of an application will look like and then they make prototypes to show the user flow within the application, usually before the developers write a single line of code. It’s not about making it look pretty (although that’s part of the outcome usually). It’s focused on simplifying the user experience and addressing edge cases in which users can arrive at dead ends when navigating the application. It is also about ensuring that the application includes all the necessary functionality, manifesting the vision of the software architect as closely as possible.

Before Figma, there was Sketch. Sketch appeared on the scene in 2010. It created the category, recognizing the explosion in app design as new ways of interacting with increasingly sophisticated software emerged. Before Sketch, designers would try to adapt existing tools such as Adobe Photoshop for the purpose, but this was difficult. Sketch was a desktop app built for the MacOS. It enabled a single designer to whip up complex wireframes quickly. It was distinguished by its functionality; it was built for this purpose.

Figma came later. It took the company years to write its code, but it disrupted the space. It had similar base functionality as Sketch, but it was built natively for the browser (not as an installed desktop application) and it added an important layer: collaboration. Here’s Stratechery’s Ben Thompson:

“Think about my brief description of this “product design and development” segment: multiple app views created by design and implemented by engineering imply at least two different people working on a project (a designer and a developer); in reality, the huge number of different views and increased functionality in apps meant that there were increasingly large teams on both sides. Sketch definitely made it easier to design an app in one place, but it did nothing to make it easier for teams to work on an app together; Figma, because it was native to the web, effectively got collaboration for “free” from the beginning.”

Figma took off. Thompson quotes Figma’s S-1 filing related to their recent blockbuster IPO:

“As more designers and their teams started using Figma, they began to understand the benefits of designing together in the browser. It was more fun working collaboratively in the same file; it was also faster and more efficient to work in a single product that brought storage, asset creation, prototyping, and other parts of the design toolchain into one place. The ability to easily share work with a URL led people to bring collaborators into their files earlier, placing more emphasis on co-creation and less on the “big reveal.” It also led Figma to spread quickly within companies and design communities globally, while giving teams something they’d never had before: a single source of truth to access the most up-to-date designs. Today, the openness and accessibility that Figma helped pioneer is no longer a novelty; it’s the expectation, a way of working that has spread across teams, tools, countries, and industries — and transformed the way products are designed and built.”

Figma was built for an adaptive market for information and influence within the organization (and across the organization if you include consultants and third parties).

Figma owns the market.

Sketch was an old-school approach, an application built for a different era which limited the number of stakeholders involved in the project. Figma recognized that their customers could build better apps (obtain better outcomes) with more collaboration and more flexibility. They made the user experience simple and accessible.

Figma also noted that it was going public, not because they perceived AI to be a threat that would put them out of business, but because they wanted to add AI as a complementary layer to their collaborative suite.

An adaptive markets approach to RFPs would do the same thing. It would explode the process in terms of enabling more data and more input from a wider array of people, supplemented with AI tools, wrapped in a simple, elegant user experience.

AI will not replace procurement; it will enhance it. It is a bicycle for the mind, in the logic of Steve Jobs.

Does this characterize the RFP tools in the market today? Were they built natively for collaboration? Are they easy to use? Do they bolt on AI as a replacement or is AI an adjunct function?

This is what we’ve built at EdgeworthBox. We’re a collaborative, adaptive suite of tools, data, and community that enables flexibility and joint procurement. Watch this space. Important new things are coming this Fall.

This is a human tendency.

Software developers are no different. You see this in the initial phases of a new technology roll-out.

Consider for example the early days of search online.

Companies like Yahoo!, AltaVista, and the like merely digitized the analog way we would find things. Before the Internet, if you were looking for a plumber to fix a leaky faucet, you would pull out the Yellow Pages directory and look under the letter “P.” There was a listing with a name and a telephone number and an address. Some plumbers would pay for an ad in the form of a box that might show their logo with some slogan. You had no way of distinguishing one plumber from the other based on the information in the book.

As I recall,  Yahoo! had listings of links in alphabetical order. So did everyone else. You used Yahoo! because it was there and everyone else used it. I believe it even started out as something like “Jerry’s List” named after founder Jerry Yang. Advertisers would pay Yahoo! for the equivalent of the boxes in their listings. Instead of phone numbers, clicking on the name of Plumber X would take you to his website. The listings were links.

The experience had the merit of being familiar, at least.

That is until Google came along and did two things that were interesting.

One, the user interface was entirely different. Instead of a home page in which one could see listings of categories, clicking on which links would take you to another page for a specific set of goods or services or interests like Plumbing, there was just a single box under the now-familiar Google logo. It was clean. Yahoo! and the others were cluttered. With Google, you typed in the name of the thing you were searching to find in Google’s box.

Two, the results, presented on a separate page, were a listing of links, including a brief description. However, the links were in the form of on an ordered list. Google determined the ranking of each individual listing based on the number of citations for that link in other sites or the frequency with which people clicked on it. It was like the way in which academic papers are ranked based upon the number of citations. Now, there was a way to distinguish based on relevance or quality that the Yellow Pages methodology did not contemplate.

Yahoo! was a directory. Google was a search engine.

Simplicity and rank ordering won the day.

Rank ordering was so important that an entire cottage industry sprouted up of people who told you they could game the system and trick it into giving you a higher ranking than you would have obtained without their help.

The company didn’t even advertise itself in the old days. It spread by word-of-mouth. I remember when a colleague told me about Google and my shock and awe when I pulled up the site at work for the first time.

Similarly, ERP systems digitized the analog version of bookkeeping and procurement systems and HR systems and payroll systems. Where the accounting had been done manually with clerks updating paper spreadsheets based upon specific functional activities and those spreadsheets rolled up into the general ledger, now those functional activities took place in a digital interface that updated databases. The databases then provided the information for other systems to automate their aggregation into the general ledger. Productivity increased in the sense that there were fewer accounting clerks, even as there was greater IT expense for software licenses and computers and networking equipment and IT professionals. As they say, the productivity was everywhere to see but the financial statements.

Digitization meant taking a pencil-and-paper task and making it screen-based. That’s it. That’s typically all it meant. The business process didn’t change meaningfully.

Even today, there is little distinction in the way in which a Request for Proposals auction takes place between a paper process, an email-and-spreadsheet process, and a contemporary procurement technology approach. The tools may be different but the business process is the same. Perhaps there is some automation on the margin that makes the digital process easier, but maybe it’s offset by a reduction in the quality of the bid solicitation document. Maybe people spend more time focusing on the quality of the process when it’s manual. Maybe.

In anticipation of the introduction of artificial intelligence and leveraging lessons from financial markets where millions of auctions take place daily, EdgeworthBox took the first steps to change the business process.

• We added structured data regarding previous RFPs and contracts and made the data shareable across all the stakeholders in the RFP process, not just people in procurement (for the buyer) or sales operations (for the seller).
• We built a social network with messaging and profiles to help users from both sides and across organizations collaborate.
• We added rapid onboarding tools so that buyers could cast a wider net beyond the narrow ken of suppliers with which they had existing relationships.
• We enhanced the group dynamic at the level of the value chain and the internal stakeholder group.
• We enabled joint RFPs issued by multiple organizations.
• We added scoring tools to speed up and improve the quality of vendor selection.
• We wrapped everything in a cleaner user experience to simplify the process on both sides.

All of these features were designed to deliver specific functional improvements: faster RFPs, better-written RFPs, and greater competition in terms of price and solution that would lead to better problem-solution fit.

Just as Google cleaned up the user experience and added utility in terms of ranking links by quality and utility, we simplified the RFP process to remove the bureaucracy while making it much easier to surface actual intelligence.

We did it with a view to developing troves of the kind of data that we anticipated AI solutions would need. (With our background in matching buyers and sellers in financial markets, we like to think of our approach as closer to a Bloomberg terminal than Google.)

From what we can tell, many incumbent procurement technology providers have rushed their AI products to market with another layer digitizing the analog process. At least that’s my working hypothesis. The AI tools in the market have more in common with the pen-and-paper RFP auction than they do with what AI should be able to do.

Digitizing a process means it goes from pen-and-paper to a screen.

For many solution providers, converting the process to AI so far seems to be just an extension of this digitization. There’s nothing new when it comes to improving the process. At best, AI moves the process from a screen to a software robot. Maybe.

In any case, it’s still the same process.

The only thing we can say for sure is that AI is a way to generate fear-of-missing-out for some solution providers to exploit.

This is why there must be the inevitable adoption blowback, the dip in adoption. People don’t want to overpay for something that doesn’t move the needle.

What AI needs to do is to fix the RFP business process because it is broken. It is bureaucratic. It is inefficient. It is centralized. It is the opposite of nimble.

It is risk averse. It is afraid.

Here are several predictions about how AI agents and more sophisticated AI tools can change the RFP business process.

First, AI will lead to a decentralization of the process. Instead of having procurement officers supervise the process with massive bureaucratic oversight, business units will execute their own RFPs. For example, the CTO will execute his own reverse auction to decide which cloud services to purchase. Procurement will have full transparency into the process and will trust the agents to execute the workflow the organization is comfortable letting the agents use. But the business users will run the process, not procurement. This means it needs to be simple and it needs to be functionally efficient.

Second, procurement staff will focus more on more strategic functions like contract enforcement and vendor performance evaluations, helping the firm ensure that they get the value they paid to obtain.

Third, suppliers will have their own AI agents. We may see a fully decentralized process in which buyer agents deal with supplier agents.

Fourth, the process will be much faster and much less expensive.

Fifth, it may be the case that firms replace the use of catalogs managed by expensive middlemen with hasty RFP auctions.

Sixth, the combination of collaborative transparency and AI agents may make procurement-as-a-service a much more attractive option, especially for smaller organizations. It will be cheaper to execute. It will be more efficient.

These are the things we’re working on for the next iteration of EdgeworthBox. We love to talk. Give us a shout.

Imagine the early days of the automobile industry. Cars were made by hand. Skilled individuals used tools (screwdrivers? wrenches? hammers?). The quality of the cars was variable. It was difficult to produce in high volumes.

Then, Henry Ford applied principles developed in other industries (like meat packing) to automobile manufacturing. He standardized components, broke down the process into steps, and set up a production line in which workers (specializing in individual stages) sequentially performed all of the tasks necessary to make a car. Production engineers studied the line constantly, using the data they gathered from time-and-motion studies to tweak the work at every point to make output more efficient on the margin.

“By 1914, Ford was producing more cars than all other automakers combined, with a Model T rolling off the line every three minutes.”

Automation of the Ford line brought prices down, making cars more affordable. He also took care of his workers, raising wages and implementing work rules that improved their lives and enabled them to afford the cars they manufactured. The impact this industrialization had on the broader face of America was even more significant. Other industries adopted his production techniques and his labor policies. Urban geography changed as automobile adoption became widespread with the rise of the suburbs; Ford had compressed distance. Other countries followed suit.

Car companies started to outsource some of their production lines, such as the assembly of parts (or, in some cases, whole cars), sometimes sending work outside of the country.

Fast forward to today and many automobile manufacturing plants employ robots instead of humans. The robots work tirelessly. They are less expensive. They are more reliable. They use more specialized tools. They are custom-designed; a robot on the automotive line is different from a robot in a shoe factory.

The modern company is full of so-called knowledge workers who work with data, using their judgment to make decisions. They have specific expertise in one or more functional areas, including procurement. Often, they must collaborate with other knowledge workers within the firm who have access to different data and look at it through the lens of different knowledge.

To quote Daniel Kahneman, Olivier Saboy, and Cass R. Sunstein from their book Noise, “Judgment can therefore be described as measurement in which the instrument is a human mind. Implicit in the notion of measurement is the goal of accuracy – to approach truth and minimize error.”

There is a parallel here to the evolution of manufacturing.

In the beginning, there was pen and paper. Procurement staff did everything manually. At the RFP end of the spectrum (EdgeworthBox’s area of focus), this meant coordinating internal stakeholder committees, developing requirements, writing bid solicitation documents, and mailing potential suppliers. It involved tracking everything in spreadsheets kept up by hand. Suppliers wrote out their responses and buyers evaluated them.

The advent of email and spreadsheet software made this easier to track and coordinate. Instead of corresponding with suppliers using letters, buyers could do so with electronic forms of communication. Spreadsheets helped procurement staff plan and organize reverse auction RFPs and RFQs. Theoretically at least, it was easier to manage and retain data for subsequent use.

In practice, the judgment of the staff derived from their experiences. Procurement events were noisy and biased in that there was tremendous variability around the outcomes. Even for one-off decisions, the outcome could be very different depending on who was running the process. Purchases of goods and services did not always obtain the best value-for-money in terms of the problem-solution fit the firm sought or obtaining the right price from the right supplier. Procurement judgment was prone to missing the truth.

ERP solutions and other sourcing software tools emerged over the past thirty years. These sought to take the knowledge worker’s process (for various functions) and to translate them into code, replacing the use of email and spreadsheets. The underlying (unstated) assumption behind these systems is that all companies execute these functions using the same process. Developers held this assumption even more firmly when building software for use in a specific industry, say manufacturing. All manufacturing companies were deemed to use roughly the same accounting, for example. And they were thought to approach RFPs the same way.

It makes sense to do so from the developer’s perspective. There are fixed costs to writing code. To the extent that you can sell the same code to more people, you amortize these over a larger base, improving your profitability. However, you avoid contextualizing the solution for each company.

You can have any color suit you like, sir, as long as it’s grey.

This lack of contextualization is a problem. Consider system A. It was originally written for manufacturers to help them execute RFPs. The vendor obtained tremendous success and sold themselves to a large ERP company. The ERP company then integrated the acquired solution into their offering as their procurement module, something its customers could elect to bolt on as an option. The ERP company wants to have a comprehensive suite of solutions so that they become the single source of back-office truth for their customers. Software is about scale, after all.

What happens if your company is a medical products company that is using system A. You have to jam your square peg into their round hole. What’s even more difficult is that the ERP system sells expensive seat licenses. Your CFO wants to control how many people get these, so it’s typically only people from the procurement department who warrant access. The other stakeholders are left on the outside.

In the end, many people end up using email and spreadsheets to overcome the limitations of the ERP module. Combine this reduced business-software fit between system A and the user firm’s context with the fact that the data in the system is restricted in terms of who can access it (and who practically does look at it), judgment gets noisy and biased.

Companies don’t buy the right products. They don’t find the right suppliers. They don’t pay the right prices.

Companies don’t get value-for-money.

AI takes two forms: tools and agents.

An example of an AI tool is chatbot, like ChatGPT. People use ChatGPT to write the emails that they send to suppliers or to other internal stakeholders. They may ask ChatGPT to write the Statement of Work. In this case, the machine is predicting a series (sometimes a long one) of next words. We use judgment to predict. The machine has some judgment that it has distilled from its training on vast amounts of general data. The user provides some context (in what is called the context window) and the machine does the rest. For some tasks, it’s probably fine. For other tasks that require more specific knowledge and greater experience in making decisions, it may not be the best solution.

We can think of AI agents like the robots on the manufacturing line. We give them access to tools, some of which may be AI tools like chatbots and others may be more general like access to Internet search or a calculator for performing mathematical operations.

I suspect that many of the early AI tools and AI agents were nothing more than wrappers for the legacy systems and ERP modules they were meant to augment. The predictions were just as biased and as noisy. If anything, the process became opaquer.

Over time, the agents will be more effective and more transparent. They will use chain-of-thought reasoning to emulate the judgment of their human overseers, showing their work. They will have access to a broader array of tools.

Their judgment will improve.

Most importantly, though, the agents will be customizable for the specific context of each user firm and each user case. This will be made much easier for agents using software tools that have built-in flexibility and collaboration around structured data. The flexibility makes it easier to integrate idiosyncratic conditions; no more trying to fit in questions about penetration testing in an RFP template designed for buying diesel generators. Collaboration is key because the agents will become members of the team; the more information and context they can obtain from the team, the better the outcome will be. Structured data, say from prior RFPs and responses received, will be vital for developing the agents’ judgment.

This kind of thoughtful approach will be far superior to just creating an agent backed only by a general large language model, or one reliant only a limited set of tools.

The efficiency gains of a robotic manufacturing line compared to manual assembly are staggering. The gains from agents will be just as impressive.

Please reach out to us. We love talking about the future of procurement and AI, in particular.

With the Request for Proposals process, the answer is likely no.

Consider the evolution of the RFP. You can imagine industrial companies in the 19^th century looking to purchase blocks of commodities like copper of a specific grade or wool for their mills. Commodities have a standard grade. They are fungible; one pound of prime beef is the same as another pound of prime beef. When we isolate characteristics related to quality, then the sole remaining factor is price. Buyers want to pay the lowest price. The supplier that is most motivated to sell will be most aggressive on price, perhaps reflecting an excess inventory that costs money to finance.

The RFP process, or more accurately, the Request for Quote process, is optimized for purchasing commodities where there is only one deciding factor.

There are several issues that derive from this, though.

One, we have trained buyers to focus on price as the dominant factor in selecting solutions. The problem here is that not everything is a commodity. When we need to distinguish between solutions across multiple dimensions, trying to reduce the problem to just one leads to sub-optimal outcomes. We may end up paying the lowest price today only to forego higher revenue or to incur higher costs in the future because we picked the wrong proposal.

Two, we have come to rely on the convenience of the RFP. Because it’s a process with which we’re familiar, we default to the RFP, ignoring the possibility of any other approach. We’ve baked it into our compliance policies. We won’t get fired for running an RFP.

Three, we presume to have enough category knowledge to be able to write a bid solicitation document that will generate plenty of responses. We assume that if we issue an RFP, suppliers will respond with plenty of free information either because they understand what we’re looking to buy or because they’ll do anything we ask in the hope of obtaining our business. The lazy default of the buyer is to be arrogant about their power relative to the supplier base.

The truth is that when it comes to complex procurement, we are not purchasing commodities. We need a process that is designed for the thing that we’re buying and we are blind to the possibility of alternatives to the RFP because of administrative inertia. We shouldn’t assume that we know more than the suppliers or that we are very good at communicating our intent. Writing is difficult. Most people struggle with it as individuals. Things can only get worse when we start crafting a bureaucratized instrument by committee.

Charlie Munger was an American lawyer and investor with a legendary track record. He was famous for his wisdom, expressed in clear language. These consisted principally of a set of mental models that enabled him to understand the world. Here’s Farnam Street discussing one of Munger’s favorite techniques: inversion.

‘It is not enough to think about difficult problems one way. You need to think about them forwards and backward. Inversion often forces you to uncover hidden beliefs about the problem you are trying to solve. “Indeed,” says Munger, “many problems can’t be solved forward.”

…

‘Despite our best intentions, thinking forward increases the odds that you’ll cause harm (iatrogenics). Thinking backward, call it subtractive avoidance or inversion, is less likely to cause harm.

‘Inverting the problem won’t always solve it, but it will help you avoid trouble. You can think of it as the avoiding stupidity filter. It’s not sexy but it’s a very easy way to improve.’

To apply this approach to the RFP, let’s start with the desired outcome and think about all the steps that it would take to get there, moving backwards in time.

When we purchase something significant or complex using a reverse auction like an RFP, we want to solve a problem. It’s more than that, though. We want to solve the problem as quickly and efficiently as possible while paying a reasonable price. We want to buy the right solution, from the right supplier, at the right price.

To solve the problem, first we need to understand the problem. It’s not enough to state it. We need to pull it apart. We need to assess how it interacts with other parts of the system of our enterprise. We need to think about the things that can go wrong. We need to understand the tradeoffs and conflicts in our existing approach, so that we can appraise how our solution will impact all aspects of the organism.

We also need to understand all the different options on the market and why suppliers made the choices they did in coming up with the variety of products we confront.

Moving backwards in time from our optimal outcome, the most immediate step is having a way to evaluate the options in front of us. Ideally, we have been able to convince a large number of suppliers to present us with alternatives. We have a representative sample that is indicative of the diversity of solutions from which we could choose. We don’t need every solution provider to offer us a sample solution. We just need to know that we have considered all the broad types of solution.

We need a way to compare these surfaced options that systematically helps us to pick the right one across multiple dimensions, not just price. To make an informed decision about how this will work as a system within the enterprise and the complexity of all its myriad moving parts, we need people who understand all those pieces and how they complete the puzzle to be part of the process.

Moving backwards another step, we need multiple suppliers to engage with us. It’s not sufficient to have a sophisticated evaluation process if we don’t hit the critical mass of proposals. We have to convince people to engage with us. This means we have to reduce their costs significantly. (It might even make sense to pay their proposal costs up to some reasonable limit.) But to really get suppliers to plug into our conversation, buyers need to showcase the problem in a way that appeals to their interest in the problem in the first place. We need to include them in the definition of the problem so that we can elicit from them their intelligence about the market. Ideally, the buyer enterprise doesn’t develop their requirements in a vacuum but relies upon the supplier knowledge to help them refine the specifications before suppliers begin to write their proposals.

Moving backwards through the decision tree, before looping in the suppliers, the buyers must have detailed conversations with all of the stakeholders within their enterprise, including staff who face the problem this procurement intends to address.

The one common denominator to all of this, and the thing that is underwhelming in most RFPs, is collaboration around various groups of people. There are fractal levels of groups starting with the prime contractor and its subcontractors (i.e., the supply chain). There is the internal committee of stakeholders who contribute to the process (and also those who will be affected by the final decision). There is the possibility of joint purchasing across organizations.

Collaboration is key. This is where the RFP process fails. This is the source of the iatrogenic effects of linear thinking and a forward progression through the problem that fails to also look backwards from the desired end. This is what nobody tells you.

The ideal solution will include these groups in direct collaboration from the beginning of the project to identify the full reach of the problem and to surface as many ideas as possible about how to solve it, in an inclusive manner that encourages feedback and engagement. This is not an adversarial competition in which buyer and supplier are arrayed on opposite sides of a zero-sum negotiation, but rather a collaboration to generate a long-lasting, transformation.

Incidentally, this lack of collaboration in the current status quo is a key reason for the failure of most digital transformation projects.

At EdgeworthBox, we have built a platform for collaboration that spans these different layers: the supply chain, the internal stakeholders, and partner organizations. We have built a platform that removes the frictions inhibiting genuine sharing of information. We enable inversion of the problem for complex procurements. If you’re a commodity buyer or someone purchasing small amounts, a traditional P2P system is what you want. But if you’re buying complex, long-lived, strategic solutions for critical problems, then you want EdgeworthBox as a layer in your procurement technology stack. Let’s talk.

They are very good at steering the buyer to weight certain features heavily and to discount other features entirely in the pre-RFP phase. This is, of course, “shaping” the RFP.

They are very good at writing slick proposals. These make the buyer feel good about the purchase.

They succeed at making the buyer feel good about themselves.

Note that none of what I have described has anything to do with the buyer purchasing the item with the best problem-solution fit or at a reasonable price. Value-for-money is not part of this conversation.

The salesperson’s job is not to solve your problem; it’s to convince you to buy their stuff.

It comes down to getting the buyer to think it was their idea to buy the widget that the polished salesperson is peddling.

Salespeople who are good at responding to bid solicitations are really like jedi knights.

Those aren’t the droids you are looking for; mine are.

Let’s conduct a thought experiment. Consider the following scenario.

Imagine a buyer who does their independent research. They don’t hire a consultant. They think about things from first principles. They develop their own expertise by speaking to their internal customers, the people who will use the good or the service the organization proposes to buy. They focus on what’s important and what’s not. Perhaps they talk to people with the same needs in other organizations to understand how they would approach the problem with a clean sheet of paper.

People can be remarkably candid and helpful if you know how to ask the right questions and you have the courage to do so.

Our intrepid and self-directed buyer team puts together a description of the thing that they believe will most closely address the problem their purchase is meant to resolve.

They do all of this without looking at what’s available in the marketplace and without speaking to any supplier. They don’t want to be infected. They want to approach this situation with a beginner’s mind, free of assumptions and history.

Inevitably, this pleasant reverie will collide with market reality.

At some point, our buyer team must speak with the suppliers. Perhaps it’s a pre-RFP conference call to talk about what they want.

Imagine the fireworks.

Invariably, the buyer will describe something that is innovative or that challenges the status quo approach to this particular problem.

Cue the wailing.

What you’re talking about doesn’t exist, the consultants will say. What you’re asking for will require millions of dollars in development spend, the leading incumbents will say. (This is especially true for SaaS software.) I’ve seen situations in which all of the participants on the call take turns laying into the buyer, gently. It’s a delicate balance. They have to get the buyer team to second guess their internally developed understanding of the problem and what’s feasible, but without individually being the bad guy who makes the buyer upset. It’s amazing how organic this shared responsibility diffuses; every supplier seems to do their part in negging the buyer. It’s tacitly collusive.

If they get this right, one lucky supplier will get the opportunity to educate the buyer on the realities of the marketplace for these type of solutions in a follow-up “consultative” session. If, coincidentally, the emergent understanding happens to align with the individual vendor’s product line, then so be it.

But it’s even worse than that.

Our buyer team, having been scolded into timidity, will write an RFP that now caters obviously to one particular supplier. Perhaps they understand this, so the buyer (sheepishly) waits to release the RFP until the Friday before the July 4^th long weekend at 5 pm, the netherworld for buried press releases and bid solicitations.

Anyone sophisticated reads the RFP and realizes that this deal is “wired” for a particular supplier. Unless they feel obligated by the relationship to write a proposal, suppliers drop out. A competitive auction becomes a failed auction quickly. The buyer scrambles to find respondents. An auction with three proposals is still an auction, right?

Even when the buyer does manage to convince several suppliers to respond, potentially by cajoling them with promises of a fair fight or better access on the next one, the default tendency for the committees that vet the final submissions is to lean towards the slick proposal. You know them: the ones with the great graphics and the jargon and the case studies. If there is an oral presentation, these people deliver beautifully.

Here’s the secret that nobody tells you: there is no correlation between proposal quality and ultimate value-for-money.

The better way to do this is, ironically, simpler.

First, the buyer should describe the outcome they want to obtain. If your problem is that you need to figure out how to handle snow clearance now that your current municipal fleet of snow trucks is getting older, then the outcome might be saying the City of Rimouski is interested in having clear streets within six hours of any snowstorm that deposits more than 2 cm of snow in a three-hour period. This would include a description of the constraints particular to Rimouski in the wintertime. This contrasts with the conventional response: issuing an RFP for snow trucks with an overly prescriptive explanation of what the trucks should look like.

Second, instead of being swayed by a glossy proposal, do real reference checks and speak with as many people as possible to understand the actual performance of different suppliers under real-world conditions. If you had to do it all over again, would you still select vendor A?

Very few people check references properly. They may ask the suppliers for the names of some referees, but these are cherry-picked for positive reviews. If you’re interviewing someone for a job, would you rather speak with their best friend or someone who was on the other side of a deal table from them? It’s difficult to find the right people, but it’s not impossible. Even then, you have to know the right questions to ask. Nobody is going to tell you outright that company XYZ is terrible. People are nice. People are afraid of litigation. Buyers need to be able to ask questions in such a way that their interviewees reveal their true preferences. This is an artform.

If the buyer can get this right, they obtain value-for-money nirvana.

You need the right tools, though.

This is what we have built at EdgeworthBox: a flexible RFP platform that enables outcome-oriented sourcing and real communication (not stilted pro forma FAQs) using our built-in messaging functionality. We can facilitate sophisticated vendor reference checks, too. We would love to hear from you. Please reach out.

This will enable us to refine our understanding of the customer workflows and to identify the different players on both sides of the table.

This is not our ultimate ambition.

We are developing Agentic AI models.

Before we can talk about what an Agentic AI approach entails, let’s start by talking about what some have called agent-based models. This is key to understanding both the status quo and the truism of the failure of almost every digital transformation project.

According to its most voluble proponent, agent-based modeling is a human-led approach to solving problems that stands in contrast to what he calls “equation-based modeling.” In the quote below, agents are individuals. They are human beings.

“Agent-based modeling (ABM) simulates the interactions of individual agents within a system, allowing for the study of emergent behavior that arises from these interactions. ABM is particularly valuable for capturing complex, system-wide effects that result from the interactions of autonomous agents.”

Strip out the jargon and the SAT words and the logic here is straightforward. The reason why so many software solutions and digital transformations fail is because they are inflexible. They do not account for the complex interaction of multiple agents using data and intelligence from a wide variety of sources. Every procurement team is different. Every project exists in an idiosyncratic context with unique institutional conditions.

Yet, traditional software approaches attempt to force people into a standard, one-size-fits-all approach to problem solving. This is good for the software vendor. He makes a fixed cost investment. Build a tool and sell it to millions of people. In forcing every different type of imaginable peg into their single round hole, the software vendor generates stratospheric gross margins for themselves. Operating leverage is a beautiful thing. For them.

You can have whatever car you want, as long as it is a Lada.

The end result is that large incumbent procurement systems cost a bucket load to implement and they still don’t work. Their vaunted inadequacies make everyone puck shy when it comes to technology.

The essential complaint that the agent-based modeling proponent appears to make is that procurement is a services problem because of its complexity. Software vendors solve for a software problem.

If a fixed income trading desk needs a machine to calculate the yield-to-maturity or duration of a bond, then you can build software for that. This is an example of a software problem.

If another company needs help understanding the risk of self-insuring the healthcare needs of its workforce, giving them an Excel spreadsheet isn’t going to be as helpful as hiring a team of actuaries to model out the risk based on situation-specific data, using their experience of other such problems and their special tools. This is an example of a services problem.

(As an aside, we built EdgeworthBox to be more flexible and to take into account explicitly the need for teams from differing backgrounds to interact around data in a contained space. We come from a financial markets background. We wanted to build a Bloomberg terminal for the real economy. We either work as a standalone solution or as a complement to the existing procurement technology. Ideally, we help people impose an idiosyncratic interaction on software designed for a standard use case.)

Procurement is a complex beast. The combination of simple building blocks and the peoplewho work these problems introduces complexity. This produces emergent behavior as people and data collide. No two snowflakes are identical.

What is Agentic AI then? There is plenty of confusion about this in the procurement literature, so I will refer to the people who are on the cutting edge of investing in Generative AI. Here’s an outstanding note from Sequoia, the venture capital firm based in Silicon Valley. I’ll try to explain the technology in plain English.

If you take away one conclusion from this note, it should be this key message. Agentic AI isn’t software-as-a-service. It is service-as-software. It is a fundamental disruption of the markets for consulting and outsourcing. Some misunderstand it. They descry it as a self-learning robotic version of the standard one-size-fits-all software approach, peddled by hustlers and snake oil merchants. Their skepticism stems in part from the novelty of Agentic AI and Generative AI and in part from the dismal history of digital transformation. The critics of Agentic AI see it as the same old priest preaching a new religion. This view is naive and it is wrong.

When most people think of Generative AI, they think of chatbots like ChatGPT or Claude. You ask the bot questions and it gives you answers. You might ask it to draft a cover letter for a job application or to edit some marketing copy. Perhaps you ask it to generate a PowerPoint slide deck.

All of this relies on the first wave of Generative AI: the foundation models such as OpenAI’s GPT-4o. These are pre-trained models. The AI companies pour as much data as they can find into as many GPUs as they can align to teach these models how to identify patterns. They are essentially built to predict the next word in a sequence, over and over and over again. They are not infallible. They “hallucinate” or make things up. They organize data into galaxies of multi-dimensional vectors. Think of this as space but with, say, 548 dimensions. It’s impossible to envision, I know.  When we ask for things, the models compose paths between these virtual, conceptual asteroids and planets and stars as they combine words and phrases to make sentences, paragraphs, and documents. They are better with some types of data, like software code, than others. Some of these navigational tracks turn out to be roads to nowhere. But that’s not to dismiss these magnificent machines. The model vendors are focused on identifying and weeding these rogue routes. They will succeed over time.

Sequoia makes the analogy to System 1 thinking in human brains. Foundation model behavior is nothing more than knee-jerk pattern recognition, not the in-depth reasoning of System 2.

Agentic AI is System 2. It breaks projects down into tasks. Think of the agents as people working on your team. Each one has a role to play. In a procurement, one team member may be tasked with developing a list of suppliers relevant to the problem. Another team member may be in charge of finding all the documents from previous related projects. A third team member may be responsible for collecting documents related to similar purchases, say from government databases disclosing contracts and bid solicitations from the public sector. We give them tools. We give them access to databases and the Internet.

The key to a successful Agentic AI implementation will be the way we coach these new artificial team mates to do their jobs. We will give them instructions in the form of natural language prompts that include prior examples of work that was good and work that was bad. We will expose the chain-of-thought that each agent needs to undertake. The agents will have pre-trained DNA from multiple models. They may have chromosomes from OpenAI and also from Anthropic. But in addition to this nature, we will nurture them. We will educate them as we would a child through school. They are inference compute, performing in-the-moment calculations that leverages their education to take advantage of the gifts of the dull calculus pre-trained compute necessary to birth them.

When they graduate from our school, when we determine that they have learned how to apply our various courses in working different kinds of problems, we will unleash them on the real world.

I can hear the Luddites now. This is nothing more than a jumped-up version of the Generative AI foundation models. They will not be any different. This is just marketing.

Wrong.

When I say “we” will nurture them, I mean human beings. This is called Reinforcement Learning with Humans in the Loop. A human expert (not a machine) will now build Agentic AI teams of agents designed for the idiosyncratic circumstances of the individual client. It is a human being who will coach them, iterating through different versions of a task-specific way of thinking about a particular problem: procurement within the context of an individual enterprise buying in a specific category. No two contexts are the same.

The Reinforcement Learning combined with human re-engineering of the application that sits on top of the foundation model will make for customer-specific AI. This isn’t the machine teaching itself based upon some incorrect reward model. This is human-in-the-loop optimization of the AI architecture for applications built for individual customers. There will be thousands of these apps. They may appear similar, but they will reflect the unique context of each customer.

One consultant will do the job of five. Perhaps company A’s Agentic AI setup can be recycled for subsequent RFx events. Maybe it will need to be tweaked for a different category. The human will take the initial feedback from the agents and grade their work, like a teacher in high school. The agents will learn. They will develop their own voice.

In practice, the agents will do the heavy lifting at the beginning, but it will be a human who oversees them, who coaches them, and who completes the execution.

The agents will use tools, in many cases SaaS solutions designed for specific tasks, e.g., making a payment to a vendor. SaaS vendors will have their own agents, riding astride their software.

Every company will have its own agents who have grown up inside the context of the individual firm. No two groups of agents will be the same.

The business model will be different, too.

Back in the day, software vendors charged for enterprise licenses and maintenance. Then cloud computing came along and vendors switched to charging for seat licenses. Now, Agentic AI will charge for outcomes. This is like paying a consultant on contingency. Imagine a company that comes to you and says, I have knowledge of the sales tax in the Province of Ontario. Let me go through your historical filings. If I find anything, I’ll take half of what I find. It’s a windfall for you, after all. If I find nothing, I will not charge you a penny. In this case, companies will pay Agentic AI for each procurement event that they prosecute to completion under human supervision.

Read the Sequoia paper. Discount it as Silicon Valley claptrap at your own peril. Ignore it and you risk ending up as a quaint telegraph salesman lamenting the use of fax machines. It does a wonderful job of explaining how Agentic AI will teach agents to have task-specific “cognitive architectures” that build upon the core pattern recognition of their foundation model ancestors.

This is why EdgeworthBox is starting with Generative-Procurement-as-a-Service. We want to map out as many different procurement approaches as possible with a view to this idiosyncratic Agentic AI customization in the future. We envision armies of enterprise-specific Agents executing in EdgeworthBox to exploit our repositories of structured data, communicating with their human-in-the-loop overlords using our messaging tools.

We’re open to talking to anyone about this. Give us a shout. Check out EdgeworthBox for more information.

EdgeworthBox, an innovative provider of procurement technology solutions, is proud to announce the launch of Generative-Procurement-as-a-Service. This suite of AI-powered services is designed to transform how organizations handle RFPs, supplier responses, and proposal evaluations, enhancing efficiency, collaboration, and decision-making.

“Our goal has always been to improve the coordination of procurement processes across different groups,” said Chand Sooran, Founder and CEO of EdgeworthBox. “With Generative-Procurement-as-a-Service, we’re bringing the power of Generative AI to procurement, enabling faster, more efficient, and more collaborative decision-making. By combining data, process expertise, and human judgment, EdgeworthBox augments leading-edge Generative AI tools. Offering this as a service enables both buyers and suppliers to streamline tasks typically performed by junior staff, accomplishing the legwork in a fraction of the time and freeing up senior staff resources. Technology alone isn’t enough. EdgeworthBox is built to help the people on the ground execute.”

The Generative-Procurement-as-a-Service offering includes:

• AI-Driven Statement of Work Generation: Enables organizations to draft a comprehensive first statement of work using public sector procurement data, significantly accelerating the RFP creation process.
• Supplier Response Accelerator: Assists suppliers in drafting responses to new RFPs based on their historical submissions, ensuring faster and more consistent responses.
• AI-Assisted Proposal Evaluation: Supports buyers in evaluating and ranking supplier proposals using a tailored “answer key,” enhancing both the speed and accuracy of the decision-making process.

This new offering is the latest step in EdgeworthBox’s mission to redefine procurement through technology and expertise, providing a smarter, data-driven approach to RFP management.

For more information about Generative-Procurement-as-a-Service, visit www.edgeworthbox.com or contact us at sales@edgeworthbox.com.

In this story, there are many different players.

First, there is the business. There are various trading desks focused on derivatives in different asset classes including asset-backed securitization, equity derivatives, mortgage-backed securities, corporate derivatives, and foreign exchange options. Each one of them is made up of hard chargers, individuals focused on performing at the highest level. They want to get paid; they want to get promoted. They do not have much patience for bureaucracy. It’s highly unlikely that one group works well with the other group, but they’re all important to the bank. Their work is very technology-dependent. Many of them have specialized expertise in technology. They are highly educated. It’s not uncommon to see PhDs on business cards.

Next, we have the technology group, all of which reports to the Chief Technology Officer. They are responsible for making sure that the line business gets what it needs and for ensuring that it stays up and running. This is not as simple as it sounds. It is a complex, interdependent system. They need to make sure that the various products they buy play well together. They’re responsible for guarding against cybersecurity threats. But they’re still at a bank and the traders rule the roost. If they worked at a pure play technology company, some of them might be senior power brokers within their organization, but here, they play a support role. It’s a vital position, but nevertheless, it’s secondary. The traders print the profits. Working in technology is a good job. They get to deal with leading-edge systems. It is challenging to make sure that everything fits together and keeps running. They’re constantly learning. But still. They’re not in the driver’s seat. And they’re very status conscious when it comes to anyone other than the line business.

There’s management. They hire the traders. They raise the capital and manage the bank’s compliance with various regulators. They keep the shareholders happy. Management needs to see over the horizon anticipating the kinds of business that might be exciting and relevant in the future. They must recruit the best and the brightest and keep them paid and fed, otherwise they’ll have staffing issues. It can be difficult managing the prima donnas. Heaven forfend they have employee turnover. The bank can have the best technology in the world, but if they don’t have the right people in the “front office” trading seats, it’s all for nought. And one reason traders leave for greener pastures is inadequate technology.

There are the risk management and control functions. These people enforce adherence to the rules so that the traders don’t blow the place up with bad trades, or worse. They measure risk, report it, and make recommendations as to how to optimize it. But it’s not just risk. There is financial reporting, too. There are controls in place to ensure that people cannot embezzle funds. Everyone remembers Dr. Copper from the mid-1990s, a trader at a Japanese bank who lost hundreds of millions of dollars by taking advantage of weak controls, poorly enforced.

There are other corporate functions such as legal to reinforce regulatory compliance. They manage the bank’s legal risk, whether it be its exposure to litigation with clients and other counterparties or its reputational risk from engaging in certain transactions. There is an investment bank with corporate clients, some of which are vendors to the bank as well.

And there is procurement. Whenever there is a large purchase, say for some new technology, the bank has a procurement department who ensures that there is a proper RFP, in addition to the rigorous testing the CTO must execute. It’s important to generate competition on price and solution so that they know and can prove to their stakeholders value-for-money.

Let’s add some more context here.

In the past, there have been problems coming out of the various trading desks when it comes to procurement. The first step is to generate a set of requirements. What is the problem that the trading desk seeks to solve? What must a solution be capable of doing?

Historically, the traders have tended to game the process in two possible ways.

First, in putting in a request for the funding to purchase a system, the traders have fudged the requirements. Instead of describing the problem they have and the things that any potential solution will have to do (or should be able to do), before putting pen to paper, the traders decided on the system they wanted to buy. Then, when they put together the requirements (and working with the salespeople from the company that makes the product they want to buy), they structure the requirements document to emphasize the things at which their desired solution is good and to ignore (or, at least) discount the things at which it is bad. They are so ham-fisted in their reverse engineering that the procurement people can see through it. Their description is so skewed that it limits the logical selection to just one vendor: their supplier of choice.

Second, since they are dealing with corporate money (and not funds that will affect their bonuses), they ask for more than what they need. So, in addition to distorting the description of their actual requirements, they embellish them so that they can purchase more bells and whistles for the vendor’s existing product or they can buy several additional products at the same time. If their real requirements were for a simple pen knife, they would ask for a Swiss Army Knife that had to be made in Switzerland and needed to have the Swiss cross with a red enamel handle. These traders get promoted and paid based on how well they do; they do not get paid based on the bank’s share price.

The procurement department is well aware of this problem. So they lobbied the Chief Financial Officer and the Chief Operating Officer to give them complete power over all procurements above some threshold of value, say $1m. The traders can make recommendations when it comes to the requirements, but the procurement department now sits in the driver’s seat. There is some input from the CTO’s office. Sometimes the procurement department listens to the business’ preferences, sometimes they don’t.

The business and the CTO group resent the procurement department. Who are they to tell them what to do?

In some cases, the investment banking department gets a whiff that one of their customers is trying to win a deal with the bank for their technology. The investment bankers will try to lobby on their behalf. Synergies.

Over time, the bank has evolved a cumbersome way of handling these projects to account for these behavioral distortions and cross-departmental lines. Practically, it means that a project that should take six months takes twelve to eighteen months to complete. It means that something that should have cost $100 comes with a total cost of $200. And because the process is so complicated and difficult and opaque, there are often legal challenges when a supplier who was convinced to invest in an expensive proposal loses, causing in turn further delays and further increases in costs. What’s worse, the timeline for implementing the solution in the business gets pushed out, so that the business’ ability to make money from a new revenue line or to lower costs is delayed.

Some of the other banks notice and begin to steal our bank’s clients. Our bank becomes less relevant in the marketplace.

How would we fix this setup?

One problem stands out straightaway. In the language of Silicon Valley, there needs to be “one throat to choke.” Ideally, there should be someone who works in the office of the Chief Financial Officer or the Chief Executive Officer who is in charge of overseeing the technology projects that exceed $1m in cost. This one person is responsible to the CEO for getting the best outcome, shortening the procurement cycle, and lowering both transaction and opportunity costs.

Given the fact that there are people from across the enterprise involved in the purchase, there needs to be a cross-departmental committee in place before the requirements are laid down. Instead of asking the bankers to form the requirements, these need to be developed by the entire committee, including people from technology, procurement, compliance, legal, and finance. This obviates the gamesmanship.

There needs to be a common technology system so that people using different systems and with little experience in procurement can access the procurement projects and do everything they need to do in one contained space. The procurement function for most of them will be an adjunct position, an additional duty to their primary roles within the firm. They don’t want to log into five or six different systems.

Just as there is one throat to choke, there needs to be one place to work on this project. The user experience of this platform needs to be intuitive and simple to use. Ideally, it will be plugged into the procurement system of record via application programming interface. In a sense, this platform is the layer that broadens the reach of the procurement system, exposing data and collaboration, all with an audit trail that tracks internal performance measures..

This platform will also be the place for vendors to interact with the buying committee, sharing information. The RFP takes place in this digital platform. All the communications are easily reported to authorities like the SEC. The simplicity and transparency is proof of fairness to the vendors, along with tools to help them reduce their costs.

Get this right and the bank shortens the procurement cycle, reduces the number of challenges, and attracts the level of competition on price and solution necessary to obtain real problem-solution fit at a reasonable price.

This is what we have built at EdgeworthBox, a dedicated, contained system for executing RFPs and coordinating large complex groups internally (and externally). Let’s talk.

As a member of the AWS Partner Network (APN), EdgeworthBox empowers customers to accelerate procurement cycles, increase supplier engagement, and cut transactions costs by optimizing the group buying process. Whether aligning an internal team of stakeholders, managing a network of contractors, or collaborating with other buyers, EdgeworthBox digitizes the most challenging aspects of procurement. Our platform provides a centralized, dedicated space for coordinating procurement efforts, ensuring problem-solution fit and maximizing value-for-money in the RFP process. EdgeworthBox can be used as a standalone solution or as an enhancement to existing procurement technologies.

“We are excited to expand our partnership with Amazon Web Services by joining the AWS Marketplace. This development streamlines the purchasing process for our customers, particularly public sector organizations, by making EdgeworthBox more accessible. Our platform is designed to help these organizations secure the right solutions from the right suppliers at the right price,” said Chand Sooran, Founder & CEO of EdgeworthBox.

To explore how EdgeworthBox can enhance your procurement processes, visit our listing on the AWS Marketplace or learn more at www.edgeworthbox.com.

EdgeworthBox.

##

About EdgeworthBox: EdgeworthBox is a set of tools, structured data, community, and market intelligence that streamlines the way businesses purchase goods and services. It makes it easy to execute RFPs, RFQs, RFIs, or any other kind of reverse auction, while promoting collaboration, both internally and externally. Companies use EdgeworthBox to replace the chaos and complexity of email and spreadsheets to manage reverse auctions or to insert it as a complementary layer that improves an existing procurement technology installation. Additionally, different organizations use EdgeworthBox to issue and manage joint RFPs to obtain scale economics.

Contact: Sales Department, EdgeworthBox – sales@edgeworthbox.com