iServices - Enabling Crowd Commerce

My last blog entry discussed the different options on how to define functional processes within the iServices application. As I have been too vague on the context the application will be implemented for, this article gives you a rough overview on the ideas, concepts and features thought of so far.

It all started with a beer and a discussion with a friend of mine about an idea for a web shop. At its core heart it was quite the same where the products would come from as the set of services surrounding the product portfolio were its unique selling point. One approach provided that we would use one of the several affiliate services and assemble the product catalog from it. This was accompanied, however, that we had to stick to the rules of such services, eg. forwarding the customer to the product owning shop for closing the ordering process (see shopping24.de for example). But that was not we were looking for, we wanted to have an independent shop where the ordering process would be transparent for the customer regarding the product owning web shop or the deliverying party.

The following days the idea intrigued me further since it seem to be an interesting approach for product owners and web shops (or alike) equally. Product owners, even small ones, could provide their catalogs along with any additional information to an arbitrarily large number of web shops/sellers, whereas web shops/sellers can select products, even those they would probably have no access to as their purchase quantity would be far to small, from a large unified catalog. For both it would be somehow a win/win situation.

In my mind, these thoughts formed the picture of a busy bazaar or hypermarket where participants trade with each other equally. Due to the concentration of supply and demand, all participating parties benefit from this setup. While thinking on how to summarize this picture at its best, the term Crowd Commerce came to my mind.

As I still was searching for a context that I could use for showing that asynchronous architectures are suitable for ecommerce systems as well, it was quite obvious that the scenario described about would be the perfect match. It was then that the idea of something like a bazaar or marketplace connecting product suppliers and sellers in n-to-m relationships for increasing sales numbers for both participants was born.

The core features of the concept are described further below, split up into different two view points: product owner view and web shop view.

Product Owners

• product owners provide their product catalog along with media, availability and other information possibly required by web shop
• they decide where the products are allowed to be incorporated into: theme shops, special shops only, all shops, shops requesting a specific compensation at maximum ....
• they receive orders from an arbitrary web shop for their products and fulfill them
• fulfilling orders might be done in their own name or with a special label of the shop that forwarded the order
• provide the platform with updates on order states as well as product availabilities
• might change the availability of a product between different web shops incorporating the product due to compensation or selling rates in order to max. the numbers

Web Shops

• select and consume products from the platform catalog if they were cleared for it by the owner
• use the platform processes to place orders for products belonging to the product
• use the infrastructure to handle payment processes

There are some more ideas and visions but it would lengthen the blog entry unnecessarily.