The UIX One Should Expect from Best-In-Class Auctions, Part II

Last week we dove deep into the basic general requirements for any e-Negotiation platform, namely e-RFX and e-Auction, and called out the need for easy template creation and easy starting bid population and validation as two necessary key requirements (among a set of requirements). (See: Best-in-Class e-Sourcing Part I and Best-in-Class e-Sourcing Part II.)

However, as we explained in our last post, the requirements for auctions go quite deeper than the requirements for RFX. In our latest article over on Spend Matters Pro [membership required] on What To Expect from Best-in-Class Reverse Auction Technology and User Design (Part 2), the doctor and the prophet dive deep into specific capabilities required of modern e-Auction platforms in order for a user to have a great experience.

In our article, we define three absolutely requirements, as well as two requirements that will soon be absolute, for every e-Auction platform that wants to be a modern platform, including real-time connectivity monitoring.

As we state in our article, internet and software connectivity should never be taken for granted. This is a lesson one of the authors originally learned over 15 years ago (first hand) when helping run early online sourcing events at FreeMarkets. However, even today, many platforms still take this for granted, assuming that everyone has the reliable, redundant internet infrastructure of a modern first world data center. This is still simply not the case. Your supplier representatives are probably located at their factories in the middle of Nowheresville in the Lost State of Third World Country and might still be on a 1.54 Mbps T1 connection, which is only up on good days. Their data centers might be located in the nearest city, which barely has enough electricity to meet demand on a good day (when the AC or Heat is cranked up in every home and building), and subject to occasional rolling brown-outs. And so on.

The fact of the matter is the software should assume that suppliers can, and at least one supplier representative will, lose connection during an event. And if this happens, the supplier still needs to be able to bid. A modern platform allows for each supplier representative to designate one or more proxy bidders, in priority order, and if the main rep is unable to establish, or maintain a connection, the software will detect that and automatically switch the bidding designation to a proxy (who will be view only until he or she needs to take over bidding). In addition, the loss of connectivity and change of delegate will be noted and the buying organization notified.

In addition, it will detect if multiple supplier representatives lose connectivity, assume there is a major issue, automatically suspend the event, and notify the supplier representatives through other means (e.g. backup emails, fax, and/or even SMS) that the event has been suspended and will pick up either the designated back-up time or at a time to be communicated by the buying organization as soon as the issue has been identified and resolved.

This is necessary not just to maintain good supplier relations, but to prevent costly legal challenges, especially in the public sector, if an organization lost because it couldn’t bid through no fault of its own (and could prove that it was willing to make the lowest bid which, in many jurisdictions, requires the award to be given to that organization). But yet, a [large] number of auction providers (of the 50+ that the authors collectively know about) do not provide this capability.

Curious to know what the other four requirements are? Then check out our full piece over on Spend Matters Pro [membership required] on What To Expect from Best-in-Class Reverse Auction Technology and User Design (Part 2).

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>