R E S E A R C H W H I T E P A P E R
This research paper focuses on end-user requirements and opinions regarding Web-based customer portals for data VPN services, which are provided to end-user customers by service providers. Only enterprise views on customer portals are discussed in this report; we will present service provider opinions on this topics in a separate report.
Web-Based Customer Portals
1 Report Background 1 Customer Portal Overview 2 What Features Are Most Needed
3 Must-Have Features 4 Important Features 5 Nice-to-Have Features
6 The Willingness of Enterprises to Pay for These Features 6 Differences Between Industry Verticals
6 Financial Services 7 Manufacturing 7 Conclusions 8 Research Methodology 8 Authors
Table of Contents
Report Background
The research presented here is derived from direct interviews with more than 40 enterprises based in North America and Europe. Figure 1 illustrates the distribution of the vertical markets rep-resented in this research report. The enterprises interviewed would mostly be considered large enterprises and so the conclusions presented here should only be considered representative of this segment of the market. Additional information on the research process is presented at the end of this report.
Customer Portal Overview
The term “customer portal” refers to a source of information regarding the services that an end user has contract-ed for from a service provider. These portals are traditionally provided via an Internet-based GUI, which the service providers’ customers can then access at their convenience.
The type of information presented within a portal can range from a high-level overview of services offered by the service provider to highly customized reports detailing the performance of end-user applications across the network. Below is a partial list of portal features or functionalities that enter-prises could use:
• dynamic, on-demand, changes in circuit bandwidth
• dynamic, on-demand, changes in bandwidth allocation and traffic classification by CoS • entering trouble tickets (e.g., if latency is too high)
• tracking of open trouble tickets
• inventory tracking by corporate location (i.e., equipment and/or services) • review of billing information, in aggregate, by corporate location or department
• performance reporting of network-based QoS parameters (e.g., current and trend levels for latency, packet loss, jitter, etc.)
• performance reporting for end-user applications
• reporting of bandwidth usage by corporate location, department, network equipment, port, application, etc.
• on-demand reporting of various above-noted information for specific time periods
• proactive notification of changes in service performance (i.e., increase in latency, packet loss, or other performance parameters)
• proactive notification of breach of service performance thresholds (e.g., latency greater than a pre-set value)
• summary or details of service results compared against overall SLA requirements
Figure 1. Vertical Markets Represented in this Research Report
Financial Services 10 Industrial 7 Consumer 6 Public Sector 2 Professional 9 Technology 4 Health4
The above list of features and functionalities are those that most enterprises focused on when discuss-ing their requirements related to customer portals. However, not all of these features are considered equally important to these enterprises, so we have segmented this list into three categories, as discussed below.
What Features Are Most Needed
Generally, enterprises first identified features that would be considered critical or “standard” for any basic portal; without these “must-have” features, there would be no use in having a portal. Enterprises indicated that these features, for the most part, are currently being offered by service providers, although not always in a portal format. Enterprises would expect service providers to offer these features, and service providers not offering them would not be considered for supplying services. The next category could be considered “important features”, or those that would be very useful to enterprises. These features are not as commonly offered by service providers, but may be offered as part of a managed service. Enterprises viewed these features as being competitive differentiators for their suppliers.
Lastly, enterprises viewed some features as “nice-to-have.” These enterprises did not consider these features important now, but could see benefits at some future point in time. Their comments were that these features would be most useful when moves, adds and changes to the network were much more frequent. Nevertheless, as with the “important” features, service providers who are currently offering these features would stand out with enterprises. Generally, only a few enterprises viewed these “nice-to-have” features as important to the current delivery of their services, and could see the immediate benefits they would bring.
One observation regarding the important features and nice-to-have features is that once they are offered via a portal, enterprises are likely to use them increasingly and will ultimately come to rely on them. The nice-to-have features will likely take longer to be adopted, as networking architectures and business situations change.
Table 1 below lists the portal features within each category. The listing is an approximate catego-rization based on explicit as well as qualitative comments from the enterprises interviewed for this research report.
Table 1. Comparison of Web-Based Customer Portal Features
MusT-haVe FeaTuRes IMPoRTanT FeaTuRes nICe-To-haVe FeaTuRes
Performance monitoring and reporting: Dynamic service bandwidth changes Dynamic changes to classification criteria of traffic
- overall bandwidth usage types to specific CoS
Performance monitoring and reporting: Dynamic bandwidth allocation by CoS level Service order entry and tracking - usage by application or port
Performance monitoring and reporting: SLA tracking Inventory tracking (service and/or equipment)
- QoS metrics (jitter, latency, and packet loss) by location
Must-Have Features
Enterprises indicated that reporting features related to the health of their service provider network are the most important capabilities of a customer portal. The health of their network can be com-municated via a number of features, and can be summarized as performance monitoring and report-ing capabilities, as well as trouble-ticket entry and trackreport-ing. These are the most critical features that enterprises value in a customer portal, and can be viewed as minimum requirements. Nevertheless, despite their importance, there is room for differentiation between service providers to generate a competitive advantage.
Performance monitoring
Performance monitoring is an obvious requirement for any end-user service, and as a first step, enterprises expect to be proactively notified if there is a problem with their service. However, some enterprises indicated that they were not receiving these notifications, despite promises from their service providers; enterprises that had to notify their service providers of a downed circuit were not impressed with their service provider (see trouble-ticket tracking below).
Additionally, enterprises indicted that for performance monitoring to be useful it must go beyond simple indications of whether the service is up or down. As a starting point, bandwidth usage reporting was the top concern, including the ability to report on usage based on location, department, application or class of service (CoS). Enterprises want to know if “garbage or real applications” are driving band-width usage.
Beyond simply reporting on bandwidth usage, enterprise ICT executives would also like to have a view of the quality of the network service for a given application. At the high end of the spectrum, this would imply reporting on application performance which is affected by network performance. This would be typical of an enterprise that has outsourced its IT applications and communications to a systems integrator. Generally, though, the expectation is for reporting of the quality of the network service by subscribed CoS. The main parameters of interest are jitter, delay, packet loss and network availability, since these network parameters affect application performance. ICT executives would like the ability to track these various parameters historically, and also be able to set-up a network polling function to gather this information over a set period of time.
When asked whether they would be willing to pay for the use of a Web portal, enterprises indicated that these performance monitoring features are the most important features that would positively influence them to pay. Many of the enterprises surveyed indicated that they had purchased equip-ment to provide performance monitoring capabilities, but ended up lacking the resources to set these up and were either not using the tools or were just using them on an ad hoc basis. There is a strong consensus among enterprises that performance reporting brings significant value, which they are willing to pay for if it can be justified through operational savings as compared to doing it themselves. Pricing and willingness to pay will be discussed further on in this report.
Trouble-ticket tracking
Tracking live trouble tickets ties in with the need for knowledge regarding service status. Some enterprises additionally indicated that the ability to enter trouble tickets was a must-have feature, especially since degraded service status notifications are not always provided by the service provider. Once entered, the ability to view the current status of these trouble tickets can be the most efficient way to monitor progress to resolution and eliminate unproductive communication between the service provider and the end user. This efficiency can translate to operational expenditure (OPEX) savings for the service provider, allowing it to focus on problem resolution. The expected result is that the trouble ticket is resolved faster!
However, as some multinational companies simply stated, “we complain really loudly” when inter-acting with their service provider concerning trouble tickets. These large multinationals will usually have more leverage than small and medium-sized enterprises (SMEs) with this approach, but they could benefit by streamlining the overall process using online trouble-ticket entry and tracking SMEs on the other hand, will see a direct and more immediate benefit from being able to manage (enter, escalate, check status on, etc.) their trouble tickets.
Nevertheless, many enterprises commented that voice-based communications support from service providers for dealing with trouble tickets should not be reduced. Using voice-based communications would still be a necessity when access to the Internet is not available (i.e. when out of the office or during non-business hours), and some enterprises indicated that they would need to “test” the portal-based system before fully trusting its capabilities (i.e. after a few successful resolutions of trouble tickets). Additionally, a written record of the progress to resolving the problem is still important for keeping all necessary people up to date.
Important Features
The following is a discussion of the features that enterprises generally considered important. While some enterprises may view some of these as “must have”, generally these features seemed to resonate with fewer enterprises than those discussed within the “must have” features section.
Dynamic service bandwidth changes
Generally, enterprises considered the ability to affect dynamic bandwidth changes to be an impor-tant feature. The ability to turn bandwidth up or down, on demand, for a given location through the portal ranked higher in overall importance than the ability to make dynamic changes to the classification of traffic types to specific classes of service.
The term “dynamic” was however interpreted differently by most enterprises, with existing reference times for bandwidth changes measured in months. For these enterprises, the overall bandwidth required was something that could usually be planned in advance, and therefore most changes would not need to be executed in real time. What all of these enterprises are simply looking for are shorter lead times, such as days or weeks, to adding bandwidth; as one enterprise commented, “I am just asking my service provider to take my money faster”.
There are always exceptions however, and some enterprises did site specific examples of when they might like to dynamically adjust bandwidth to certain locations, such as for month-end financial reporting or regular data backups. While these examples can be planned, other situations either can-not be planned, such as an important but un-planned video conference, or are poorly planned, such as “forgetting” to order additional bandwidth for a location that is expanding. In these instances, the ability to order more bandwidth for short-term delivery would be a very useful capability.
However, these same enterprises viewed the flexibility to dynamically change the way overall band-width is allocated to be a valuable service to offer via a portal, which is discussed below.
Dynamic bandwidth allocation by CoS level
In addition to dynamic bandwidth changes, enterprises also viewed the ability to change, on demand, the amount of bandwidth allocated for each CoS within an overall bandwidth limit as an important service to offer via a portal. For example, to accommodate an unexpected surge in videoconferencing requirements, an enterprise may want to increase the amount of bandwidth allocated to real time traffic from 20% to 30% of the overall available bandwidth.
SLA tracking
SLA tracking gives the ICT executive (some large enterprises now have an SLM, or service level manager) a view of how the managed network service is performing compared to agreed-upon terms with the service provider. Given that the enterprises interviewed were generally ICT executives, it is not surprising that they would wish to have a view of performance compared to contractually agreed-upon standards, but the high importance given for visibility on a customer portal was driven by operational concerns. Several enterprises highlighted that the recording of SLA metrics on a portal is necessary, but should also be augmented with proactive notification of changes in service perfor-mance or breach of service parameter thresholds. The former feature is a warning that services may be impacted, while the latter feature is an active notification that the applications have been impacted.
Review of billing information
Billing and the maintenance of past billing records accessible from the customer portal ranked as an important feature for several enterprises. Others considered this capability to be a minimum requirement, though, which should be part of any customer portal. Granularity in billing reporting, such as by location or department, were generally viewed as additional benefits that would save the ICT group internal time and effort. Having accurate billing as a standard practice, however, was an overriding desire of enterprises.
Nice-to-Have Features
Finally, we discuss the features that enterprises generally viewed as “nice-to-have”. While most enter-prises could see the benefit of these features, most ICT executives did not view them as “must have” today; a few enterprises, though, did express a desire to use these features now. Some enterprises did indicate that once “nice-to-have” features are available and start to be used, these features become “important” or even “must-have” features.
As previously mentioned, most survey respondents viewed dynamic changes to classification criteria of traffic type to specific CoS to be less important than the ability to dynamically change overall bandwidth allocation by CoS. This feature would enable the enterprise to move a type of traffic (e.g., based on DSCP marking) to a different CoS based on business needs. For complete flexibility and to address the desires of the broadest range of enterprises, service providers should consider offering both dynamic bandwidth and changes to classification criteria, on demand, via their customer portal.
Service order entry and tracking via a customer portal received mixed reactions. For some enter-prises, this represents an efficient means of placing the order and, more importantly, tracking its progress through to fulfillment. Others would be more inclined to deal with the service provider representative, especially for enterprises where only a few ICT personnel would have authority to place service orders. Therefore, if order entry were available via the customer portal, a secure means of ensuring appropriate authorization levels would be required.
Inventory tracking by location via a customer portal assists ICT personnel by giving them a clear view of the circuit, service and equipment inventory available at each of their corporate locations. This has value for day-to-day activities, such as the need to identify whether a subscriber can access a specific service from their location, or for site-specific future planning activities. Not all enterprises deemed this a necessary feature, but those who did rated it highly.
The Willingness of Enterprises to Pay for These Features
For the most part, enterprises indicated a reluctance to pay directly for any of these portal features. The level of reluctance was obviously highest for the must-have features, which almost all enter-prises viewed as integral to the overall service. Most enterenter-prises commented that a comprehensive portal becomes a differentiator for the service provider, which will help attract business, but it can also help service providers to reduce their operational expenses. The enterprise should therefore not have to pay for these capabilities. Some enterprises also indicated that their IT budget has been “frozen for years” and that spending is continuously scrutinized due to the globally competitive envi-ronment in which they operate; any new costs would therefore have to be justified in such a situation, and likely would have to be paid for by cancelling other expenditures.
However, there was a strong consensus that performance reporting (a “must-have” feature) brings significant value, which enterprises are willing to pay for and justify through OPEX savings com-pared with doing it themselves. Many enterprises have already purchased network monitoring equipment to provide these capabilities, but these enterprises have found that they do not have the time or resources to fully use the features of these devices. There is an operational expense for these enterprises to set-up, maintain and monitor these devices. If their service provider could provide the same reporting capabilities as with the existing internal equipment, these enterprises indicated a willingness to shift expenditures to pay for the information from their service provider. In this case, the purchased devices could be relocated to other locations to perform functions that would not have been cost-effective previously. Alternatively, some enterprises indicated that they would pay the service provider to operate the performance-gathering equipment that they have already bought and paid for.
Finally, one enterprise indicated that by outsourcing their performance reporting requirements, it would allow the enterprise to outsource responsibility for timely availability and accuracy of the reports.
Generally, enterprises indicated that they would be willing to pay 5 percent to 10 percent for these portal services, or on average, $100 per corporate location regardless of bandwidth. However, many enterprises indicated that these payments would be difficult to justify as an explicit expense (i.e. as a separate line item), and suggested that incorporating the fee into their overall monthly charges would be a better approach to success.
Finally, some enterprises expressed concerns and reservations regarding the overall accuracy of exist-ing billexist-ing functions, and if these billexist-ing systems could support billexist-ing for various customer portal functions. While enterprises expressed a willingness to pay for certain customer portal functions, their view was that existing billing systems should be fixed to reduce errors related to existing services that are being billed for.
Differences Between Industry Verticals
Generally, the research results listed above were consistent across industry verticals. However, some differences did emerge, which are discussed below.
Financial Services
While portal features rather than the underlying portal infrastructure were the topic of the inter-views with the enterprises, the financial services industry stood out in its concern for security and the mechanisms to ensure the integrity of the portal. For example, network access using secure shell (SSH) without violating existing policy (e.g., no telnet), would have to be ensured. In addition, audit-ing capabilities of the portal activities, to ensure ongoaudit-ing data security and integrity, were stated as a requirement.
It is clear from these interviews with financial services companies that any positioning of portal benefits will need to be supported by a discussion of the measures taken to ensure the security and integrity of the offering. The benefit to the service providers who develop these assurances is that they can then be leveraged with the other verticals. Although not to the same level, many other verticals expressed concern for protecting the integrity and confidentiality of their data. Therefore, if the service provider can meet the needs of the financial services vertical, they will likely meet the needs of all verticals.
Manufacturing
With globalization, manufacturing companies are moving factories around the world to take advan-tage of lower cost levels and to be closer to their customers. These companies are also increasingly working with different suppliers for different parts of the manufacturing process. With more and more internal and external communications requirements, these manufacturing companies have a greater need for information related to the performance and status of each of these services. A special requirement would be communications with subcontractors, where services would have to be activated and de-activated depending on the project.
Additionally, certain applications are more critical to manufacturing companies, such as supply chain management (SCM) and order entry, and may also be hosted centrally for all the above- mentioned internal and external locations. Due to the importance, customer portals that can explicitly provide performance statistics on traffic related to these applications would be useful for manufacturing companies.
Conclusions
Enterprise ICT executives have shown a willingness to outsource the management of their VPNs but they cannot outsource their responsibility to meet their internal enterprise customer needs and expectations. From the interviews conducted it is clear that enterprise ICT executives see the value of a customer portal helping to bridge this gap by giving them additional visibility and greater control of their communications services.
Customer portal reporting features, including performance reporting and trouble-ticket tracking, have the most universal appeal among the enterprises interviewed. These capabilities help ensure that their VPN services are performing as expected and can allow more effective planning for future requirements. Some enterprises also consider the ability to dynamically control the bandwidth and allocation of bandwidth to various classes of service, to be important functions of a customer portal. These capabilities were of greater value to enterprises that had more dynamic bandwidth require-ments driven by unpredictable application usage.
Overall, the customer portal is an important point of differentiation between service providers that enterprises will use in their selection criteria; service providers need to offer customer portal features to competitively differentiate themselves. Finally, any enterprise spending for customer portal features will need to be justified based on savings compared to doing it themselves. This is especially significant with respect to performance monitoring.
There is a strong consensus among enterprises that performance reporting brings
significant value, which they are willing to pay for if it can be justified through
operational savings as compared to doing it themselves.
Research Methodology
This research report is based on direct interviews with ICT managers and executives from more than 40 enterprises. These enterprises are based in North America and Europe, and for the most part, would be considered large enterprises. The research-gathering process was based on prior knowledge of MAN and WAN data networking requirements for more than 50 enterprises based in North America and Europe. The structure of the interviews focused on existing portal features that these enterprises were able to access, which features were used and for what purposes. Additionally, the interviews addressed which features these enterprises would want to have, and ultimately what amount these enterprises would be willing to pay for each of these features.
The enterprises interviewed for this report, broadly speaking, represent seven industry verticals. These verticals consist of Financial Services, Manufacturing, Media, Professional Services, Public Sector, Retail, and Technology.
Authors
Rene Latraverse Brian Van Steen, CFA
Director, Solutions Marketing Director, Solutions Marketing
