Many organizations are now paying attention to the development of their customer-facing self-service channels, with some of them already developing the second or third generation. Many customers are already accustomed to good self-service channels; online banks are good examples of services with a long lifespan.
North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.
23 August 2016
Public administration, cities and insurance companies, to name a few examples, have lots of reasons to focus on easily usable self-service channels. Some are advancing beyond self-service by building online stores and other additional service offerings inside their channels. The Finnish telecom operator Elisa is a good example.
As far as typical websites and standard online stores go, dramatic improvements have been introduced during the past decade. Only few customers need to build their online store as a tailored project (although sometimes the exception proves the rule…).
In self-service channels, though, lots of the work is still custom coding, and even if off-the-shelf products were used, usually customers end up with a large amount of tailored code on top or beside the platform.
Why is this? Are things moving towards the better?
Answer: Yes, they are moving towards the better. The challenge is that things are moving in many directions simultaneously.
In fact, things used to look pretty straightforward at the end of the 2000’s and the beginning of the 2010’s when all Microsoft clients insisted on building all their services on SharePoint. That hangover, fortunately, is passing.
Even Microsoft now supports something different. Microsoft is throwing all its weight behind its Azure cloud platform and encourages everybody to code their services in Azure as custom implementations.
This isn’t a bad message in itself, but will undoubtedly change the moment Microsoft shops another platform to its product portfolio.
Platforms, namely, are not nearly dead, not even portals, although even I have actively wished for their death over the years.
Fortunately, we have gotten rid of the most horrible portal platforms. The Liferay portal, popular in Finland, is not at all a bad platform if your needs can be satisfied with a portal solution.
Customer-facing self-service channels, however, can be built in myriad ways. A rough way of dividing top-level technology strategy approaches (what a mouthful) results in four alternatives:
- Buy a portal product, integrate everything into it and customize all customer views on top of it.
- Customize all customer views on top of your most important business system, such as CRM.
- Focus on API layer and custom-build self-service channel applications.
- Focus on identity and access management and use it to open up a limited direct view of your business system.
Let’s take a closer look.
Model 1: Build on a portal
Perhaps the most typical basis for a customer-facing self-service channel is to build the services on top of a portal. In fact, Microsoft’s SharePoint also represents this model in the case of self-service channels, even though you can’t quite call SharePoint a thoroughbred portal.
At the moment, however, Microsoft Office 365 is developing in a totally different direction in comparison with traditional portals, such as Liferay.
The most common portals in practice in Finland are Liferay and IBM’s portal solutions. Some Oracle portal products are also being used.
The primary benefit of portal products is that they offer a little of everything. They allow lightweight integrations into backend systems. They usually include pretty good user and access management out of the box. They usually have decent CMS functionalities, such as content and lay-out management. Experts are mostly available, and over the years, especially Java-based portals have developed some shared practices.
All this makes portals good “universal tools” for building customer-facing self-service channels, particularly if the services have to meet many kinds of needs and expectations. Building on a portal could be called a safe basic solution.
This safety and universality aren’t always the only reasons. Sometimes the point is simply that it can be a lot more cost-effective to build on a portal than, for example, buying separate identity and access control system, or expanding a business system, such as Salesforce, into a self-service channel.
Particularly when building self-service channels with a long lifespan as the requirement, portal solutions may prove the winning solutions. This is why, for example, public administration often favors service channels built on portals.
Model 2: Build services on top or on the side of a business system, such as Salesforce
Sometimes, customer-facing self-service channels are so heavily dependent on a single business system that the most reasonable alternative is to bolt the service views tightly on to the business system.
For many organizations, this central business system could be the CRM system, in which case it might be sensible to also build the central views of the self-service channels on the side of the CRM, for example using the interfaces CRM offers.
At the moment, particularly Salesforce is actively pushing this model to many organizations, even to clients who do not use Salesforce as their CRM solution.
Salesforce’s model is very reminiscent of the earlier SharePoint boom where clients are enchanted with the supposed “platform properties”, although the end result is usually nothing but tailored coding. The only difference in respect of custom implementations is that in addition to maintenance, you have to pay high license fees to Salesforce.
Building self-service channels on top of a business system is most often the hardest to recommend, because the model does not lend itself easily to future expansion without an even tighter lock-in with the business system in question.
For platform suppliers, such as Salesforce, this model is of course comparable to claiming the best gold deposits in California with an infinite contract. It’s hard to blame them for promoting their model.
For the client, the model usually makes sense only if 90 percent of the self-service channel functionalities and views are really produced by the business system.
For example, if the self-service channel only allows customers access to update their own details, browse their contracts and maybe send service requests to the organization – and all this takes place within the CRM – then it may be a good idea to create the customer interfaces of the services on top of the business system. In other cases, the model will most likely lead only to an unproportionally tight vendor lock-in for a single business system.
Model 3: Focus on API layer and custom-build self-service channel applications
The third model is probably the most “beautiful” as far as architecture goes and therefore often the model favored by developers. The model is also actively promoted by many software development companies, who of course detect large-scale custom coding markets in the model.
The model makes a lot of sense. It won’t be cheap, but may offer a lot of possibilities in the future.
The basic idea is to abstract business systems behind a separate interface layer. The self-service channel applications are not integrated directly into the business systems. The applications only communicate with the interface layer (API layer).
This model has been hyped for years in trade magazines, and it has been given many names, such as Service-Oriented Architecture (SOA).
This model, correctly implemented, is beautiful for the IT administration as business systems behind the interface layer can be changed fairly flexibly, and the customer-facing services are not easily interrupted.
Also, services provided for customers can be renewed fairly often without touching the backend systems or integrations.
This is why big B2C companies, such as telecom operators and banks, often place their bets on such architectures because they provide the possibility of rapid changes in services and applications visible to their customers.
The flip side of this model is that the implementation of the interface layer is easily an exercise costing hundreds of thousands of euro, and in itself, does not provide any visible benefit anywhere.
Only when new services are built on the interface layer, the benefits start to slowly appear.
In general, the benefits of this model only manifest themselves when you genuinely develop a lot of services for customers or make a lot of changes in the backend systems.
Usually, the organizations using this model have genuinely multichannel needs, such as many mobile applications for their customers or several different extranet solutions that use the same backend systems and place orders in the same product databases.
A rule of thumb could be that the more multichannel customer experience and the more heterogenic backend system architecture you have, the more likely it is that investing in a competent interface layer is beneficial in the long term.
In the short term, investment in an interface layer is always a challenging proposition because visible benefits are scarce.
In this model, the applications visible to customers need not necessarily be custom-made. For example, many organizations offering online commerce use this model but still use an e-commerce platform to run the webshop visible to the customer.
When implementing customer-facing services, however, this model favors a “small application concept”, that is, a model where fairly independent, small applications are created and where the starting page opened by the customer may even look a lot like the opening page of a smartphone.
Such a small application model is, of course, sensible for other reasons in today’s environment, because it is well applicable to mobile use and enables fairly independent small-step development for the different parts of the service.
Model 4: Focus on identity and access management
The fourth model is perhaps most often used for scenarios between companies (B2B extranets), because it is usually desired that consumers be offered fairly consistent user experience and not ping-pong consumers in several different systems.
In the B2B realm, ping-ponging is more acceptable, even ideal, because professional users can be offered a direct access to specialist applications where they can operate with user rights similar to the company’s own personnel.
For example, many large importers use this model to open up direct access to their order and inventory systems for their resellers without building a separate service layer (such as on top of a portal system).
This model focuses on creating a versatile identity and access management solution and connecting central business systems directly to this system. It offers users login services and, for example, a simple start page to start a variety of applications. The identity and access management system (such as offered by GlobalSign and others) is responsible for showing users only those application icons they are entitled to use, and in addition, that the users have only the rights within each application they are authorized for.
This model could be characterized as a “professional’s self-service channel” because the user experience is rather bare, in some ways reminiscent of using a smartphone. All tasks are performed in different applications that may work in different ways and enable a high variety of functional levels. This model is excellently suitable for service solutions between companies, and it may save millions of euro at best because it removes the need to code the heavy service layer as users are allowed direct access to business system interfaces – although with limited rights.
Summary: Choose the model that is right for your particular need
This is only a scratch on the surface of the variety of technological solution models available for customer-facing self-service channels.
In the stories to follow, we intend to delve deeper into the various models, but we hope this overall picture might be useful to you.
Really big organizations should also note that all the models described here may be used together. For example, a big banking and insurance company’s service entity comprising online banking, insurance services and mobile applications will easily include all these components.
The main takeaway from this story is that you absolutely should first create a business concept for customer-facing self-service channels and the desired development roadmap, and only then start thinking about the technology for implementation. And if you wish, we are more than happy to help you with those discussions here at North Patrol.
