SaaS: Collaboration
Yesterday I set the stage for the 5Cs of Saas: collaboration, community, connectedness, completeness, and changeability. Today I'm going to focus on collaboration in SaaS. As I mentioned yesterday our team found, through customer interviews and research, that a motivating factor - one of the primary factors - for SaaS purchases is to allow seamless collaboration between parties in arbitrary (but well-defined) roles.
Well, what exactly does this mean? From our perspective it means that an actor using the software has full, role-specific privileges and experiences directly within the software. That is, there's no concept of a "portal" or any other external "connector" to the software. It also means that the provisioning of that experience is seamless to the actor doing the provisioning.
An example here might help explain this. Let's say we have a customer support representative using a customer service application. This person receives a phone call or other trigger causing them to describe a customer to the application. Now, in a typical application, this means that there's a user, the customer service representative, and a customer. These two concepts are typically quite distinct in their semantics. The user has access to the application and, by definition, can use it. The customer is a data point somewhere in the application represented by a row in a database, but has been granted no additional rights.
In a collaborative world this model breaks down. There's a distinct difference in the caste model: in some way the user is a higher caste entity than the customer. The user can create new data items and fully interact in business processes. The customer is disconnected from the application and may be able to "interact" via some external connector (for example receipt of an email message or a message exchange).
What we found was that our customers want us to remove this divide. They want to see the customer as a first-class, privileged actor in the application. But, and this is important, they do not want the customer to be a user in the application in a way that either uses a license or requires a specific provisioning step. As you might see we have a bit of a dilemma here. Most business software written to date enforces this divide. We can't use the existing models.
What can we do about this? Well, we could fake it and create an additional layer on top of the business application which provides some level of interaction for the customer. But, this means that any customization that takes place in the core application must be duplicated in this additional layer. It's not only that, but any business logic or business process which is enacted in the core application must be augmented so that it explicitly takes this additional layer into account; and this business logic must typically be duplicated, often in a different way, in the additional layer. This doesn't sound like a good thing.
What customers want is a single application, with defined identities, playing well-understood roles to collaborate around a given business process. Additional layers only mean additional work. That is, customers want to treat their partners as if they are first class citizens in the business process.