Creating an Enterprise Service Portal

Self-service tools have really come of age, enabling organizations to develop full-service website portals that include information, service requests, and self-service opportunities. A true service portal wouldn't be restricted to IT; it would be a gateway to interacting with all of the organization's service providers from a single landing page and would be the central repository for policies and information developed across the organization. This vision transforms today's service request catalog into an enterprise service portal and is a significant undertaking.

The enterprise service portal becomes a hub for all of the needs of an organization, but it also offers the ability to optimize costs.

The enterprise service portal becomes a hub for all of the needs of an organization, but it also offers the ability to optimize costs. When properly designed and adopted, a request catalog cuts call volume and enables requests to be delivered directly to fulfillment teams, enabling the service desk to focus on incident resolution and management. While switching to an enterprise service portal model might not lead to headcount reductions, it can prevent the need for staff increases. Additionally, when you add automated fulfillment to handle menial, uninteresting tasks, IT staff can focus on more pro-active activities and system maintenance, improving service delivery.

The Challenge

Many IT organizations own the tools with the capabilities to deliver this portal, but they might not be the most appropriate personnel to design the portal, being more analytical and technical than creative and lacking experience in website design. To gain adoption, the portal needs to be modern and compelling in its design, reflecting the organization’s branding and using images that resonate with associates. It should be designed as well as the company's website, as it sets the tone for the organization.

While IT might succeed in building a technical request catalog that offers end users the ability to request IT services, many efforts to establish service portals fail due to poor design. People use the catalog only because they need to in order to obtain certain services, like access.  The result of the overarching lack of adoption is that organizations don't typically look to IT to deliver an enterprise-level portal once they see what IT has created. In fact, rather than thinking at the enterprise level, request methods may spring up across the organization, from paper based forms to collaboration tools in use at the organization and purchased products. The latter can result in duplication of tools throughout the enterprise and additional costs as a result.

A Value Proposition for the Enterprise Service Portal

High-value request catalog projects can be a game-changer for an organization. They enable people to be more productive via a single site for access to all of the services available in the organization and streamlined processes to request services, and they enable the consolidation of tools into a single platform. The ability to achieve this aim depends on the scope of the catalog and use of automation to the greatest extent possible. There are several important considerations when undertaking a project to build an enterprise-level portal.

Business value of the services and requests made available. The graphic below shows the value of service requests, based on their focus from the viewpoint of where IT generally starts building a portal.  Internal IT requests often seen in request catalog pilot projects are the lowest value requests to the customer, while complex business requests or requests that include automated fulfillment provide the higher value.

Ability to automate fulfillment. The service portal of the future needs to enable self-service and automated fulfillment, delivering an app store experience. Software deployment isn't the only service that can be automated. Consider account provisioning, password resets, virtual desktop provisioning, automated procurement of supplies from external providers, updates to corporate directories, and so forth. Many HR and payroll requests can be fulfilled with an automated system: employee address changes, benefits enrollment as a result of family status change, bank changes (for direct deposit), and reimbursements for benefits such as tuition and gym memberships. Find these, and automate them as part of the initiative.

Ability to consolidate request platforms. Consolidating all of the home-grown solutions into a single platform will save administrative maintenance costs, software licensing costs, and overall support costs. Other providers may not be ready to give up their management tools right away, so build a bolt-on or front-end portal and allow them to continue using their tools, gradually bringing everyone along over time.

Engage the Right Stakeholders Early

Rather than focusing on an IT request catalog effort, declare the intent to go enterprise-wide at the beginning of a catalog initiative. In considering the stakeholders for the effort, seek out a representative from any/all service providers in the enterprise. They will help gain adoption and support for the larger initiative and also help IT develop requests that meet the needs of other groups they work closely with, such as facilities, building security, and HR. Include consumers of their services to ensure the customer view is considered during design.  Remember to include communications and marketing departments, who can provide experts in design and ensure strong alignment with organizational branding standards.

Use an Agile Approach

Once the stakeholders are established, create the vision for the catalog implementation project and take it on in small phases. Agile focuses on developing a minimum viable product in short bursts of development, with many, frequent releases. This approach is ideal for building an enterprise portal as it enables the organization to establish the portal and some high-value requests quickly. You can then add requests almost continuously, falling into a rhythm that enables the catalog to continue growing.

The first release, consisting of several sprints can establish the foundation for the catalog:

• The core data and foundation for product itself
• The portal design and organization
• The first set of requests to be included (10–20 of the most common requests) 
  

Using an agile approach and devops release methodology can make it possible to add requests to the catalog routinely as it continues to grow, establishing a rhythm of moving requests from the pipeline into production.

If the organization can automate the migration of requests into production, a devops approach can be taken, providing weekly or even nightly releases of new requests as soon as they have been completed. This effort will keep the catalog growing quickly and enable the organization to gain sufficient momentum to keep the project going. It also enables fast correction if there is a problem associated with request design.

Keep Working the Backlog

Obviously an enterprise-level catalog will take quite a long time to mature and requires ongoing attention. The organization will need to develop a process for prioritizing requests across providers and for continuing to solicit new providers until the catalog is completed and moved into a maintenance mode, adding or changing requests as needed by the business.

Developing a prioritization process will become the most critical aspect of catalog growth. There are two schools of thought on which requests to do first: the simple requests that are easy to document and develop or the more complex requests that cause some level of pain in their fulfillment. Old school used to recommend starting simple. In reality, if the components of a complex request can be documented in a workflow, the organization has what it needs to develop it, as long as their technical skill enables them to do so.

Thus, a recommended approach includes ranking requests based on complexity, business value, volume, and any other factors that may be important to the organization. Once an initial list of requests is developed, each item can be scored based on a simple high (5 points), medium (3 points) and low (1 point) rating schema, and then a total request score can be tabulated for each request. Re-sorting the list from high to low score can provide a first cut. The stakeholders can then add intelligence to the ranking. One item to consider very seriously is the need to bring all requests that are currently offered through a tool over to the catalog at the same time to avoid having providers working in multiple tools.

Catalog and Request Design

This is a final area to consider, but an extremely important one. Before the group begins designing requests they should go Internet shopping, learning about order design and fulfillment.  Research will reveal several best practices:

• Organization and ability to search are paramount. Many organizations will list their categories on a banner, either at the top or down the side of the web site. This method gives the user the ability to navigate to another area of the store easily. Search capability makes it easy to find exactly what's needed. Both a browsing and buying experience are provided.
• Shoppers do not need to enter a lot of information once they establish an account. There aren't a lot of options from which to select, and when there are, they are generally in drop downs rather than free text.
• When certain items are selected, related accessories that might be needed are offered to the customer. These options often appear as "people who purchased this item also purchased...."
• Checkout is easy and generally includes a total cost for the order and a delivery date. A confirmation email typically follows, as do periodic updates during the delivery process, unless the order is something that can be delivered immediately, such as software or movies.
  

Try to avoid a couple of common pitfalls in request design:

• Avoid asking for the user’s name and contact information if they have already logged into the portal. The system knows who they are, where they are located, and who they work for. The information can be made available to the fulfillment teams, without having to ask the customer to supply or scroll through it.
• If desired, a delivery location can be added at checkout to support environments where people work out of several locations or home workers need to request delivery to their home office.
• Supply department administrators who order things for others a version of the request that enables them to order in bulk or for someone else. This keeps things simple when people order something for themselves, while still providing administrators the ability to request items on behalf of others.
• Speak the customer’s language and don't ask questions they cannot answer without support. This word of caution is not aimed at IT only; other providers also have an industry lingo. HR requests can be just as difficult to understand as technical requests. Make use of the field-level help (mouse or hover-over) capabilities of the tool to explain what's needed and provide choices from which to select as often as possible.
  

Using Focus Groups to Evaluate Design

There is no right design for a service request catalog or enterprise service portal. Given this, the organization may find it useful to develop a focus group. Unlike the stakeholders, this group of individuals from a variety of organizational roles becomes an objective body who can provide honest feedback on both portal and request design. They can evaluate prototypes of the design, to ensure that people can find requests once the catalog is live and provide feedback on the questions and design of each request. Ultimately they become a valuable tool to designing a portal experience people will love.

Take the Time to Create Value

Building the service portal of the future is a long-term commitment, rather than a short-term effort. The value proposition for the business is high, as it provides a single landing page through which the organization’s associates will find information about and access to the services provided by all of the providers in the organization. As such, it streamlines the effort people put into administrative needs, allowing them to submit requests quickly and efficiently and get back to their core responsibilities.

To achieve this value, the organization needs a vision for the portal, the right stakeholders engaged in its initial design and implementation, and providers who are willing to continue to spend the time it takes to design their requests and keep them current. Communication between the IT staff responsible for portal development and the providers represented in the portal must be constant and ongoing, ensuring it continues to meet the needs of its customers and providers.

Building the service portal of the future is a long-term commitment, rather than a short-term effort.

Once available, the portal offers tremendous value to providers by enabling them to accept requests and issues through an effective self-service channel 24x7, even when their service desks are closed. By enabling repetitive requests to be routed directly to service providers, it enables the organization’s service desks to focus on their support responsibilities. They can focus on work that provides value directly to their customers (rather than spending time acting as a pass-through). Most importantly, it streamlines and improves overall support for the associates using the portal, enabling them to focus on the aspects of their jobs that provide value to the organization.

Phyllis Drucker is an ITIL certified consultant and information leader at Linium. Phyllis has more than 20 years of experience in the disciplines and frameworks of IT service management, as both a practitioner and consultant. She has served the itSMF USA since 2004 in a variety of capacities including volunteer, board member and operations director. Since 1997, Phyllis has helped to advance the profession of ITSM leaders and practitioners worldwide by providing her experience and insight on a wide variety of ITSM topics through presentations, whitepapers, and articles and now her new book on the service request catalog, Online Service Management: Creating a Successful Service Request Catalogue (International Best Practice, forthcoming 2016). You can read more of her work such as the “What’s in Your Service Catalog” series and her “Self Service, the Cloud and ITSM” articles on Linium’s website. She will share sample designs for a service portal of the future when you sign up for a free portal consult.