Chris Reddick (President and CEO of Clarity Ventures) and Ron Halversen (Vice-President of Sales and Marketing) talk about the importance of listing the features you need, those you want, and those you can ignore.

Part 2 of an 8-part series (Return to Part 1)

RON: So the next one is features. So a couple of the features—before you dive in and talk about those—obviously we've got ones like a comparison engine, right? If I'm going out looking for a specific product on a marketplace website, theoretically I could go look for that product and I could see that product available across multiple vendors and I could compare price, or I could compare lead time, or maybe they have a different warranty for the same thing, right? 

So comparison is a big one. Being able to filter out and see more things from the seller, being able to communicate with the seller, ask them questions about the product. But I also want you to dive in a little more, like some of the ones we did on the pool one, where we had hard and soft stops. We had the ability to go in and manually do website quotes where people could go in and say, “Hey, Mr. Vendor, are there any vendors out there that if I buy 100 units and I'm willing to pay 100 bucks,” where they can put out a threshold to say, “We'll accept up to this price and it'll auto-accept that, or it won't because it's outside the threshold in an auto-sense.” 

what is hipaa

RON: So there's some really complex things that I did not explain well. But if you can dive into some of those, I think the core features most people know, I mean, I think we've all shopped on Amazon. I think they're the king of eCommerce marketplaces, or Alibaba. Everybody's been there. Everybody shopped on there. So we all know the basic functionality of seeing the sellers and comparing the products related products and all the basic core features.  

On your checklist, make sure to write down the basic stuff that you want to make sure [to get], right in your B2B marketplace software. So when you go shopping for your platform, you can get a demo of those core features. The most important thing though is, is the platform scalable and customizable for the additional core functionality that your business needs? And that's really what I want Chris to dive into now, right? Some of that hard stuff like hard and soft stops and manual quoting and auto-threshold acceptance of B2B auction bidding and some stuff that we've seen that’s unique to our clients, right? 

what is hipaa

CHRIS: Yeah, that's a great point. And I mean, I think it's really probably the most important thing to take away from this checklist when you're looking at software is, can adapt to my scenario? Because one of the things that led us to create a marketplace website software, for seven or eight years we worked with off-the-shelf tools exclusively.  

And what we found in that process was that the last mile, the last five to ten percent off functionality tended to be such that we were literally painted into a corner, because we had completed ninty to ninety-five percent with this, quote-unquote, off-the-shelf functionality. But the business, in order to fully realize its objectives of self-service and low friction for the users, it really had to have these three capabilities. That's where the bottleneck in the B2B marketplace solution was.  

Frankly, Ron, this has been an accumulation over those seven to eight years, and then ten years after that, of validating it for the entire ten years—this is really the bottom line. You need a set of core features, and you really do want to understand what are those core features are. And there should be a reasonable set of core capabilities within whatever marketplace platform you choose. 

Most importantly—and this depends on your business, if your business is mature enough or is complex enough that you know you need certain things and you know that they're bottlenecks, or you are projecting that they reasonably will be—does the platform you're working with really have a set of architecture that is friendly toward that? 

And what do I mean? Well, let's just take an example. Let's look at the example of Legos versus clay. You know, clay is great. You can make whatever you want, but once you bake it, it's set. And I'm not a clay expert, but I don't really think a lot of people add more clay after the fact. 

But with Legos you can add and remove as you need. And ultimately the point is , once a platform is set in stone, if it's not well-made, it's going to be like clay that's been baked. It looks really good, it's really cool. It can be used for that specific purpose, but really not a lot else. And it's brittle, and if you if you crack it, it's gone.  

Whereas with Legos, they're really made to be interchanged. And with our software, that is very much the case. Add B2B auctions, add a marketplace. Depending on how the software was architected and written, it can either do really well with a specific set of tasks, or it can do really well at the specific set of tasks and be adaptive to new tasks. 

If you think about it, what is the basis for B2C marketplaces? Was it made to be adaptive, and was it made to be compatible with changes and adaptations that you're going to have? And without going into super detail on the technical front, I will just say that some keywords that you should look for are things like “plugins” or “modules,” the ability to “override” or “extend.” And then look for examples of where, mechanically, you can see that, “Okay, all of these different areas of this eCommerce marketplace platform were overridden, and I can see actual examples of that. And it's a viable solution.  

One of the key questions that I would always ask around that is, what are the limitations? What are the areas that can't be extended or overridden, and why? If you get those answers, you can understand what the limitations actually are. The answer should be, effectively, there are no limitations, but there may be more overhead to overriding or extending a core feature, and you need to know what that is, ideally. 

RON: Yeah, my big litmus test is the API, right? As I'm doing demos, I have a lot of people come in and ask us about our marketplace eCommerce platform and we start talking through that and they're like, “Well, how does it stack up to this?” And they'll say, “Well, have you looked at the documentation for the API for that B2C marketplace?” 

And they're like, “No,” and we'll Google it, we'll open it up and we'll walk through the API together. And I'll show that most APIs out there have anywhere from about 200 to 500 endpoints. Right? And they're like, “See, look at all the stuff it has there. It's all documented. It can do everything.” And I said, “Yeah, watch this.” And I pop into our B2C marketplace platform, I go to the API documentation, and we have over 11,000 endpoints documented within the platform.  

So when you start taking 500 endpoints and 500 functions that you can do within a platform to 11,000, they don't even compare, right? Our platform was literally made to be infinitely scalable and was designed that way first, even with ERP marketplace integration

So for me, the litmus test is, I go look at the API. So once I write all my features down, can I go in and integrate all those features? For example—I'm not picking on WooCommerce, it's the most widely distributed eCommerce plugin in the world—but WooCommerce has about anywhere from two to 400 endpoints, depending on which documentation you're looking at. 

But it doesn't do B2B invoicing at all. So when you go to B2B eCommerce, and we try to go integrate that with—I've got clients that have WooCommerce on the front end, but then they come to us to integrate Dynamics AX on the backend, which those two just don't even sync. But now all of a sudden they've got all this invoicing and all this multi-warehouse. It got all this capability in their ERP that can't be exposed in WooCommerce, because even if there's a plug in that adds B2B invoices generation to WooCommerce—which there is—those plugins don't extend the API. So now we don't have the ability unless we directly integrate directly to the database, which everyone knows is not the way to integrate. 

This is the most important reason, for me, why you get these features written down, so that you can go validate the true capability to extend and support that functionality when you build a multi-vendor marketplace in the future.  

Continue to Part 3 to learn about the importance of a 3-to-5-year plan.