In the past, I have talked about collaboration opportunities in SaaS environments where similar business run their operations and one can get some input or intelligence from the other, here http://tchristidis.blogspot.com/2011/01/collaboration-in-saas-environments.html . Also, I have talked about how a SaaS application forms a kind of community which can assist users to exchange ideas and increase the usability of the software, thus maximizing the investment they have done in their SaaS solution, here http://tchristidis.blogspot.com/2011/10/saas-applications-and-their-community.html.
Today, I am elaborating on some details and investigate if and how a SaaS environment can be used not only as a means to execute daily tasks but also as a business enabler for the on-board users.
The basic idea is that a SaaS database contains valuable data of the on-board users, such as services they provide, product catalogues, availability of their products etc. Businesses with some kind of co-relation (e.g. a Service shop that services automobiles and a Parts supplier of that service shop) may stop for minute and think how this potentially common database can assist them to do business together and increase productivity, while providing better service to the customer. A service shop would typically stop at a customer’s inquiry by saying “sorry, that accessory is not available”. But, what if they could instantly add “…but I can get it for you in 2 days…”.
Recently, I was discussing with a retail professional who said to me that he was thinking about approaching other retailers in his area and propose some kind of discount scheme if customers from one shop visited the other (obviously, their products were not antagonistic, but complementary to each other). If a customer visited shop A to buy, say, some meat, then he would instantly gain some discount on shop B which sells fish and vice versa. A great idea, if you ask me, that talks about collaboration in the real world. Now, imagine this in the virtual world of SaaS. Customer goes to shop A and buys meat and the SaaS platform automatically registers a “earned discount” for shop B. When customer visits shop B, he doesn’t need to say anything. The cashier sees that there is a “earned discount” and immediately assigns it to the receipt. Need some kind of verification? Easy. The two businesses of the example reside in the same database. Therefore data exchange is possible; so is a more sophisticated workflow (if need be) between clerks of businesses A and B (in order to verify, authorize etc.).
One could expand the above case to a more sophisticated loyalty scheme that stretches beyond the physical boundaries of business A. What if there was an easy way so that loyal customers to business A could enjoy benefits in business B, too? (further business analysis is not my intention today, but I think you get the point!).
Another example is that of a retail shop that finances its sales through personal loans. The retailer already has the basic data that the bank needs for its loan application process: The customer data, the goods sold and their value. What if that data could be transmitted to the bank and get an instant response with zero effort from the retailer. Of course, such “interfaces” or EDI can be built between any two systems, but that would mean customization effort and a combined project between the two businesses and their two software vendors. New web services would need to be built, security issues could arise etc. But if these businesses were running on the same SaaS platform, then the technical difficulties would be much lower, since there would be one I.T. vendor that would only need one internal process to decide how that business enablement can be implemented in that one, shared database (of course, in that simplified example I choose to overlook how a bank would choose to implement its loan approval process in a public cloud, but that’s another story).
Perhaps this kind of functionality requires some customization but it is my belief that horizontal SaaS solutions that support some kind of workflow and also architecturally allow some data sharing can be the vehicle to such business-to-business collaboration. And my point today is that SaaS ecosystems can also work as business enablers for the parties that have subscribed in that service.
Popular posts from this blog
Through this channel I have been talking about the advantages of cloud and SaaS products for a long time. In this post I’d like to focus on a more specific area. An area that contains a large pool of potential customers, who at the same time are still facing basic problems in their journey towards a “computerized enterprise”. That of small business ERP and especially the Financial ERP. By the term “Financial ERP” we define the software that performs the basic functions of book-keeping, sales and purchases, stock keeping customer/vendor order management and perhaps some more like basic workflows and some kind of business intelligence. These are requirements that small and medium-sized businesses are seeking to approach first, or they have already done so with not much success. Also, they are the kind of requirement that start-ups are trying to cover, since they touch the back-bone of the business function.
The relationships between customers and providers in the cloud business are generally governed by the Service Level Agreement or SLA. In a previous post I made the point that a really “tough” SLA is probably not the “holy grail” of the cloud business, which every customer should be looking for. In this post I will continue the same line of thought, focusing this time in the impact that a strict SLA has on the customer organization itself. For this purpose, I will use the term “Reverse SLA”.
In this post I will dive into the waters of Customer Ranking techniques and how they can be supported by the existing Small Business ERP that is in use. By the term “supported” I not only mean extracting valuable info as per the customer’s behavior (and thus be able to make decisions about their credit situation) but perhaps also the software being able run the entire process. Of course, such processes do not apply to all kinds of businesses. In this discussion, we assume the business model of a company selling B2B and in credit. Obviously, for a B2C sales model that is being served by, say, an e-shop where all sales are cash, there is no reason to examine low-volume, private customers.