Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Building a Self Service Portal

Posted on: 10 May '13

Self Service Portal or SSP is one of the key components in any Cloud based solution. The use case for a SSP is to enable the end-user to request a product or a service and have it delivered. A request at SSP could involve a workflow where the user may have to select various options and may also need to make a payment. Once the process of making the request is complete, the next step would be to satisfy the request.

Satisfying the request can be done in two ways, manual or automated. For the manual case, it will mean that the IT team will be involved in processing the request and this could lead to back and forth with the requester if there is an ambiguity with the request. Depending on the nature of the request, the time to fulfill a request manually could either be instantaneous or time consuming. In contrast, if the process of fulfilling a request is automated, the time taken will usually be the same, though the request could get a positive or a negative answer.

For automating a workflow, it is essential that the rules or policies for fulfilling a request need to be defined clearly, along with what needs to happen when a request cannot be fulfilled.

Typically, the skill set required for manually fulfilling a request is the knowledge to configure / provision a service or product whereas for automation, the skill set required is to be able to program using the published interfaces of the service or product to achieve the needful.

The SSP is one of the components of VMUnify and building it has been a challenging experience. SSP is the place where the user or the consumer meets the provider. The provider wants to make this experience unique and successful. The simplest way of making the experience unique is to give the ability to the provider to put in a new name or logo, also called as White Labeling. This could be extended to also be able to change the fonts, background and similar attributes. However, the true unique experience will only come when the provider has a chance to define the workflows, success and error scenarios, etc. It’s an engineering challenge to provide a totally unique SSP to every user when it is tied to a product.

Do you have experience in building unique SSPs when tied to a product? How did you handle the engineering challenges of supporting multiple SSPs?