An Adaptive Hypermedia System
for Improving an Organization’s Customer Support
MAJ Timothy Schmoyer
Department of Electrical Engineering and
Computer Science
United States Military Academy
West Point, NY 10996
dt6667@exmail.usma.army.mil
MAJ Bernard J. Jansen
Department of Electrical Engineering and Computer Science
United States Military Academy
West Point, NY 10996
jjansen@acm.org
Please Cite: Schmoyer, T. and Jansen, B. J. 2000. An adaptive hypermedia system for improving an organization's customer support. WebNet Journal, 2(4), 30 - 35.
Abstract
Using the paradigm of adaptive hypermedia along with usability design techniques, an we developed an adaptive hypermedia system was developed that automated the customer support tasks of an organization charged with the maintenance and upkeep of a large governmental building. We present the theoretical underpinnings of the system, the design methodology, along with the development and implementation of the system. The system is currently in use, resulting in positive improvements in organizational support to the customer. The system has been so successful that plans are currently under way to expand the implementation of the system to other locations. We discuss our current and on-going improvements to the system, which include the introduction of software agents and voice technology.
Introduction
For organizations that provide a services directly to customers, there is a requirement for involvement with customers along with organizational tracking of customer support performance. Some examples of such support requirements , among many others, are maintenance service orders for a buildings, merchandise return or repair, and status reports of actions or accounts. The degree to which an organization successfully accomplishes this customer support has a direct impact on the overall perception of the organization’s efficiency, customer satisfaction, and organization’s bottom-line. Some functional issues to consider are completeness, accuracy and timeliness of the provided support. Not only must an organization effectively and efficiently address these issues, but also the organization must also accomplish them in a manner that the customer perceives as personal. These factors became the design criteria in the development of our on-line system..
We were able to combine adaptive hypermedia in the form of dynamic web pages, usability aspects of computer interface design, and the connectivity of the Web to develop a paradigm that delivers the high level of organizational support that many customers desire and expect. The system implementation resulted in not only improved customer support , and automatic but recording keeping of also valuable knowledge for improved management of the organization.
We designed and developed an adaptive hypermedia customer support system that accepts, checks, submits, and confirms maintenance requests for the tenants of a large governmental building. The system accomplishes this, and ensures continued customer use, by recognizing and adapting the information presented to a particular customer, including name recognition, contact information, automatic email dialogue and presentation of historical data, along with error checking of customer submissions. The result is a more satisfied customer base, better knowledge management by the organization, and most importantly, an improve state of maintenance for the building. The system structure is flexible enough to be easily adapted for other organizations and situations.
Review of Literature
Adaptivity is an aspect of hypermedia that can utilize a variety of methods for flexible delivery of information, especially through a Web-based interface. (Eklund & Brusilovsky, 1998). Adaptive hypermedia has the potential to overcome the limitations of traditional computer systems by tailoring applications to met specific user needs and requirements. Adaptive hypermedia has been utilized in various aspects including interfaces (Nielsen 1993) and education (Schneider, 1994). An excellent review of adaptive systems is contained in (Brusilovsky, 1996). Adaptive pages are now appearing on the Web. An common example instance is Excite’s (http://www.excite.com) personalized search page, which receives an average of five times as much traffic per user relative to than the normal Web page (Basse, 1999).
Adaptive systems attempt to anticipate the needs and desires of the particular user. To do this effectively, the application design must be based on a model of the user (Knott, Mellish, Oberlander, & O'Donnell, 1996; Milosavljevic, Tulloch, & Dale, 1996). Some systems develop this model utilizing the user's previous actions. Other An adaptive system may also gather information by monitoring what the user is doing, or the system may ask questions of the user. For example, some intelligent tutoring systems build a user model based on what reading material a user accepts and validates the model by means of multiple-choice questionnaires.
A user model can be represented by of a set of pairs (c, v) where c is a concept and v is a value (Eklund & Brusilovsky, 1998). A concept is an idea, subject, preference, submission, or topic (i.e., a noun). A value is a measure that associates the user to that concept. The value is typically a descriptive term to represent the degree a user knows about a particular concept (i.e., beginner, novice, or expert) or a number representation of varying degrees defined in the meta data of the system. In practice, concept-value pairs are often represented using numeric data types. Greater granularity fidelity in the descriptive concept-value pair is can be obtained by offering a range of many values, for instance a value between 0 and 100. An adaptive system could also use only a few numeric values, 1 through 5 for example, if less granularity fidelity is required, or a system could just use Boolean values, that is such as true and false. In the system we developed, we opted for using Boolean values. With this inplementationimplementation, the concept-value pair is a straightforward way to represent a particular user.
The Adaptive Hypermedia Customer Support System
We developed an adaptive hypermedia system to process the maintenance service requests from the building’s the tenants of a large, governmental building. The system resulted in dramatic, positive increased improvement in the processing of customer service requests, the management of these service requests, and most importantly, improved the maintenance support of the building.
Background
Prior to the development of this system, the submission of service orders was a laborious, inefficient, and in the view of many tenants, fruitless process. The building in question was built in the 1930’s as a riding stable. It was needed for the training of college students who would be future military officers. It was at the time, the largest riding stable in the world, and now provides several thousand square feet of usable space.
In the 1950’s, the building was refurbished and converted into college classrooms, offices, laboratories, shops, indoors ballistic range, and commercial retail space. Over the years, there were numerous other renovations, modifications, and additions to the building. One of the modifications was to wire the building with a local area network (LAN). Therefore, most occupants and all agencies in the building had access to the LAN. At the time our system was implemented, over two hundred individuals from seventeen separate agencies were tenants in the building, along with literally thousand of temporary users of the building. The responsibility for the upkeep and overall maintenance of the building, as well as, customer service support to the tenants of the building fell to a building supervisor known as the Building Commandant. The resources available to the Building Commandant included a small janitorial staff and external maintenance support provided by a single agency known as the Department of Housing and Public Works (DHPW). DHPW was responsible for all maintenance, repair and utilities at our location. This maintenance situation parallels many other governmental and non-governmental building arrangements where the upkeep is out sourced.
When a tenant had a maintenance issue, the tenant would call or email the Building Commandant. The Building Commandant would then record the service request and report the issue by telephone to a service clerk at DHPW. The DHPW service clerk would enter the service request into a database, assigning the work request to the appropriate shop and provide a tracking number to the Building Commandant. Upon receiving the work request, the DHPW shop would then dispatch maintenance teams to address the issue, responding within a few hours for emergencies and within a few weeks for routine requirements. The Building Commandant was responsible for monitoring the progress of these maintenance requests and liaison with DHPW to ensure the work was completed.
There were several deficiencies with this arrangement. First, the information the tenants provided to the Building Commandant would many times not be specific enough or would be missing vital information needed to address the maintenance issue (e.g., location of the problem). Second, by communicating first with the Building Commandant there was a built in delay in addressing the maintenance issue. The Building Commandant may not be in to answer the telephone or not check his email for a period of time. This caused a delay in the service request getting to the maintenance organization. Third, some tenants, realizing the delay caused by communicating with the Building Commandant, would bypass the Building Commandant and call the maintenance organization directly. Unfortunately, the Building Commandant would then lose oversight of these maintenance requests and lose the historical information that, with the proper analysis, could be the harbinger of future, larger problems. Additionally, since the DHPW service clerk received calls for every building within the locality, customers often were placed on hold, and they received no feedback on their service requests once submitted. Because of these issues and despite the hard work of all involved, the building was falling into disrepair while the use of the building was increasing.
Purpose
To address these issues, we designed and implemented an adaptive hypermedia system to handle the submission of maintenance requests. We decided to utilize the adaptive hypermedia paradigm to design the system because we believed it provided the opportunity to realize both the functionality requirements the organization needed and the usability aspects that would ensure the tenants utilized the new system. Using this Web-based system, a tenant could submit a maintenance request containing all the necessary information directly to the Building Commandant and the service organization simultaneously. The system also would also provide feedback on the success of the submission and a mechanism for the customer to monitor the status of the service request.
We decided to utilize the adaptive hypermedia paradigm to design the system because we believed it provided the opportunity to realize both the functionality requirements the organization needed and the usability aspects that would ensure the tenants utilized the new system.
Design
Since most all tenants had access to the LAN, we decided to take advantage of this infrastructure. We wanted an adaptive hypermedia based system with the central functionality being the submission of service requests, but it would also provide be a conduit for the receipt and posting of important building and tenant information. First, we reviewed dozens of Web systems, both well and poorly designed. Many of these Web systems are listed examined in (Kahn, 1998). . Many of these Web sites were reviewed in (Kahn, 1998). This is was the first step in usability and system design methodology advocated by Nielson (1993), which is to conduct a field study of comparable a systems and isolate good and poorly designed features.
During the design of our system, we incorporated other features of Nielson’s (1993) methodology, namely using a common interface design platform as a starting point, defining measurable usability attributes, realizing the "less is more" functionality features, and acceptance of an iterative design process. This last point was critical to our system as we rolled out three major versions and several minor changes in less than 6 months. However, the interface layout remained basically the same, and the actual URL for access to the system never changed. So the customers were cushioned from the frustration associated with successive system changes.
Based on the needed functionality aspects of the system, the concept-value pair of adaptive hypermedia systems, and our usability design methodology, we set forth the following design characteristics of our system.
Development
The system had two major components, the interface and the backend. The backend was an integration of a Microsoft Access and an Oracle database. The two databases were linked via Visual Basic code and embedded standard query language (SQL). The Access database was used for tracking by the Building Commandant and as the data source for customer queries on the status of service requests. The Oracle database was used by the external maintenance organization, DHPW, for their internal management of service request. The duplicative storage of information, along seemingly a waste of space and effort, actually was a boon for the care and upkeep of the building. With access to an independent local database, the Building Commandant has a record of submitted service requests that the maintenance organization’s Oracle database should mirror. This allowed for the identification of lost or improperly terminated service requests. This also minimized concerns by the maintenance organization of providing access and suffering possible disruption to the maintenance organization’s database. Plus, a local database permitted the storing of building and customer specific information that the outside maintenance organization did not care or have the need to track. This specific customer information also permitted the development of the development of an adaptive aspects of the system.
Cold Fusion was used as the development application program interface (API) for the system’s interface. Cold Fusion provides an standard mechanism for developing both dynamic web pages and the database-query mechanism. The resulting system interface is displayed in the customer’s browser as HTML and Javascript. These are all standard platforms for the development of Web interfaces. Using the concept that "less is more," when a customer requested the URL for the customer support system, he/she had a limited number of options or concept-value pairs, the primary one being submit a service order or not. The concept was the service order. The value, a Boolean data type, being that the customer did or did not want to submit a service request.
If the customer desired to submit a service request and had never submitted one before, the system queried the user for some personal information (e.g., name, office number, email address, etc.). This information was utilized to identify the customer on subsequent visits; thereby allowing the system to tailor or adapt the information provided to that customer and also provided the Building Commandant necessary information to conduct customer relations. So, our system utilizes the approach of questioning the customer to develop a portion of the user model.
For a particular service request, the essential field or concept was location, and the value being that the location already had a service order request submitted or it did not. When a customer submitted a service request, the system first queried the customer, addressing the customer by name, for the location. This personal addressing, along with personalized email responses, seemed to anthropomorphizing the system in the minds of the customers. In a 6 month sample of 1003 the exchanges from the customers to the systems, we identified over 126 entries (12.6%) that indicated the customers were personifying the system. These queries contained terms or phrases that one would expect in a conversation, such as "thank you", please, and "I would appreciate." The percentage would be higher if entries from the Building Commandant and DHPW technicians, ones who know how the system works, were removed from the 6 month sample.
Once the customer entered the location, usually a room number, the system displayed to the customer a list of all open (i.e., not completed) service order requests for that location. The customer could then scan the list to see if someone else had already submitted the service request. This feature in it self was a significant productive boon, resulting in significantly fewer duplicate service requests being submitted.
If the particular shortcoming was not on the already submitted list, the customer could proceed, and the system would prompt the customer for the necessary information. If the customer did not submit all the correct information, the system would prompt the customer for the specific missing information, and only when all the information was correctly entered would the system submit the service order to the maintenance organization. The system would also email a confirmation message to the customer, the Building Commandant, and a point of contact at the maintenance organization. Figure 1 shows a typical service request Web screen.
Figure 1. Service Request Entry Page Showing previous and Open Service Requests.
The system also handled many other functions needed for building maintenance, such as checking the status of previously submitted service requests and tracking all service requests submitted a particular customer. Using the system, the Building Commandant could track trends in service requests in order to isolate problem locations and customers experiencing reoccurring problems. The system also offered FAQ lists, direct email contact to points of contact within the building for many of the major tenant organizations, and email contact to the Building Commandant. In these features, we utilized previous actions of the user in order to implement the adaptive aspects of the system.
The first version of system rolled out within one week of setting forth the design considerations. The second version rolled out one month later. The final version was rolled out two months after conception of the system. There have been numerous but relative minor changes since that time. Overall, the system appears robust and enthusiastically endorsed by the customers based on the high volume of use.
Several design considerations went in to the system. To address "location in hyperspace", the first image that a customer saw sees on accessing the system’s URL was is a picture of the building. This reaffirmed visually for the customer that they were in the correct location. We intentionally designed a site that focused exclusively on the building maintenance, so the choices for the customer were are intentionally by design narrow. This keeps the cognitive load on the customer to a minimum. Figure 2 shows the initial page to the Web system.
Figure 2. Initial Page to the Web System with Building Location.
Conclusions and Directions for Future Research
The major contributions of the system, is the dramatic improvement beyond the practical in the maintenance of the building. From a research and implementation perspective, a significant contribution of the system is the implementation of adaptive hypermedia in a commercial environment. Previously, adaptive hypermedia has been mainly a research area and confined to academic environments or simple, relative stable "personalizing" of Web pages. This research and resulting system illustrates that adaptive hypermedia systems can be successfully implemented in a commercial setting, with enormous pay off for an organization. Additionally, the system shows that usability design methodologies, so often ignored in product design, can be successfully implemented in a commercial setting with little disruption to product fielding schedules. In fact, this system illustrates that a system design process incorporating usability factors can resulted in a product that is both rapidly taken to market and commercially successfully. In fact, the system has been so well received, that it is currently under-going expansion to encompass other buildings in the nearby geographically area with further expanse in the incipient stages for nation-wide expansion in the incipient stage.
We are investigating system improvement in three areas, namely (1) expanding the system’s adaptivity, (2) introducing software agent into the system, and (3) integrating voice technology with the existing Web and database components. In the area of adaptivity, we would like the system to prompt (i.e., use push technology) the customer with expanded information on building locations or previous service requests that the customer submitted. We are also investigating having the system assist the user with clarification issues. This clarification would be dependent on the service request and lessons learned from previous but similar service requests. For example, if the service request concerns a power outage in a particular room, many times this is simply a tripped circuit that the customer could fix. The system, keying in on the electrical outage problem, would suggest this plan of action to the user before submitting the service request. This historical information could be gathered from a variety of sources including the Building Commandant and DHPW maintenance teams reports..
The area of software agents offers numerous potential productivity improvements. The three that we are currently investigate are: (a) The feasibility of immediately notifying the customer via email on the day a maintenance team is dispatched to work on a service request. One area of productivity that is suffering, under both the old and new system, is that the maintenance teams lose considerable time attempting to locate the customer for room access, etc. (b) We are also examining immediately notifying the maintenance organization, customer, and Building Commandant when an emergency service order has been entered into the system and requires rapid response. Examples of these types are maintenance problems with elevators, plumbing, and safety systems such as fire alarms, exit doors, and sprinkler systems. (c) We are also exploring if software agents could be of benefit in the area of long term building upkeep. Software agents could conducting knowledge mining of the database for trends in certain building locations (e.g., a leak in a certain room occurring every summer) or in customers that are having a range of problems (i.e., the same customer entering varied service requests for the same location). The software agent could mine the database and notify the Building Commandant of these types of maintenance trends for preemptive action.
Finally, we are investigating voice technology, specifically computer-telephony-integration. In computer-telephony integration, a network server integrates interactive voice response (IVR) with the backend databases. The approach we are taking is to use a small key system unit (KSU) that is IVR capable. We would integrated the KSU with the network server by scripting the system prompts to provide order entry information to the database through the standard SQL, which is the database language. However, we do not want customers only being able to enter and query orders via the telephone.
We also desire our IVR KSU to interact with our customer’s Web browsers (e.g., see using a product such as the one outlined at http://www.peri.com/product/periwbbr.html).
We also want our customers to have the ability to call in the service request via the Web system. We are investigating putting a link on the system that telephones the maintenance organization’s service representative, which is exactly what is needed for emergency service orders. The customer, or a software agent working on the customer’s behalf can "talk" to the service representative using the computer’s multimedia sound card and the Web browser's Telephony Application Programming Interface (TAPI).
These enhancements will only further enhance the organization’s customer support by further addressing the individual customer’s needs, improving the long-term management and maintenance upkeep, and increasing the options available for customer support. The adaptive hypermedia system, both currently and with further planned enhancements, is proof that technologies and methods that were only research domains a short time ago, can be implemented and profitably employed in support of an organization’s customer support goal.
References
Brusilovsky, P. (1996)., Methods and Techniques of Adaptive Hypermedia. In: User Modeling and User-Adapted Interaction. 6: 87-129, Kluwer academic publishers. , 1996. (URL: http://www.contr ib.andrew.cmu.edu/~plb/UMUAI.ps)
Basse, J. (1999).1999 Retrieved from the World Wide Web on 11 August 1999 from http://www.nielsen-netratings.com/.
De Bra, P. &, Calvi, L. (1998). AHA: a Generic Adaptive Hypermedia System. Ninth ACM Conference on Hypertext and Hypermedia Hypertext'98. Pittsburgh, USA., June 20-24, 1998
Eklund, J.ohn & Brusilovsky, Peter. (1998). The Value of Adaptivity in Hypermedia Learning Environments: A Short Review of Empirical Evidence. Ninth ACM Conference on Hypertext and Hypermedia Hypertext'98. Pittsburgh, USA.
Kahn, P. (1998). Website Information Architecture. Presented at Ninth ACM Conference on Hypertext and Hypermedia Hypertext'98. Pittsburgh, USA., June 20-24, 1998
Knott, A., Mellish, C., Oberlander, J. & O'Donnell, M. (1996). Sources of flexibility in dynamic hypertext generation. In Proceedings of the Eighth International Natural Language Generation Workshop (INLG-96), Herstmonceux Castle, Sussex, UK, 151-160.
Milosavljevic, M., Tulloch, A., and Dale, R. (1996). Text generation in a dynamic hypertext environment. In Proceedings of the 19th Australasian Computer Science Conference, pages 229-238, Melbourne, Australia.
Nielsen, Jakob. (1993). Noncommand User Interfaces. Communications of the ACM 36, 4 (April 1993), 83-99