Patent Application
20230283532
The present invention generally relates to the field of software systems, and more particularly, to the automated determination of which service-level agreement (SLA) should be associated with a given user request in a request management system.
Request management systems provide a means to respond to user requests that are serviced by agents, aiding agents to prioritize the requests and ensure that the requests are handled in a timely manner or that any goals associated with the requests are otherwise met. However, the determination of which SLAs should apply to any given user request may be less convenient. System administrators or other users of the system may be obliged to manually formulate, maintain, and revise substantial metadata permitting the system to select a given SLA for a given user request. This is tedious and error-prone, requiring considerable administrator time and potentially leading to system errors.
The figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.
Users 106 are affiliated with an organization 100 (e.g., as employees or volunteers of the organization) and may use their user devices 105 to access the computing system of the organization. The users 106 may encounter issues that need to be resolved by other members of the organization assigned to respond to such issues. These other members of the organization 100 are referred to as “agents” 108, and use their agent devices 107 to likewise access the computing system of the organization. The user requests may relate to any number of issues, such as the computing system of the organization (e.g., resolving a problem with the network or with an application program), physical resources of the organization (e.g., obtaining a new keyboard for the user), or the like. In order to achieve a high degree of user satisfaction, the agents should resolve the user requests within a reasonable amount of time. An SLA system 110 within the organization 100 assists the agents 108 with issuing and tracking service “tickets” (data representing a particular user request and associated metadata) and satisfying whatever goal is desired for agent responses to the user requests.
The users 106 and agents 108 communicate using a messaging system, such as an external third-party messaging system 130 as illustrated in
The SLA system 110 includes a number of components used to support the handling of user requests by agents. A messaging interface 116 obtains user messages from the messaging system 130 and uses an SLA selector 120 to select, from the SLA repository 112, an SLA that is appropriate for that message. A ticket issuance module 117 creates a new ticket according to the contents of the user message and the selected SLA and stores it in the ticket repository 111. An SLA enforcement module 115 monitors the active tickets to help ensure that the agents handle the tickets in a timely manner. These components are now discussed in more detail.
The types repository 113 contains a set of known types of requests that a user can make. Some examples of types for a given organization 100 might be “Application access request” (representing a request for a particular user to be able to use a particular application), “Badge access request” (representing a request to add rights to particular rooms or other locations to access rights of a user's badge), “Broken computer” (indicating a request for replacement computer), or the like. The types repository may be populated by an administrator or other user of the organization 100, for example.
The SLA repository 112 contains the different possible SLAs that could be assigned to a given ticket. An SLA (service-level agreement) defines an expected level of service for the servicing of a particular user request. In some embodiments, an SLA includes a goal to be met, including a metric type, an explicit or implicit condition, and a value of that metric. For example, the metric type might be response time (for an agent to acknowledge the user request), a resolution time (for an agent to resolve the user request), a pending time, or the like. The metric value is of a type corresponding to the metric, such as a number of minutes or seconds for the “response time” metric type. The condition may be implicit, such as an implicit “less than or equal to” value for the “response time” metric type. An SLA may also have an associated applicability condition, which is a predicate defined in terms of contextual variables and constant values and that defines circumstances in which the SLA is applicable to a given request. For example, one particular applicability condition might be “DAY IS Saturday OR Sunday”, expressing that the SLA only applies on the weekend; “REQUESTOR MEMBEROF Executives”, expressing that the SLA only applies to users who belong to the “Executives” group within the organization 100; or “TYPE IS ‘Broken computer’ AND USER IS ‘jsmith’” expressing that the SLA applies only if the request type is “Broken computer” and the user has the username “jsmith”. Applicability conditions may be arbitrarily complex, with any number of subexpressions. In some embodiments, an SLA may additionally have an assigned request type (e.g., as an explicit or implicit portion of the applicability condition) from the types repository 113; in other embodiments (as discussed below) SLAs are more decoupled from types, with SLAs not expressly coupled to particular types, and with tickets being matched with an SLA using a machine-learned model, rather than matching purely upon types expressly assigned to SLAs. In some embodiments, SLAs may additionally have data including a list of one or more agents 108 or other users 106 to be notified in response to events associated with an SLA assigned to a ticket (such as the goal associated with the metric being breached), and/or a tag to apply to a ticket with the given SLA when the SLA is breached.
The ticket repository 111 stores data for service tickets representing particular user requests and associated metadata. In some embodiments, each ticket has one or more associated types from the types repository 113. The type may be assigned explicitly and manually by an agent 108 of the organization 100, such as by the agent selecting one of the types from a user interface provided by the SLA system 110 and choosing an option to create a new ticket of that type, or explicitly and automatically by a machine-learned model or other logic of the SLA system 110 that maps a ticket to an SLA to be associated with it. In other embodiments, the ticket need not have an explicit type, instead automatically being assigned an SLA by the SLA selector module 120, rather than being assigned an SLA partially or purely via a type associated with the ticket.
In some embodiments, the SLA system 110 includes a messaging interface 116 that obtains user messages from the messaging system 130, so that the messages may be analyzed to determine whether they represent a user request for which a ticket should be issued. In some embodiments, the messaging interface is implemented as a plugin or other form of extension that operates in conjunction with the messaging system 130 to obtain information on messages of the organization that are passing through the messaging system 130. The messaging interface may pass all or some (e.g., a subject line, thread name, or message body text) of the message data to the SLA selector module 120.
The SLA selector module 120 determines which SLA should be applied to a given ticket. The determination may be made in different manners in different embodiments. In some embodiments, each ticket has an associated type, and the SLA selector module 120 selects an SLA for a given ticket purely based on the ticket's associated type. In this embodiment, there must be a mapping from types to SLAs. For example, the type “Application access request” could be statically mapped to a particular SLA specifying a resolution time of at most 60 minutes. A requirement on administrators of the organization to create a static mapping from types to SLAs constitutes an extra burden on administrators. In other embodiments, the SLA selector module 120 selects an SLA for a ticket by evaluating the applicability conditions of the various SLAs and seeing whether the ticket data satisfies those applicability conditions. The type, and/or user identifier, may be part of the applicability condition, and so may at least in part determine the SLA in this embodiment.
In still other embodiments, such as that illustrated in
With an SLA determined for a given user request (or prior to or concurrent with the SLA determination), the ticket issuance module 117 generates a ticket for the user request, setting the SLA for the ticket to the SLA determined by the SLA selector module 120. The ticket is stored in the ticket repository 111, and may either then or later be assigned to an agent 108.
The SLA enforcement module 115 monitors the active (unresolved) tickets within the ticket repository 111 and provides feedback to the agents 108 to help to ensure that the goal of the ticket is met. For example, in the case of time-based goals, the SLA enforcement module 115 could issue a warning at a given point before the time-based deadline for the ticket (e.g., when 75% of the allowable time has elapsed), or when the ticket deadline has been reached, or at some point or multiple points after the ticket deadline has been reached, or any combination thereof. The SLA enforcement module 115 may use the messaging interface 116 to send the warning via the messaging system 130 (e.g., sending a Slack™ message to an assigned agent 108 or manager thereof, warning “[SLA violation] The ticket #189893 has only 5 minutes left til the completion deadline.”) Alternatively, instead of sending a message, the SLA enforcement module 115 can update a user interface provided to agents 108 by the SLA system 110, e.g., adding a visual flag that the deadline for that particular ticket is near.
In some embodiments, a multi-tenant system (not illustrated in
Physically, the organization 100 is made up of a number of computing systems, including the various client devices 105, 107; one or more internal networks that connects the computing systems, including routers or other networking devices that define the boundary between the organization and external networks; and the like.
Similarly, the messaging system 130, although depicted as a single logical system in
The network 140 may be any suitable communications network for data transmission. In an embodiment such as that illustrated in
The user 106 uses the user device 105 to send 205 a message embodying the user request. For example, the user 106 might send a Slack™ message over the messaging system 130 containing the body text “My laptop broke. I need a new computer.” The message is obtained by the SLA system 110 (e.g., by its messaging interface), and the message data is provided to the SLA selector module 120, which determines an SLA from the SLA repository 112 that is most appropriate for the user request. As noted above with respect to the SLA selector module 120, in various embodiments the SLA is determined based solely on a type associated with the user request (where an agent 108 may specify the type, or a machine learning model may map the message data to a type), or is determined based on matching a ticket with SLA applicability conditions, or is determined by mapping the ticket or message data directly to an SLA using the model 121.
The SLA system 110 creates 215 a ticket for the user request, assigning the SLA determined by the SLA selector module 120 as the SLA for that ticket. The SLA system may assign 220 the ticket to an agent 108 for resolution, and notify 225 the agent of the assignment (e.g., by sending a message through the messaging system 130, by updating a user interface displayed to the agent, or the like).
With the ticket assigned 220, the SLA system monitors 230 whether the assigned agent has resolved the ticket yet (i.e., completed the task corresponding to the user request), e.g., by determining whether the agent has marked the ticket as closed using a user interface. If not, the SLA system determines whether a deadline associated with the ticket is approaching (or arrived, or past), and if so issues 240 an appropriate warning to the agent, as discussed above with respect to the SLA enforcement module 115 of
It is noted that the interactions of
The storage device 308 is any non-transitory computer-readable storage medium, such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memory 306 holds instructions and data used by the processor 302. The graphics adapter 312 displays images and other information on the display 318. The network adapter 316 couples the computer 300 to a local or wide area network.
As is known in the art, a computer 300 can have different and/or other components than those shown in
As is known in the art, the computer 300 is adapted to execute computer program modules for providing functionality described herein. As used herein, the term “module” refers to computer program logic utilized to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, and/or software. In one embodiment, program modules are stored on the storage device 308, loaded into the memory 306, and executed by the processor 302.
Embodiments of the entities described herein can include other and/or different modules than the ones described here. In addition, the functionality attributed to the modules can be performed by other or different modules in other embodiments. Moreover, this description occasionally omits the term “module” for purposes of clarity and convenience.
Other Considerations
The present invention has been described in particular detail with respect to one possible embodiment. Those of skill in the art will appreciate that the invention may be practiced in other embodiments. First, the particular naming of the components and variables, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, formats, or protocols. Also, the particular division of functionality between the various system components described herein is merely for purposes of example, and is not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead performed by a single component.
Some portions of above description present the features of the present invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules or by functional names, without loss of generality.
Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.
Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by real time network operating systems.
The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored on a computer readable medium that can be accessed by the computer. Such a computer program may be stored in a non-transitory computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of computer-readable storage medium suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent to those of skill in the art, along with equivalent variations. In addition, the present invention is not described with reference to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any references to specific languages are provided for invention of enablement and best mode of the present invention.
The present invention is well suited to a wide variety of computer network systems over numerous topologies. Within this field, the configuration and management of large networks comprise storage devices and computers that are communicatively coupled to dissimilar computers and storage devices over a network, such as the Internet.
Finally, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the claims.
