Patent Application
20070208698
The following disclosure relates generally to request submission.
Organizations are increasingly implementing and relying on internal systems that function over a wide-base infrastructure, such as intranets. When problems occur that are related to the use of such systems, members of the organization and other users, such as employees and customers, may call or send a message to a helpdesk or support center run by a support staff (consisting of helpdesk agents) in order to seek assistance. Once a user reports a problem or requests assistance to solve a problem, a helpdesk agent may generate a trouble ticket to log the report or request. The support staff then investigates the problem that is affecting the user, which is often related to an infrastructure outage or some sort of planned or unplanned diminished service. For example, an employee attempting to use a printer connected to a network may experience difficulty when attempting to print a document. The employee may not completely understand the problem, but has enough knowledge that he or she may provide a general description of the problem (e.g., “the printer on the third floor is not printing”) to a helpdesk agent, who then generates a report. Eventually, one or more helpdesk agents are assigned to investigate and ultimately resolve the printer problem.
While there are several different categories of helpdesk service requests (e.g., “how to,” “request for change,” “break/fix,” etc.), industry reports reflect that infrastructure outages typically make up a significant percentage of total helpdesk service requests (approximately eighteen percent of all helpdesk service requests). Often, where a problem is related to an infrastructure outage or diminished service of a system or subsystem, the support staff may receive several service requests relating to the same problem, but they have no way to convey such knowledge to others within the organization. For example, if the problem with the networked printer described in the above-cited example is related to a planned maintenance outage, several employees may be experiencing problems with one or more printers on the network. Although the support staff already knows of the problem, its members may be required to respond to multiple service requests for assistance relating to the same problem. Receiving large numbers of such redundant service requests often prevents the support staff from addressing other issues and results in inefficient use of the organization's resources. Recent industry reports estimate that each service request contact costs an organization an average of sixteen dollars.
While a user submitting a service request requesting assistance with a particular problem may not know whether another user has already submitted a similar service request for the same problem, once service requests reach a helpdesk, helpdesk agents may be able to recognize duplicate service requests by reviewing their descriptions. Where there are many service requests to process, however, the task of identifying duplicate service requests from a large collection of service requests may be time consuming, especially when the duplicate service requests may all have varying descriptions. Moreover, if there is more than one agent working at the helpdesk to process service requests, identifying duplicate service requests may become even more difficult because of the coordination involved in such a task.
Accordingly, it would be desirable to have a tool that notifies a helpdesk agent about the existence of potential duplicate service requests.
A facility for identifying potential duplicate service requests is provided. In some embodiments, the facility notifies a helpdesk agent processing a service request if a selected pending service request is related to other pending service requests that have been submitted by other requesters, thereby enabling the helpdesk agent to address any duplicate service requests simultaneously. For example, a sudden floor-wide voicemail outage may cause eight different employees to submit online service requests indicating that their voicemail is not working properly, all within a one-hour period. The facility then identifies potential duplicate service requests within a store of submitted service requests. The facility displays potential duplicate service requests in a list on the helpdesk agent's computer as a distinct group of related service requests. The helpdesk agent may then select individual service requests from the displayed list of potential duplicate service requests in order to consolidate the service requests. Consolidated service requests may then be addressed efficiently as a group. For example, the consolidated service requests may be logged using a single trouble ticket. Additionally, the facility may notify, as a group, the requesters of consolidated service requests that their service requests are in the process of being addressed.
By providing a standardized facility for submitting service request information, one or more information fields of a service request such as time, title, type, area, subarea and description may be compared with similar fields in other pending service requests. The comparisons may involve searching for exact matches (e.g., using a standardized “TYPE” field), searching for keywords (e.g., using a “description” field) and/or searching within a specified range (e.g., searching for service requests submitted within two-hour time period).
The advantages realized by the use of some embodiments of the facility include more efficient processing of redundant service requests, especially in the case where redundant service requests are interspersed within a large collection of pending service requests.
In some embodiments, a system in which the teachings of the present invention are implemented can be logically structured as a multi-layered architecture as shown in
In some embodiments, the user Interface layer 110 may provide the applets, views, charts and reports, etc. associated with one or more applications. In some embodiments, various types of clients can be supported via the user interface layer 110. These various types of clients may include traditional connected clients, remote clients, thin clients over an intranet, Java thin clients or non-Windows-based operating systems, and HTML clients over the Internet, etc.
In some embodiments, the object manager layer 120 is designed to manage one or more sets of business rules or business concepts associated with one or more applications and to provide the interface between the user interface layer 110 and the data manager layer 130. In some embodiments, the business rules or concepts can be represented as business objects. In some embodiments, the business objects may be designed as configurable software representations of the various business rules or concepts such as accounts, contacts, opportunities, service requests, solutions, etc.
In some embodiments, the data manager layer 130 is designed to maintain logical views of the underlying data and to allow the object manager to function independently of underlying data structures or tables in which data are stored. In some embodiments, the data manager 130 may also provide certain database query functions such as generation of structure query language (SQL) in real-time to access the data. In some embodiments, the data manager 130 is designed to operate on object definitions in a repository file 160 that define the database schema. In some embodiments, the data storage services 170 provide the data storage for the data model associated with one or more applications.
In some embodiments, the data exchange layer is designed to handle the interactions with one or more specific target databases and provide the interface between the data manager layer 130 and the underlying data sources.
In some embodiments, the multi-layered architecture allows one or more software layers to reside on different machines. For example, in some embodiments, the user interface, the object manager and the data manager can all reside on dedicated web clients 200. For other types of clients such as the wireless clients 203, in some embodiments, the object manager and data manager can reside on a system server. It should be appreciated and understood by one skilled in the art that the system configuration shown in
In some embodiments, the system environment illustrated in
In some embodiments, the database 290 is designed to store various types of data, including predefined data schema (e.g., table objects, index objects, etc.), repository objects (e.g., business objects and components, view definitions and visibility rules, etc.), and user's or customer's data. In some embodiments, dedicated web clients 200 and server components, including those that operate in conjunction with the other types of clients, can connect directly to the database 290 and make changes in real-time. In some embodiments, mobile web clients 210 can download a subset of the server's data to use locally, and periodically synchronize with the server database through the system server to update both the local and the server database.
In some embodiments, various tables included in the database 290 may be logically organized into the following types: data tables, interface tables, repository tables, etc.
In some embodiments, data tables may be used to store user business data, administrative data, seed data, transaction data, etc. In some embodiments, these data tables may be populated and updated through the various applications and processes. In some embodiments, data tables may include the base tables and the intersection tables. In some embodiments, base tables may contain columns that are defined and used by the various applications. In some embodiments, the base tables are designed to provide the columns for a business component specified in the table property of that business component. In some embodiments, intersection tables are tables that are used to implement a many-to-many relationship between two business components. They may also hold intersection data columns, which store information pertaining to each association. In some embodiments, intersection tables provide the data structures for association applets.
In some embodiments, interface tables are used to denormalize a group of base tables into a single table with which external programs can interface. In some embodiments, they may be used as a staging area for exporting and importing of data.
In some embodiments, repository tables contain the object definitions that specify one or more applications regarding:
In some embodiments, the file system 295 is a network-accessible directory that can be located on an application server. In some embodiments, the file system 295 stores the physical files created by various applications, such as files created by third-party text editors, and other data that is not stored in the database 290. In some embodiments, physical files stored in the file system 295 can be compressed and stored under various naming conventions. In some embodiments, dedicated web clients 200 can read and write files directly to and from the file system 295. In some embodiments, mobile web clients 210 can have a local file system, which they periodically synchronize with the server-based file system 295. In some embodiments, other types of clients such as the wireless clients 203 and the web clients 205 can access the file system 295 via the system server.
In some embodiments, the enterprise server 250 is a logical grouping of the system servers 255 that share a common table owner or a database, point to a common gateway Server, and can be administered as a group using a server manager 260. In some embodiments, the connection to the gateway server can be established via TCP/IP. In some embodiments, the enterprise server 250 can be scaled effectively by deploying multiple system servers 255 in the enterprise server 250, thus providing a high degree of scalability in the middle tier of applications.
In some embodiments, the server 255 runs one or multiple server programs. It handles the incoming processing requests and monitors the state of all processes on the server. In some embodiments, server programs are designed and configured to perform one or more specific functions or jobs including importing and exporting data, configuring the database, executing workflow and process automation, processing to support mobile web clients 210 for data synchronization and replication, enforcing business rules, etc. In some embodiments, the server 255 can be an NT Service (under Windows NT operating system) or a daemon (e.g., a background shell process) under UNIX operating system. In some embodiments, the server 255 supports both multi-process and multi-threaded components and can operate components in batch, service and interactive modes.
In some embodiments, the server manager 260 is configured as a utility that allows common control, administration and monitoring across disparate programs for the servers 255 and the enterprise server 250. In some embodiments, the server manager 260 can be used to perform the following tasks: start, stop, pause and resume servers 255, components and tasks; monitor status and collect statistics for multiple tasks, components and servers within an enterprise server; and configure the enterprise server, individual servers, individual components and tasks, etc.
In some embodiments, the gateway server can be configured as a logical entity that serves as a single entry point for accessing servers. In some embodiments, it can be used to provide enhanced scalability, load balancing and high availability across the enterprise server. In some embodiments, the gateway server may include a name server and a connection brokering component. In some embodiments, the name server is configured to keep track of the parameters associated with the servers. For example, the availability and connectivity information associated with the servers can be stored in the name server. The various components in the system can query the name server for various information regarding the servers' availability and connectivity. In a Windows NT environment, the name server can be run as an NT service. In a UNIX environment, the name server can run as a daemon process. In some embodiments, the connection brokering component is used to perform load balancing functions such as directing client connection requests to an appropriate server (e.g., the least-busy server).
In some embodiments, as illustrated in
In some embodiments, dedicated web clients 200 (also called connected clients) are connected directly to a database server for data access via a LAN or WAN connection. In some embodiments, these connected or dedicated web clients do not store data locally. These dedicated web clients 200 can also access the file system directly. In some embodiments, the user interface, the object manager and the data manager layers of the multi-layered architecture reside on the dedicated web client 200.
In some embodiments, the mobile web clients 210 are designed and configured for local data access and thus can have their own local database and/or local file system. In some embodiments, mobile web clients 210 can interact with other components within the system via the gateway server. Through synchronization, the modifications from the local database and the server database can be exchanged. Mobile web clients 210 are described in more detail below.
In some embodiments, a web client 205 runs in a standard browser format from the client's machine. In some embodiments, the web client 205 can connect to a system server 255 through a web server. In some embodiments, the system server 255 is designed and configured to execute business logic and access data from the database 290 and file system 295. In some embodiments, the web client 205 described herein is designed and configured in accordance with the teachings of the present invention to operate in an interactive mode. In some embodiments, the interactive web client framework as described herein utilizes dynamically created objects implemented in JavaScript on the browser side that correspond to objects on the server side. In some embodiments, these dynamically created objects on the browser side may include the current view and its corresponding applets, the current business object and the corresponding business components, etc. The web client 205 is described in more detail below.
In some embodiments, wireless clients are essentially thin clients enabled on wireless devices. The wireless clients can use a wireless application protocol (WAP)-based user interface to communicate and exchange information/data with the system server.
The system configuration illustrated in
In some embodiments, the presentation services 315 may be designed and configured to support various types of clients and may provide them with user interface applets, views, charts and reports, etc. As described above, a large variety of clients may be supported (e.g., wireless clients, handheld clients, web clients, mobile web clients, dedicated (connected) clients, etc.).
In some embodiments, the application services 325 may include business logic services and database interaction services. In some embodiments, business logic services provide the class and behaviors of business objects and business components. In some embodiments, database interaction services may be designed and configured to take the user interface (UI) request for data from a business component and generate the database commands (e.g., SQL queries, etc.) necessary to satisfy the request. For example, the data interaction services may be used to translate a call for data into DBMS-specific SQL statements.
In some embodiments, data services 345 may be designed and configured to provide the data storage for the underlying data model that serves as the basis of the various applications. For example, the data model may be designed and configured to support various software products and applications including call center, sales, services and marketing, etc., as well as various industry vertical products and applications such as eFinance, eInsurance, eCommunications and eHealthcare.
In some embodiments, the core services are designed and configured to provide the framework in which the applications execute. In some embodiments, the core services may include the following:
In some embodiments, application integration services may be designed and configured to allow the various applications built in accordance with this framework to communicate with the external world. In some embodiments, the various types of services in this logical grouping may be designed and configured to provide for real-time, near-real-time and batch integration with external applications. For example, these integration services may be used to enable communications between external applications and internal applications using available methods, technologies and software products. In some embodiments, application integration services allow the systems or applications to share and replicate data with other external enterprise applications. Accordingly, these services allow a particular application or system to be both a client requesting information and a server having information requested from it.
In some embodiments, business processes services are designed and configured to allow the client to automate business processes through the application. In some embodiments, these various business process services may include the following:
In some embodiments, creation of these business processes can be done through Run-Time tools such as Personalization Designer, Workflow Designer, SmartScript Designer, Assignment Administration Views and Model Builder.
In some embodiments, integration services may be designed and configured to provide the client with user interface and thin client support. In some embodiments, these may include capabilities for building and maintaining web-based applications, providing web support facilities such as user Profile Management, Collaboration Services and Email and Fax services, advanced Smart Scripting, etc.
In some embodiments, design time tools may be designed and configured to provide the services to customize, design, provide integration points and maintain the application. These various tools provide one common place to define the application.
In some embodiments, administrative services are designed and configured to provide one place to monitor and administer the application environment. In some embodiments, these services allow the user to administer the application either through a graphic user interface (GUI) or from a command line, etc.
From the “MY SERVICE REQUESTS—HELPDESK ONLINE” page 500, the requester may select an item from an “SR AREA” drop-down menu 506. In some embodiments, the particular SR area selected by the requestor corresponds to a particular system that may be the basis of the requestor's service request. Examples of SR areas include “Facilities,” “Finance,” “Human Resources,” “IT,” “Mfgops” and “Payroll.” For purposes of illustration, examples of subareas within an “IT” area may include “Hardware Break/Fix,” “Desktop Hardware,” “Dial-up,” “File Sharing,” “Laptop Hardware,” “Local Connectivity,” “Net Conference,” “Net meeting,” “Password,” “Printing,” “TelephoneNoicemail” and “Windows 2000.” Examples of subareas within a “Facilities” area may include “Air Conditioning,” “Doors,” “Electrical,” “Elevators,” “Furniture,” “General Exterior,” “Plumbing,” “Security,” “Appliances,” “Lighting,” “Facilities/conference,” “Moves,” “Locks,” “Recycling” and “Refreshments.”
The following example further illustrates the use of the “SR AREA” 506 and “SR SUBAREA” 508 fields as provided in some embodiments. An employee having problems with the temperature of his office being too cold may create a service request choosing “Facilities” for both the “SR TYPE” 504 and the “SR AREA” 506 fields and “Air Conditioning” for the “SR SUBAREA” 508 field. Besides being used as a means for identifying duplicate service requests, the information provided in the “SR AREA” 506 and “SR SUBAREA” 508 fields may be useful for purposes such as determining the appropriate recipient of the service request or describing a problem so that appropriate measures may be taken to address the problem. The information provided by the user in a “DESCRIPTION” text area 510, in some embodiments, may also serve a similar function.
Once the requester has entered information about the type of the request, the requester may select a priority for the service request (e.g., “Very High,” “High,” “Medium,” “Low,” etc.) using the “PRIORITY” drop-down menu 512. In some embodiments, the first and last name of the requester 514 is automatically displayed in corresponding text fields of the service request. In an alternate embodiment, the requester may be prompted to input his or her name, location and/or other identifying information, such as an email address or phone number. In some embodiments, when the requester has inputted the appropriate service request information, the requester may submit the service request by selecting a “SUBMIT” button 518, or cancel the service request by selecting a “CANCEL” button 520.
In some embodiments, an “SR NUMBER” field 606 displays the service request number assigned to the selected service request (e.g., 1-3633901). A “SOURCE” field 608 displays the source of the service request (e.g., web). In some embodiments, the title of the service request is displayed in a “TITLE” field 610. Similarly, information in a “DESCRIPTION” field 632 is displayed, which allows the helpdesk agent to acquire a high-level understanding of the submitted service request. Other fields in the service request in some embodiments include “REQUESTOR NAME” 612, “SR TYPE” 618, “SR AREA” 620, “SR SUBAREA” 622 and “PRIORITY” 626. In some embodiments, an “OWNER” field 630 and a “CREATED BY” field are also provided. The information in the “OWNER” field relates to identifying the particular helpdesk agent or individual assigned responsibility for handling the service request.
Values for the “STATUS” field 614 and the “SUBSTATUS” field 616 are provided by the helpdesk agent. For example, a service request that has not yet been completed or fully addressed may be assigned the status “open,” while a service request that has been fully addressed may be assigned the status “closed.” The “SUBSTATUS” field 616 relates to whether the service request has been assigned to a particular helpdesk agent. In this example, the information in the “SUBSTATUS” field 616 indicates that the service request has not yet been assigned.
Once the helpdesk agent has reviewed the details of the selected service request as displayed in the lower section 604 of the “MY HELP DESK SERVICE REQUESTS” page 600, he or she may select a “FIND DUPLICATES” button 636 in order to determine whether the system contains other pending service requests that are based on the same problem indicated by the selected service request. Selection of the “FIND DUPLICATES” button 636 causes the display of a window showing potential duplicate service requests, such as the “DUPLICATE FINDER” window 700 of
In some embodiments, a percent match 708 for each service request is also calculated and displayed alongside each service request listed in the “DUPLICATE FINDER” window 700. The percent match 708 objectively indicates the degree of similarity between the words in the description field of the selected request and the words in the description field of the identified service request. It is possible that the system may not identify potential duplicate service requests for a particular selected request. In such a case, the system may display a “no duplicates identified” message in the “DUPLICATE FINDER” window 700.
From the “DUPLICATE FINDER” window 700, the helpdesk agent may select or “pick” one or more of the potential duplicate service requests in order to confirm that these picked service requests should be handled as a group with the selected request. In order to do this, the helpdesk agent selects a service request and then selects a “PICK” button 710. Each “picked” service request is then tagged as relating to the selected service request and addressed accordingly. The helpdesk agent may also view the details of a selected service request by selecting a “DETAILS” button 712. For example, if the helpdesk agent selects the service request number 564556 indicating that the printer on the fourth floor is not working, and then selects the “DETAILS” button 712, a display showing the details of that particular service request is displayed. The display will be very similar to the detailed display of the service request in the “MY HELPDESK SERVICE REQUESTS” page 600 of
The “DUPLICATE FINDER” window 800 in some embodiments displays area 808, subarea 816, open datetime 818 and SR number 806 information for each displayed service request. Description information 804 is also provided so that the helpdesk agent may quickly and subjectively view each service request to confirm whether it is a duplicate. For example, although the service requests listed in the “DUPLICATE FINDER” window 800 of
Once the helpdesk agent assesses which of the listed potential duplicate service requests should be treated as duplicates, the helpdesk agent may then use the “PICK” button 810 to select all the service requests that he or she wishes to group together as duplicates. In some embodiments, grouping service requests in this way may result in a single trouble ticket being logged for the group of service requests. One of ordinary skill in the art would appreciate, however, that many other ways to address duplicate service requests may be implemented without departing from the scope of the invention. When the helpdesk agent has completed the process of using the “PICK” button 810 to group duplicate service requests, the helpdesk agent may select the “OK” button 814 to return back to the “MY HELPDESK SERVICE REQUESTS” page 600.
From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. For example, although the above description refers to searching information by comparing specific combinations of fields of a specific type, one skilled in the art would recognize that many information types and many combinations of information might be compared without departing from the scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
