text:
|Call center system where users and representatives conduct simultaneous voice and joint browsing sessions
|Roberts et al.
|Method and system for establishing voice communications using a computer network
|Dezonno et al.
|Method and apparatus for selectively presenting media-options to clients of a multimedia call center
|Beck et al.
|Service providing customized information to queuing customers
|Bolduc et al.
|Using web page hit statistics to anticipate call center traffic
|Bauer et al.
|Optimizing call-center performance by using predictive data to distribute agents among calls
|Bogart et al.
|Method and apparatus for enabling interaction between callers with calls positioned in a queue
|Walker et al.
|Method and apparatus for generating agent scripts
|Dilip et al.
|Method and apparatus for call distribution and override with priority
|Gisby et al.
|System and method for delivering expert information by computer
|Dworkin et al.
|System for coordinating communications via customer contact channel changing system using call centre for setting up the call between customer and an available help agent
|Bateman et al.
|Call management method and system for skill-based routing
|Brooks et al.
|Personal communications internetworking
|Pepe et al.
|Computer telephony integration system and method
|Method and apparatus for queuing a call to the best backup split
|Flockhart et al.
|Directory management system and method
|System and method for integrating voice, facsimile and electronic mail data through a personal computer
|Computer implemented process and computer architecture for performance analysis
|Janovski et al.
|Call distributor
|Agent vectoring programmably conditionally assigning agents to various tasks including tasks other than handling of waiting calls
|Electronic mail system having integrated voice messages
|Computer system and method for electronic commerce
|Chelliah et al.
|Completion of calls to a preferred agent in an automatic call distributor
|Method and system for automatically monitoring the performance quality of call center service representatives
|Maloney et al.
|Method and system for monitoring and controlling the performance of an organization
|Powers et al.
|System and method for providing automated customer support
|Fawcett et al.
|Message storage and delivery system
|Bobo, II
|Flexible customer controlled telecommunications handling
|Gerber et al.
|System for automatically sending mail message by storing rule according to the language specification of the message including processing condition and processing content
|Telecommunication network with integrated network-wide automatic call distribution
|Kaish et al.
|Method and system for integrating a plurality of call center agent performance enhancement modules
|McCalmont et al.
|Unified messaging system and method
|Method and apparatus for providing result-oriented customer service
|Szlam et al.
|Telephony system with supervisory management center and parameter testing with alerts
|Cambray et al.
|Method and apparatus for conversing over a network
|Luther et al.
|Method and system for multi-channel data automatic call distribution
|Bruno et al.
|Method and apparatus for interactive television through use of menu windows
|Electronic mail system having integrated voice messages
|Method for accessing real-time data in an automatic call distribution system
|Joyce et al.
|Communications system using a central controller to control at least one network and agent system
|Andrews et al.
|Video teleconferencing for networked workstations
|Palmer et al.
|Video and TELCO network control functionality
|Integrated television services system
|Blahut et al.
|Method and system for automatically monitoring the performance quality of call center service representatives
|Maloney et al.
|System and method for integrating voice, facsimile and electronic mail data through a personal computer
|Irribarren et al.
|Method for forming a virtual call center
|Automated voice system for improving agent efficiency and improving service to parties on hold
|Expected wait-time indication arrangement
|Costantini et al.
|Method and system for monitoring and controlling the performance of a call processing center
|Powers et al.
|Arrangement for automating call-center agent-schedule-notification and schedule-adherence functions
|Integrated voice-mail based voice and information processing system
|Herrero Garcia et al.
|Calling center employing unified control system
|Method for resynchronizing secondary database and primary database with preservation of functionality of an automatic call distribution system
|Butensky et al.
|Apparatus for supervising an automatic call distribution telephone system
|Clare et al.
|Telemarketing complex with automatic threshold levels
|Cassleman et al.
|Supervisory management center with parameter testing and alerts
|Cambray et al.
|Two dimensional routing apparatus in an automatic call director-type system
|Method and apparatus for message handling in computer systems
|Boaz et al.
|Telephone system with ubiquitous agents
|Automated voice system for improving agent efficiency and improving service to parties on hold
|Szlam et al.
|Telephone call handling system
|Home agent telecommunication technique
|Conn et al.
|Method and apparatus for dynamic and interdependent processing of inbound calls and outbound calls
|Szlam et al.
|Automatic call distribution based on matching required skills with agents skills
|Kohler et al.
|Method for predicting agent requirements in a force management system
|Interactive call processor to facilitate completion of queued calls
|Morganstein et al.
|Automation of telephone operator assistance calls
|Dowden et al.
|Operations monitoring system
|Darland et al.
|Interactive call distribution processor
|Morganstein et al.
|Customer definable integrated voice/data call transfer technique
|Gawrys et al.
|Service allocation system
|Wayne et al.
|Announcing waiting times in queuing systems
|ACD Management information system
|Costello et al.
Automatic call distribution centers, also called ACDs or "call centers," route telephone calls from customers who place the calls, to agents who respond to the calls. A typical application for a call center is in a customer support department where customers seek information to assist them in using a product.
Modern call centers provide many features to make the handling of calls and exchange of information more efficient. Not only do call centers strive to assist the customers in stating and categorizing their questions, and the agents in responding to the questions, but the call centers also provide supervisors who manage the agents with information so that the supervisors can make decisions on how to best operate the call center. Also, call centers provide information to assist product manufacturers, or service providers, in improving the quality of their customer service department, particular product or service, etc.
For example, a common feature of call centers today is to allow a customer/caller to select from a menu of choices to help categorize their needs. Often, this pre-selection by the customer allows the call center to screen and categorize customers so that customers can be matched up with the proper resources to handle the calls. Call centers also have mechanisms for "queuing" the calls according to the screening information, availability of agents, etc. Call centers can also maintain a database of previous calls from the same caller, or customer. This database can be available to an agent so that an agent will be familiar with the history of the callers' problems, needs, etc. Call centers also log data on calls and call handling. For example, the time each agent spends per call may be a statistic that is of interest to a supervisor in order to judge agents' performances. Also, analysis of the types of calls being received as where, for example, recurring problems appear, can be used to identify problems in a product or service.
The products and services available in today's information age have become more complex and implicate complex technology. The knowledge necessary to use, configure and upgrade products has grown, inevitably translating into a need for more customer support. Unfortunately, today's call centers do not always provide optimum exchange of information. The almost exclusive use of the telephone as the sole communication channel between a customer and agent does not always provide flexible and efficient exchange of information. The shortcomings of today's call centers are especially deficient in light of the increasing volume of calls that call centers must handle. It is not uncommon for call centers to have hundreds of agents handling thousands of calls each day. A call center's operating overhead can be in the millions of dollars per year. The impact of a good customer support center, however, can be reflected in revenues in the hundreds of millions, thus making an efficient and effective call center vital to a company's successful operation. However, today's call centers have failed to adapt to provide an efficient exchange of information between the call center and the customers in light of today's products and technology.
For example, it is common for computer users to download software applications, software updates, drivers, data, etc. from the Internet. In order to support these software products companies provide online documentation in the form of notes, instructions, lists of "Frequently Asked Questions" (FAQs) and other documentation. However, the Internet's presentation of information is often inadequate to all but the most sophisticated computer and Internet users. Even when looking at a single manufacturer's website, a customer may spend a long time only to determine that the answer to their question does not exist within the wealth of information provided at the website. Customers are left to their own devices to figure out how to search among web-based information and often can not make effective automated searches because they don't know how to characterize their problems in a few keywords.
As an alternative to online documents, some manufacturers allow more customized assistance by providing, for example, an e-mail form or address to which the customer may send a question. However, in some cases, the customer may desire immediate response to which an e-mail response is not sufficient. Also, it is often awkward to state a problem without interactive communication. This is especially true with computer-related products where a discussion of a problem is often a mix of acronyms, abbreviations, syntax symbols and other peculiar uses of the written word beyond mere conversational text. Also, questions about using a user interface are difficult to state with text alone since locations, controls, objects, button presses, etc. need to be discussed.
Another form in Internet communication that is sometimes used in the customer support arena is "real-time chat," or, simply, "chat." The chat form of communication allows typed text to appear immediately on another person's screen so that two or more people may have a typed "conversation" by using their computers over a network such as the Internet. In customer support, moderated chat is another communication type that can be used to give information to customers but it represents the same type of personnel drain to the customer service provider that voice communication presents and, thus, is not a popular form of customer service support unless some screening or prioritizing can be performed. Typically, this means a customer must submit a request for a chat with an agent. In these systems, the customer is at the disadvantage of not knowing when an agent will appear and may thus have to wait online whether they desire to be in front of their computer or not.
Of course, the customer can revert to the traditional communication method of picking up the telephone and dialing a customer support center. However, this reduces the customer to voice descriptions of their problem which, in the computer and software world, may not translate well. For example, anyone who has tried to relay a long uniform resource locator (URL) by calling out the slashes and sub-domain names of text that is a collection of garbled non-words at best, and then having to verify the name when it is repeated back by the person at the other end, can understand the value of being able to use text or other images in a conversation to describe a problem. Also, many of today's customers use their single telephone line to connect to the Internet. This means it is not possible for a customer to simultaneously converse about a problem with an Internet-related product and test out a suggested solution in real time.
Thus, it is desirable to provide a call center system that enhances the ability of a call center to exchange information with a customer. Such a call center should provide benefits in efficiency and effectiveness to both customers, agents, supervisors, and the manufacturer of a product, or provider of a service, to which the call center services are directed.
The present invention integrates multiple communication types in a call center and provides benefits when one or more communication types are used to provide a caller with information. The communication types can be chat, email, voicemail, Internet Protocol (IP) voice, traditional telephone, web page, digital image, digital video and other types. Features of the invention include allowing a single agent to handle multiple customers (endpoints) on multiple communication channel endpoints. The system prioritizes and assigns calls to agents based on a number of criteria. One criterion is the number of endpoints assigned to an agent and that agent's availability. Another criterion is the assigned priority of a customer call. Another criterion is the priority of service provided to a specific customer. Another criterion is the efficiency of a given agent. Another criterion is the agent's efficiency at handling a particular communication medium.
The agent has control over accepting calls in a multiple endpoint environment via an agent graphical user interface. Features of the agent graphical user interface include allowing the agent to drag and drop canned responses, images, URLs, or other information into a window for immediate display on a customer's computer.
The system also provides for detailed agent performance tracking. One type of performance that is tracked is the agent's performance on different communication types. The system takes into consideration how many lines or endpoints an agent had assigned to them.
The system provides failure recovery by using a backup system. If the network server fails, then the customer is connected directly to an agent in a peer-to-peer arrangement. When a failed computer comes back on line, the statistics gathered are then used to synchronize the returned computer.
The system provides extensive call recording or "data wake" information gathering. The system provides flexibility in transferring large amounts of historic and current data (Datawake™ brand information gathering) from one agent to another, and from storage to an active agent.
The system integrates human agents' knowledge with an automated knowledge base. The system provides for an agent updating, or adding, to the knowledge base in real time. The system also provides for "blending" of different communication types. For example, HTML can be included with chat-text so that, for example, a URL can be provided that can be clicked on to take a customer to a specific website. Agents may be allocated to different communication types as, for example, where agents handling telephone calls are re-allocated to handle web requests where web requests communication type calls suddenly increase in frequency.
In one embodiment, the invention provides an automatic call distribution system for transferring information between customers and agents, the automatic call distribution system includes a network interface for transferring information between customers and agents through a computer network; and a control system for simultaneously assigning a plurality of customers to a single agent through one or more of the interfaces.
Customer Site
The details of the present invention will be described in connection with the Figures as follows: Section
As with the external physical configuration shown in
Similarly, other computers at
The present invention is embodied in a product called WebCenter™, manufactured and distributed by Acuity, Corp. The WebCenter design includes three distinct subsystems referred to as the Web Response Unit (WRU), WebACD and Communications Interface Unit (CIU). The WRU handles initial customer interaction with the system. The WRU allows a customer to obtain information independently, such as by querying a database, compilation of Frequently Asked Questions (FAQ) or other information source. The WRU manages the customer login process, provides for self-help searching of knowledge bases, tracking of customer issues and their resolution. The WRU provides interfaces for connection with other data systems' databases for knowledge searches. If the customer cannot find the appropriate information from the WRU then the customer can escalate to the WebACD and talk to a live agent.
Once a customer call has been escalated, the WebACD manages interaction between customers and agents, forwards unresolved issues to human agents and routes customer requests for agent interaction. The WebACD supports interfaces to traditional ACD systems allowing those call center agents to operate in both telephony and Web support roles. Links to these traditional ACD systems will allow the WebCenter to mark agents as "busy" when they are handling Web-based issues, and streamline the agent tracking process by using the ACD system agent ID numbers for identification and authentication.
The CIU manages the physical communications channels between customers and agents. In a preferred embodiment, the CIU module provides real-time text discussion, or chat, with multimedia extensions allowing agents and customers to interact immediately to solve a particular problem. The CIU also provides a number of interfaces to extension modules, including computer-telephony integration (allowing customers to request a telephone call-back) and H.323 (i.e., "voice packet," or "packet over IP") to PBX integration. The latter function allows agents to speak with a customer via their telephone handset, while the customer uses an internet phone (H.323 compliant software) on their end of the connection.
Events such as a customer call or other form of question origination can be from the WRU, specifically, or the corporate web site in general. For example, a customer may be browsing the corporate web site for information and can access information through the WRU. Some of the customer inquiries can be handled in an automated fashion through databases where the customer interacts with a process. At some point the WRU may determine that the customer's inquiry needs to be serviced by interaction with a human agent. At this point the inquiry is escalated to WebACD
Calls are queued within the WebACD and are assigned to agents based on numerous factors including the type of communication (e.g., chat, email, voice, web-page, IP voice), availabilty of agents, agent efficiency with respect to a communication type, and customer priority rating. When an agent successfully answers a question in certain types of communication, such as email, the answer is provided to the customer and may also be used to update a database so that the answer can be provided in an automated fashion the next time the same or similar question is asked.
At step
At step
At step
Assuming that the customer initiates the session within the timeout period, step
Once an agent has been assigned to the call, step
Other events may wake the task at either of steps
Assuming, at step
The case where an agent disconnects abnormally is handled by steps
The case where the customer becomes absent results in step
After termination, step
The WebCenter allows a single agent to handle more than one call at a time. Each agent is allocated, or assigned, a number of "endpoints." An endpoint can be thought of as a communication line over which information can be exchanged with a single customer. The ability to allocate multiple endpoints to a single agent helps maximize agent effectiveness.
The process of assigning an agent to a call is executed after WRU escalation process determines that a customer's call should be assigned to an agent. Although there are many possible ways to determine whether and how agents, and agent endpoints, are assigned, the present invention operates using the following criteria.
Central to the assignment of calls to endpoints is the notion of a "state" for each endpoint. In the preferred embodiment, each endpoint can be in one of four states. These states are as follows: (1) available=the endpoint is not being used and can be assigned to a call; (2) idle=the endpoint is not being used but cannot be assigned to a call; (3) talk=the endpoint is presently assigned to a call and cannot be assigned to another call; and (4) wrap=the endpoint if finished with a call but bookeeping and reporting with respect to this endpoint is being performed so the endpoint cannot yet be assigned to another call.
Naturally, schemes for assigning calls to endpoints, or agents, can vary widely. For example, another scheme can delete one or more of the states above such as the "wrap" state. Another scheme can use additional states such as a "suspended" state where the call has been placed on "hold."
Using the four states above, a basic formula for assigning agents is to assign the next call to the least-busy agent according to the ratio
#assignable endpoints
_ _ _
#agent allocated endpoints
which is computed for each agent.
Thus, the larger the ratio, the less busy is the agent. For example, assuming agent
Assume agent
Allocation of endpoints can be made by agent supervisors. Additionally, the preferred embodiment allows each agent to have some control over their endpoint allocation. By using buttons on the agent user interface as described below, each agent can increase or decrease their endpoint allocation dynamically.
A refinement to the call allocation approach is to take into consideration the communication type. That is, calls that are coming in on a chat channel can be ratioed separately from calls coming in from IP voice channels. In other words, if agent
Another refinement is to take into account the efficiency of an agent with respect to different communication types. For example, if agent
Another refinement is to assign calls based on customer ranking. For example, a customer ranking according to level of service (e.g. whether the customer is a "gold," "platinum," overly-repetitive, etc. customer) can be implemented to assign a number to customers that allows a customer to be moved up in a queue, to be assigned to a different queue, or to other wise gain priority over other customer calls. For example, customers who have emergency situation can be passed through to an agent regardless of their position in a queue. Or even regardless of the availability of agents according to the normal approach using the ratios above.
Row of buttons
The "close endpoints" button reduces the endpoint limit to zero for a particular agent. It is used by an agent when the agent does not want any new calls. However, any calls that are already open, or in session, remain active. The use of the "close endpoints" button allows the agent to stop any new incoming calls from being assigned to the agent. The "create new resource" button causes a new, untitled, resource to appear in the Resources window, discussed below. The "WebCenter Home page" button displays the call center's home page in the agent's browser window. The home page typically includes statistics, information links, utilities, etc., particular to the specific installation that is hosting the call center. The "customer data" button brings up records, statistics and other data for a current customer. The "NetMeeting" button initiates a NetMeeting session that allows the customer and the agent to share screens, pointers and further facilitates communication between the customer and agent. For a description of NetMeeting session characteristics see, e.g., http://www.microsoft.com/netmeeting/sdk/.
Returning to
Communication window
Resource window
The pre-defined resources are useful where the agent has certain Internet web pages that are often referred to a customer, or where the agent frequently needs to provide the same text information to customers. In
Resource creation window
The indicators at
A. Introduction
Reporting is vital to the operation of an efficient call center. Through real-time reporting, the call center manager can determine how well customers are being serviced, how well agents are performing, and how well the system in general is operating as it happens. This kind of information is very useful to perform ad-hoc staff changes, identify and assist agents who are having difficulties, and recognize failed hardware or software. Historical reports help the call center manager look at all of those factors in the past, where the information can be more carefully analyzed to produce a more efficient call center in the future.
Acuity's WebACD has been specifically designed to provide very detailed reporting information on a real-time and historical basis to the call center manager. This document describes the kind of data this collected, the rationale behind the data, and how it can be used to make the WebCenter more efficient. Examples of reports are shown in
B. Background
For further discussions, it is necessary to understand the terms used in WebACD reporting. These terms have very specific means in the context of the WebACD so the call center manager can know exactly what each value means as he seems it.
B.1. Basic Terms
The following terms listed in Table I form the foundation for WebACD statistics computations.
|agent -
|An agent is an employee of the call center who
|communicates with customers. Customers are
|individuals who escalate to the WebACD from
|the Internet. This is the person contacting
|the agent.
|team -
|A team is a collection of agents who have
|similar abilities. An agent must be in one,
|and only one, team. typically tasks are
|queued for teams and the first agent to
|become available in the team will receive
|the task.
|task -
|When a customer connects to the WebACD,
|he creates a task. In a telephony call
|center, this would be a "call,"
|but since we handle many different media
|types, Acuity uses the term "task."
|task type -
|When the customer escalates to the WebACD,
|a task type is specified. Typically this
|is encoded in the live help button. For
|example, if the customer asks for live
|help on a product information page, the
|task type might be "Sales." If he
|asked for help while looking at a list of
|known defects, the task type might be
|"Support." In a traditional call
|center, this is called a "call type"
|or "application." Statistics are
|collected against the task type so the call
|center manager can look at how customers who
|asked for Sales and customers who asked for
|Support are being serviced.
|task id -
|Each task in the system is assigned a unique
|number called a "task id." This number
|is two parts, separated by a dash. A sample task
|id is 5-23. In this example, 5 is called the session
|number. Each time the WebACD is restarted, the
|session number is incremented by one.
|The second part, 23, is the task number
|for that session.
|The task number starts over at 1 when the session
|number is incremented.
|When a customer escalates, his task is assigned
|task id -
|a unique task id and the original task id for
|his task is set to be the same as the task id.
|If, during a conversation with an agent, the task
|is transferred to another agent, the act of
|transferring generates a new task which has a new
|task id, but the same original task id as its
|parent. This allows reports to treat transferred
|tasks individually or grouped into customer
|sessions. (Transfer is not available in WebCenter
|Express, so in that product, the original task
|id is always equal to the task id.)
|A "completed" task is one in which the
|task -
|agent and customer have finished working on
|the task and the customer talked to an agent.
|Compare this to an abandoned task.
|A task is abandoned if a customer ended the
|task -
|session before speaking with an agent. In a
|traditional call center, this is equivalent
|to the customer hanging up the telephone
|while waiting in the queue.
|endpoint -
|Agents in WebCenter can handle more than one
|task at a time. Each task is delivered to an
|"endpoint" on the agent client. Think
|of an endpoint as a telephone on the agent's
|desk. If the agent has two endpoints, then he
|can receive two calls at the same time.
|Likewise, if an agent has two endpoints, he
|can receive two tasks at the same time.
|route time -
|Technically, route time is the length of time
|between when the customer presses the live
|help button and the customer is placed in a
|queue. Practically this measures the amount
|of time it took the customer to down load
|the customer client.
|queue time -
|Queue time is the amount of time that a
|customer spent waiting for an agent to
|arrive and help.
|talk time -
|Talk time measures the length of time that a
|customer and agent were in conversation.
|wrap time -
|After an agent finishes the conversation,
|he "wraps" the task. In a traditional
|ACD, this is equivalent to hanging up the
|telephone. Once the conversation has completed,
|the agent may have to do some post-call work
|such as fill out paper work from the
|conversation that just ended. Wrap time is the
|amount of time the agent spent in that state.
|handle time -
|Handle time is the sum of talk time and
|wrap time. It represents the amount of
|time an agent spent handling a task.
|service level
|Service level threshold is a queue time
|threshold -
|goal for a particular task type. This
|value will be used for computing service
|sign on time -
|Sign on time is the amount of time the
|agent has spent signed on to the WebACD.
|idle time -
|Idle time is the amount of time the
|agent spent in the idle state. An agent
|is in the idle state if he has no
|available endpoints and is not working
|on any tasks.
|available time -
|Available time is the amount of time each
|endpoint of agent is available. Since this
|value is based on endpoints rather than the
|whole agent, it is "double counted"
|for one agent. In other words, if an agent
|has two endpoints that are available for an
|entire ten minute period, then his available
|time will be 20 minutes. For this reason,
|available time is never reported directly
|in WebCenter, it is only used in other
|talk time
|Talk time for an agent, like available time,
|(for an agent) -
|is double counted because an agent can be
|talking to more than one customer at a time.
|Like available time, talk time is never
|reported directly for this reason.
|wrap time
|Since an agent can be wrapping more than one
|(for an agent) -
|task at a time, it is double counted just
|like available time and talk time. Therefore
|wrap time for agents is never reported
B.2. Computed Values
From the raw data that the WebACD collects a number of useful values can be calculated. This section describes how those calculations are done in standard WebACD real-time and historical reports. If these calculations do not meet the needs of a call center manager, the raw data used for the calculations is also available so different computations can be done.
B.2.i Completed Statistics
Completed statistics are values computed after a task has completed. For a traditional ACD, this is how most, if not all statistics are calculated. The next section will describe ongoing statistics and how they differ from completed statistics.
The definitions provided here are generic, so it is assumed that all statistics are calculated over some group of tasks. For example, we might be computing average handle time for the tasks that particular agent handled or for all the tasks of a given task type.
Average route time—Average route time for a given group of tasks is the average route time for those tasks. It is computed by (sum of route time for all completed tasks)/(number of completed tasks). Note that this value only computes route time for completed tasks, not abandoned tasks. This value is a good measure of connection speeds for customers. Over a 28.8 modem the route time will be between 30 and 60 seconds. For a local Ethernet connection, the route time will usually 2 seconds or less.
Average queue time—Average queue time is computed by (sum of queue time for all completed tasks)/(number of completed tasks). Note that this value does not included abandoned tasks, so if a customer abandoned, his queue time is not counted toward this statistic; it is counted toward average wait before abandon. This value measures how long customers are waiting to speak to an agent. Queue time is very important factor in managing customer satisfaction with a call center.
Average talk time—Average talk time is computed by (sum of talk time for all completed tasks)/(number of computed tasks). This value is usually used to measure the efficiency of agents because it measures the amount of time an agent spent talking with a customer. For example, in a technical support context, this can measure how quickly agents are able to answer customer questions. In a sales context, it might measure how long the agent is able to keep the customer engaged. Note that this value is computed from the agent perspective, not the customer perspective. In a transfer situation, if AgentA transfers to AgentB, but continues to chat, even after AgentB arrives, then talk time will be accumulating for AgentA as well as AgentB. This statistic measures the amount of time AgentA and AgentB spent talking to the customer, but not how long the customer spent talking to any agent.
Average wrap time—Average wrap time is computed by (sum of wrap time for all completed tasks)/(number of completed tasks). This is a good measure of the amount of time agents spend in post-call work. In a transfer scenario, each agent has his own wrap time. average handle time—Average handle time is computed by ((sum of talk time for all tasks)+(sum of wrap time for all tasks))/(number of completed tasks). This value is a good measure for how long agents are spending on average to handle tasks. As described under average talk time, this measure is from the agent, not the customer perspective.
Service level—Service level is the percentage of task that were answered by an agent before the service level threshold. This value is computed by (number of tasks with queue time less than the service level threshold)*100/(number of completed tasks). Service level is a good way to tell whether or not a call center is answering tasks efficiently. Unlike average queue time, it will not be skewed by very large or very small queue times because it says "this percentage of tasks were answered within x seconds."
Abandon rate—Abandon rate is the percentage of customers who abandoned before speaking with an agent. It is computed by (number of abandoned tasks)*100/((number of completed tasks)+(number of abandoned tasks)). High abandon rates can signal unhappy customers because they get tired of waiting and exit.
Longest wait before abandon—Longest wait before abandon is a measure of the amount of time that the most patient customer was willing to wait before abandoning the task. This value is computed by looking at all the abandoned tasks and finding the one with the largest route+queue time. It can be used to manage queue times because it tells how long the most patient customer was willing to wait.
Average wait before abandon—Average wait before abandon is the average amount of time a customer was willing to wait before abandoning the task. This value is computed by ((sum of route time for all abandoned tasks)+(sum of queue time for all abandoned tasks))/(number of abandoned tasks). Since this value tells the average amount of time a customer was willing to wait before abandon, this value can be used in conjunction with longest wait before abandon to manage queue time.
B.2.ii Ongoing Statistics
While completed statistics are used to find averages about tasks, ongoing statistics are used to compute agent utilization and averages of concurrent items. For example with ongoing statistics, you can compute the percentage of time an agent spent in talk as well as the average number of calls in queue. To understand how this can be done, it is important to first understand how ongoing statistics are gathered.
Ongoing statistics differ from completed statistics in the time at which the time is counted. Statistics in the WebACD are collected in one minute "buckets." Let's say a task was in route from 5:00 to 5:01, queue from 5:01 to 5:03, talk from 5:03 to 5:09 and wrap from 5:09 to 5:09:45. When computing completed route, queue, talk, and wrap times, the values will all be added to the 5:09 bucket and the number of tasks completed will be incremented by one in the 5:09 bucket. If this is done for several tasks, then the average queue time can be calculated by dividing the queue time accumulated in the 5:09 bucket by the number of tasks completed in the 5:09 bucket.
Ongoing statistics are not counted at the end of the task. Instead they are calculated as they happen. In the case out lined above, the 5:00 bucket would have 60 seconds of route time, the 5:01 and 5:02 buckets would each have 60 seconds of queue time, each of the buckets 5:03 through 5:08 would have 60 seconds of talk time, and 5:09 would have 45 seconds of wrap time. Note that calculating average queue time with these values is not possible. If there were several tasks, then it is unclear what the queue time was for any one task, just that from 5:05 to 5:06 there was one task in queue. Note that if there were two tasks in queue from 5:05 to 5:06, then the 5:05 bucket would have 120 seconds of queue time. Note that if we divide 120 (the queue time summed in the 5:05 bucket) by 60 (the length of the bucket), that we get 2, which was the number of tasks in queue. Likewise, there were two tasks, each in queue for 30 seconds, the bucket would sum to 60 seconds and the division from above would yield
Using ongoing statistics, we can compute the following values.
Average number of tasks in queue—Given a period of time, the average number of tasks in queue is the average number of tasks that were in the queue over that period of time. This can be computed using the formula (sum of queue time for all tasks that should be included in the average)/(period length). This value allows the call center manager to look at queue length trends. In a historical report, this value is useful because it provides queue length, which is normally an instantaneous value, over a period of time. During real-time reporting, this value is more stable than straight queue length, which can fluctuate a great deal up and down based on how tasks arrive and how agents handle tasks.
Average number of signed on agents—Given a period of time, the average number of signed on agents is the average number of agents who were signed on during that period. This can be computed by the formula (sum of ongoing sign on time for all agents which should be included in the average)/(period length). This value can be used to compute the number of agents who are working over some period of time, given that the agents may come and go often. For example, if the call center has two agents and they both work 30 minutes, take a 10 minute break, work another 30 minutes, take another 10 minute break, and so on, then this calculation could show you that you are paying for 2 full-time agents, but combined they are only acting as 1.5 full-time agents.
Average number of endpoints—The default WebCenter agent client allows agents to choose how many endpoints they have, and thus how many concurrent tasks they can handle. Given a pool of agents and a period of time, the average number of endpoints is the average number of endpoints that those agents had available during that period of time. To compute this value, the WebACD uses the quotient (ongoing available time for the agents+ongoing talk time for the agents+ongoing wrap time for the agents)/(period length). From the definitions in section
Percent idle time—Percent idle time is the percentage of sign on time that the agent spends in the idle state. This is computed by (sum of ongoing idle time for agents)*100/(sum of ongoing sign on time for agents). Remember that these are ongoing statistics, so if, over a ten minute period, the agent is signed on for all ten minutes and idle for two of those minutes, then his percent idle time would be 20%. In the idle state, the agent is taking a break. He is still signed on, but he cannot receive additional tasks and he is not currently working on any tasks. For companies that like to use sign on time as a kind of time clock, idle time provides a way for the agent to take a break while still "on the clock." This value is useful because it tells what percentage of time an agent spent in the idle state.
Percent available time—Percent available time is the percentage of an agent's working capacity that he spends available. This value is impacted by the number of endpoints that an agent has selected for himself, but not the maximum number of endpoints that an administrator has assigned to him. It is computed via the formula [(ongoing sign on time for the agents—ongoing idle time for the agents)/(ongoing sign on time for the agents)] 100*[(ongoing available time for the agents)/(ongoing available time for the agents+ongoing talk time for the agents+ongoing wrap time for the agents)]. The second half of the formula, in square brackets, computes the percentage of working time the agent spent available, where working time is (available time+talk time+wrap time). To illustrate, imagine over a ten minute period an agent had two endpoints available the whole time and a third one in talk the whole time. In this case, ⅔ or 67% of the agent's working time was spent available. This says that only 33% of the agent's working capacity is being utilized. The first have of the formula is used to normalize the percentage with idle time. Since idle time is not double counted, this provides a way to show what percentage of an agent's total capacity is spent available, not just the percentage of his idle capacity. This value is useful for identifying under utilized agents. If a large percentage of the agent's capacity is available, then the agent is under utilized. When comparing percent available time between agents, it is very important to also compare their average number of endpoints. An agent with an average number of endpoints of 1.0 and a percent available time of 50% is spending 50% of his time sitting, waiting for a task to arrive. If another agent has an average number of endpoints of 2.0 and also a percent available time of 50%, then on average he is always working on one task.
Percent talk time—Percent talk time is very similar to percent available time; it measures the percentage of an agent's capacity that is spent talking to customers. This value is computed using the formula [(ongoing sign on time for the agents—ongoing idle time for the agents)/(ongoing sign on time for the agents)] 100* [(ongoing talk time for the agents)/(ongoing available time for the agents+ongoing talk time for the agents+ongoing wrap time for the agents)]. Like percent available time, when comparing the percent talk time performance of two agents, it is important to also compare the average number of endpoints for that agent.
Percent wrap time—Percent wrap time is very similar to percent available time; it measures the percentage of an agent's capacity that is spent in post-call work. This value is computed using the formula [(ongoing sign on time for the agents−ongoing idle time for the agents)/(ongoing sign on time for the agents)] 100*[(ongoing wrap time for the agents)/(ongoing available time for the agents+ongoing talk time for the agents+ongoing wrap time for the agents)]. Like percent available time and percent talk time, when comparing the percent wrap time performance of two agents, it is important to also compare the average number of endpoints.
Average number of tasks being handled—Because agents can handle more than one task, it is important to compute the average number tasks that the agent handles concurrently. Given a period of time and a pool of agents, this value can be computed by (ongoing talk time for the agents+ongoing wrap time for the agents)/(length of the period). Especially early in deployment, this value should be monitored because it tells the call center manager how many tasks an agent can handle at the same time.
B.3. Report Naming Conventions
To make it easier for the call center manager to understand exactly which report he needs, Acuity has devised a set of naming conventions for reports. The rules are as follows: If the report requires a parameter, then use "For<ParameterName>X". For example, TasksForAgentX iterates over all tasks handled by an agent whose name is specified by the report generator.
If the report contains nested iterations, the top level iteration is first, then "By," followed by the inner iteration. For example, TeamPerformanceByAgent iterates over all teams, but iterates over all agents within a team before moving on to the next team.
If the report iterates only once, then use "For" and the quantity iterated over. For example ActivityForAlITaskTypes simply reports on the activity seen in each task type. Another example is TasksForTaskTypeX, which lists all the tasks for the specified task type
If the report is for a specific date, then use "OnDayX". For example, TaskTypeXActivityOnDayY reports the activity for one task type on one particular day, where the task type and the day are specified by the person generating the report.
C. Standard Reports
As part of WebCenter Enterprise and WebCenter Express, there are a number of standard reports that provide a foundation of reports on which companies can build reports customized for their business processes.
Enterprise Reports—All WebCenter Enterprise reports are written in Crystal Reports, the industry standard reporting package. Using Crystal, customers can generate paper or web based reports. The following sections describe the reports which are shipped with WebCenter Enterprise and how they should be interpreted.
DailyActivityForWebACD—Given a range of days, this report gives a summary of activity that happened on each day for the entire WebACD. Since the calculations are for the entire WebACD, all agents and all task types are included in the summaries. This report is useful for getting an overall summary of the system behavior. For more detail, look to the WebACDActivityOnDayX and task type and agent reports.
WebACDActivityOnDayX—Given a date, this report lists activity during different types of one day. The length of the time interval used in the report is configurable and can be as short as one minute or as long as one hour. The columns Start and Stop specify the time interval that the row covers. If an interval is missing, then all the values for that row would have been zero.
Remember from section B.2.i that the fields Completed, Abandoned, Service Level, Queue Time (avg), and Handle Time (avg) are computed as tasks complete. This means that for a task to be included in these calculations, it must terminate during the specified time interval.
Like DailyActivityForWebACD, DailyActivityForTaskTypeX takes a date range and a task type and then reports the performance of that task type for each day in the date range. This report is useful for comparing the performance of one task type over all the days in a week or month. For example, this report may show that after a large promotion, the number of tasks to the Sales task type increased, or that the day before a holiday agents do not service tasks as quickly as they do on other days.
TaskTypeXActivityOnDayY—Like WebACDActivityOnDayX, TaskTypeXActivityOnDayY reports performance for different times during one day, only this report is for one particular task type. The length of the intervals is configurable in the WebACD administration pages, so the WebCenter manager can change the interval to suit their needs based on how much detail he would like in his reports. This report is useful for looking at the performance of a single task type throughout the day. For example, this report may tell the WebCenter manager when he should schedule agents for lunch, based on typical call volumes.
Remember from section B.2.i that the fields Number Completed, Number Abandoned, and several others are computed as tasks complete, and from section B.2.ii that Tasks in Queue (avg) and Tasks Being Handled (avg) are calculated on an ongoing basis. As a result, the completed statistics may lag the ongoing statistics. For example, one period may have a large number of tasks in queue, which would translate to a large number of completed (or abandoned) tasks in the next period.
ActivityForAllTaskTypes—Given a date range, this report summaries the activity during that date range for each task type. This report is useful for comparing the performance of different task types. For example, it allows the WebCenter manager to verify that the queue time for sales tasks is lower than the queue time for support tasks. For most WebCenters, this will be the most basic overall report.
TasksForTaskTypeX—This report lists all of the tasks that arrived for the specified task type during a range of dates. If other reports give information that looks anomalous, this report can tell exactly which tasks were used to generate the reports.
Remember that if a task is transferred, it receives new Task ID, but keeps the same Original Task ID. This report shows how tasks were transferred be grouping tasks by their Original Task ID. Grouping the tasks in this way lets the WebCenter manager quickly see all of the agents that handled a particular customer. A transferred task can be abandoned if the agent cancelled the transfer before the second agent arrived or if the customer abandons the task all together while waiting for the second agent to arrive.
TeamPerformanceByTaskType—TeamPerformanceByTaskType is the most basic team performance report. Through Plaid the WebCenter administrator can make multiple task types queue for multiple teams. This report allows the WebCenter manager to watch how each team in the WebACD performs against each task type they serve.
Note that several of the columns on the left are reported just for the entire team, not for individual task types. This is because those statistics cannot be divided into task types. For example, an agent is signed on, but signed on for a particular task types, so reporting signon time against different task types does not make sense.
TeamPerformanceByAgent—TeamPerformanceByAgent allows the WebCenter manager to look at the performance of individual agents during the specified range. The agents are grouped by team so agents handling similar types of tasks will be grouped together and can be compared.
Remember from section B.2.ii that when comparing the percent available, talk, and wrap, for agents that it is important to also consider the average number of endpoints for each agent.
TasksForAgentX—Much like the report, TasksForTaskTypeX, this report allows the WebCenter manager to look at all of tasks that were used to compute other statistics. However, this report does not show abandoned tasks or how a task was transferred. For that information, see the TasksForTaskTypeX report.
Note that even though this report specifies the queue time for each task the agent handled, this value should not be used as a performance metric of the agent. The queue time for the task is a function of how the routing has been implemented in the routing scripts and how quickly the teams assigned tasks are servicing them. However, this value does allow the WebCenter manager to see how long customers are waiting before they talk to this agent. If customers are continually dissatisfied by an agent and the customers who get to that agent have been waiting a long time, it may be that the customers were quite upset before even arriving at the agent.
Plaid is the scripting language used by Acuity's WebACD to customize how tasks are routed as they arrive off of the web site. The name Plaid is a word, not an acronym. This document explains what one should consider when building Plaid scripts as well as the syntax of the language.
Information to Gather
This section describes the information that one should gather before attempting to create Plaid scripts. Collecting this information, which defines the business requirements for Plaid, is important before writing scripts so the purpose and requirements of the scripts are well-defined before starting.
Define Task Types
The first step in creating scripts is to define the task types that will be used. Task types represent the different ways for a customer to enter the WebCenter. For example, there might be one task type called Sales and another called Support for customers with product information and technical support needs, respectively. Each task type can have its own script that executes. Furthermore, statistics are collected per task type so the WebCenter manager can look at the performance of the WebCenter on a task type by task type basis. The following sections describe some considerations when creating task types.
More broadly defined task types may be easier to maintain. The broader the task types are, the fewer entry points customers have to the WebACD and probably the few the scripts that need to be written and maintained. Likewise, broader task types often imply larger teams of agents, so it may be easier to maintain agents in larger, rather than smaller teams.
Broadly defined task types create more stable statistics and narrowly defined task types create more specific statistics. A large number of the statistics collected in a WebCenter are averages. The larger the pool of tasks for that average, the more "stable" the statistics will be from one day to the next. For example, if a task type is so narrow that it only has a few tasks a day that arrive, then one long task could skew the statistics for a task type that whole day. On the other hand, if the task types are too broad, then the statistics collected are not precise enough to provide meaningful information. For example, WebCenters often have different wait type requirements for customers requesting sales versus customers requesting technical support. If those two task types were grouped together, then the wait time statistics generated for that task type would not allow the WebCenter manager to decide whether the wait times for each group was satisfied.
Customer Interface
Topic through the WRU. In the WRU, there is a concept of a topic. Questions answer pairs are grouped by topic so customers can browser through the questions and answers, looking for the information they need. When creating a topic in the WRU, the administrator is also asked to specify a task type for the WebACD so when a customer escalates from a certain topic, the WebACD knows which task type to use. Many topics can go to one task type, but there must be at least one topic per task type. Typically a customer must select a topic when asking a questions, so if there are a very large number of topics, the customer may be confused as to which one to select.
Selection of task type from drop down. When the customer asks a question, he can pick a task type form a list that is populated from the WebACD. Again, if there are too many task types or their names are not meaningful to a customer, then the customer may be confused as to which task type to select.
Pressing a LiveHelp button. If all the customer does is press a LiveHelp button, the task type can be implied based on where he came from in the web site. In that case, it is important to recognize that the web site must be maintained with the appropriate task types.
Historical Comparisons
Task types should not change very often so the WebCenter manager can do historical comparisons of different task types. For example, the WebCenter manager may want to look at the number of tasks that came in for the task type CorporateSales over the last year. If half way through the year CorporateSales was combined with FieldSales to from the task type Sales, the WebCenter manager is not going to be able to go back over the year and look at the performance of CorporateSales.
Define Teams
Once the task types have been defined, the teams that agents should belong to need to be created. In a preferred embodiment, an agent can only be in one team. Teams were designed this way for reporting. Certain statistics, including available time and idle time can only be accounted toward an agent's team if the agent is only in one team. Then when it comes to routing tasks, the script can place the task in queue for multiple teams. Other embodiments would assign an agent to multiple teams, and be assigned on a first-come first-served basis.
Routing Specificity
This section describes some of the areas that should be considered when creating teams.
The smaller the teams are, the more specific the routing of tasks can be. For example, there could be one team called TechSupport or two teams, MonitorSupport and PrinterSupport. The latter scheme would allow routing to agents who are more likely to be able to answer the customer's question. Task types largely define how specific the teams should be because if there are not separate task types for monitor support and printer support, then it is impossible to distinguish those types of tasks in the WebACD, and thus route to different teams.
Queuing Efficiency
The larger the group of agents that a task queues for, the more efficiently the task will be answered. This is because in a small team, customers who talk to one agent for a very long period of time can keep that agent from talking to other customers, thus holding up the queue. If the task is queued for a large group of agents, this problem is alleviated because other agents can handle tasks as the one customer spends a lot of time with an agent. The WebACD allows the customer to queue for more than one team, so small team size just means that the script would have to list several teams.
Larger teams may be easier to maintain. If teams are very small, then the scripts that send tasks to those teams must be kept up to date as teams are created and destroyed.
Larger teams create more stable statistics and smaller teams create more specific statistics. A large number of the statistics collected in a WebCenter are averages. The larger the pool of agents for that average, the more "stable" the statistics will be from one day to the next. For example, one agent has a very bad day and is idle for nearly the whole day, then that one agent could skew the statistics for the whole team. In larger teams, the effect of that one agent would be smaller.
Historical Comparisons
If the WebCenter manager is interesting in doing historical comparisons of teams, it is better not to create and destroy teams often, which is more likely to happen with small teams. For example, through historical reports, the WebCenter manager may be able to predict how agents will perform around the Christmas holidays. If teams are very small, this comparison would be much harder.
Associate Teams with Task Types
Once the task types and teams are defined, it is time to decide which teams should service each task type. Usually a task type will have primary teams, which are the "first line of defense" for a task type. These are the agents who are probably best qualified to handle the tasks. Then there is usually a set of backup teams for task type. If a customer waits too long, then the customer gets placed in queue for the backup teams. These could handle the task, but are not the first choice. Using backup agents allows the customer's task to be answered in a reasonable amount of time by someone who can probably help.
Decide the Hours of Operation
For each task type, the hours that that task type will accept tasks needs to be defined. The WebACD can be programmed to turn escalations on and off so if a request comes in after hours, the WebACD will send a message to the customer saying that the WebCenter is closed. If all task types have the same hours of operation, then that will simply this customization, but for many environments that is not possible.
Building Scripts
This section describes how to write Plaid scripts. Rather than focus on the exact syntax for Plaid, this section will focus on the usual components of a Plaid script.
Write a Basic Plaid Script
A script usually has the following components shown in Table II:
|Queue for primary teams
|Queue for backup teams
|Wait indefinitely
This section will describe how to build a script with each of those sections. Table III shows a basic script that has all of those sections.
|Say("Thank you for contacting Acme Support.")
|Say("Continue browsing. When an agent arrives, you will")
|Say("be notified through a pop-up in your browser.")
|ACD.GetTeam("PrimaryTeam1").Enqueue( )
|ACD.GetTeam("PrimaryTeam2").Enqueue( )
|Say("Please continue to wait . . . ")
|ACD.GetTeam("BackupTeam").Enqueue( )
|while true
|Say("Please continue to wait . . . ")
The following sections describe factors that should be considered when writing a script like this one.
A greeting should reassure the customer that he has been placed in a queue for agents. The concept of a web-based call center is very new, so customers may be unsure of themselves as they try to use the WebCenter at first. The customer should be told they are in a queue for an agent and that they can use the right-hand pane of their window for browsing. He can also be told to expound on his question in the transcript window. Then when the agent arrives, the customer will have fully explained the problem and the agent can read it hopefully handle the task more quickly.
Queue for Primary Teams
In the script above, customers will be placed in queue for the teams PrimaryTeam
After placing the customer in queue for the primary teams, the typical script will wait for an agent in those teams to answer the task. In this example, the script waits for 30 seconds. If, after 30 seconds, an agent from PrimaryTeam
Queue for Backup Teams
After waiting for an agent in one of the primary teams to answer, the task should be queued for the backup teams. When the task is placed in queue for the backup teams, the customer goes to the end of the queue for the backup team. To make the customer jump ahead of other customers waiting in that queue, priority can be used, which is described below. Once the customer is in queue for the primary and backup teams, the first agent in any of those teams who becomes available will be assigned to the customers.
Wait Indefinitely
If a Plaid script ends, then the customer will be disconnected and the task will be finished. As a result, the Plaid script must wait for someone from one of the primary or backup teams to handle the task. There are two ways to do this. The way shown above, with an infinite while loop will give the customer feedback every 30 seconds that he is still in queue for an agent. This may be particularly important since there are several web-based call centers on the market that drop customers so they wait indefinitely and never get serviced by an agent. However, giving customers notification every few seconds is less efficient in the WebACD and for WebCenters with very large call volumes, it is probably better to just say Sleep(−1), which will wait indefinitely.
Installing Scripts
Once the script is written, it should be installed. To install a script, it should be associated with a task type. Then when an escalation comes in for that task type, the script will be executed. Note that as scripts are created, each edit creates a new version. Then to make the system execute the script, the appropriate version must be activated. All of this can be done while the WebCenter is running. If the new version doesn't work, then the WebCenter administrator can activate the previous version so the WebCenter can continue operation as usual.
Hours of Operation
There are two ways to turn off escalations to the WebACD. First, through the administration pages, escalations can be redirected to a different page that tells the customer that the WebCenter is closed. The page can be specified so customers can receive different messages based on why the WebCenter is closed. For example, if the WebCenter is closed for a holiday, the closed page could say that. The second mechanism is through Plaid, which will be described here.
To make the WebCenter open from 8 AM until 5 PM, Monday, through Friday, the greeting described above would be preceded by the following Plaid script.
if Weekday(Now( ))<1 OR Weekday(Now( ))>6 OR
Time(Now( ))<#800# OR Time(Now( ))>#1700# then
Say("I'm sorry, we are closed. Please come back.")
rest of the script
This script will test to see if it is Sunday or Saturday. If it isn't then it makes sure it is between 8 AM and 5 PM. If it isn't, then it prints out a message saying it is closed and waits 10 seconds before terminating the script to give the customer a chance to read the message. Otherwise the script executes as normal.
Plaid can also be used to personalize the service that customers receive. This may be something as simple as placing their first name in the greeting or something as complicated as changing how routing is done based on how much service the customer has paid for. The former can be done by default. The latter requires writing a servlet to create customers with special attributes.
To just print the customer's name, the following script can be used.
if ACD.GetCustomer( ).GetValue("firstname")< >" " then
Say("Hello" & ACD.GetCustomer( ).GetValue("firstname"));
The test is necessary because firstname is not a required field, so the customer may not have entered it when creating the customer record.
To test for the service the customer has paid for, you might do something like
if ACD.GetCustomer( ).GetValue("service")="gold" then
Say("You are a gold customer")
Say("You are a regular customer")
ACD.GetTeam("RegularTeam").Enqueue( )
This code will enqueue the customer with high priority for the GoldTeam if he is a gold customer and for the RegularTeam with normal priority if he is not. In order to do something like this, the customer servlet would have to be modified to add the field "service" to the user record. Acuity's consulting services can assist you with that process. Using Priority
In the WebACD, there are five levels of priority that it uses for queuing tasks, low, normal, high, urgent, and system. The bottom four levels, low, normal, high, and urgent, can be set and changed in the Plaid script using the Enqueue( ) function. The highest priority, system, is reserved for the WebACD. It is the priority assigned to transferred tasks. In the WebACD, if two tasks are queued for a team and one has higher priority, that task will always be answered before a task with lower priority. This is a very important consideration when using priority because it can result in "starvation." If too many high priority tasks are assigned to one team, then the lower priority tasks queued for that team will never get answered.
Here is an example of using priority when queuing. Assume this is a script for regular customers who often spend money.
ACD.GetTeam("GreatSales").Enqueue( )
This script will enqueue the customer for the team GreatSales and then wait for 20 seconds. If an agent doesn't answer, then he will be queued for GeneralSales with high priority, which means that customer will be serviced before the general sales customers are.
Plaid Syntax
The following sections describe exactly the syntax that can be used in a Plaid script.
An expression is the most basic construct in Plaid. An expression is a collection of symbols in Plaid that can be evaluated into one value. In Plaid, values have different types. This allows Plaid to be what is called a "type safe language." In other words, when a number is expected, you can't use a string of characters instead.
Plaid has the following types defined.
Long—A Long represents a 32-bit integer. Use this type to represent integers such as 1, 30045, or −245.
Double—A Double represents a double precision floating point number, which means you can use it to represent values like 4.6, 3.14156, or −2.45e10.
String—A String is a sequence of characters such letters, numbers, and spaces. Use values of type String to represent messages like "Please continue to wait."
DateTime—A DateTime repesents a specific date and time. In Plaid, DateTime values can be accurate to the second. Use values of type DateTime to represent values such as #7/23/73 5:03# for Jul. 23, 1973 and 5:03 AM or #18:24# for 6:24 PM.
Boolean—A Boolean represents true or false.
ACD—A value of type ACD represents the entire ACD. This type is used to get teams that are defined on the ACD, defined agents, etc.
Team—A value of type Team represents a team defined on the WebACD. This type is basically used to enqueue and dequeue tasks from teams.
Customer—A value of type Customer represents the customer that has escalated to create the task that is being executed for this script. This value is used to retrieve attributes defined on the customer.
Agent—A value of type Agent represents an agent defined on the WebACD. This type is basically used to enqueue and dequeue tasks from individual agents.
These types form the foundation for Plaid. Based on values of these types, expressions can be built in Plaid.
Plaid supports the following operators:
NOT value—Boolean NOT. If the value is true, the value of the expression is false. If the value is false, the value of the expression is true.
value AND value—Boolean AND of the two values.
value OR value—Boolean OR of the two values.
−value−Unary minus.
value< >value—Not equal
value & value—String concatenation.
In addition, Plaid supports parentheses, so expressions can be combined to form expressions such as (1+3)/2>5.
Plaid supports the following global finctions.
Syntax: Now( )
Arguments: none
Return Value: A DateTime value representing the current local date and time.
Purpose: This function returns the current date and time of the server running the WebACD. The value returned is local time, so the time zone of the server determines the value returned.
Syntax: UTC( )
Arguments: none
Return Value: A DateTime value representing the current Coordinated Universal Time.
Purpose: This finction returns the current date and time of the server running the WebACD. Since it returns Coordinated Universal Time, the time zone setting on the server does not impact the value returned.
Syntax: DateValue(srcDateTime)
Arguments: srcDateTime—A value of type DateTime that you would like converted into a date.
Return Value: A DateTime value representing just the date portion of srcDateTime.
Purpose: In a Plaid script, it is sometimes useful to compare two dates, without respect to time. For example, one might want to test "DateValue(Now( ))=#12/25/98#" and perform different actions if it is Christmas day. To facilitate this comparison, DateValue( ) converts the time portion to midnight so if you compare two dates, then they should both have times of midnight.
Syntax: TimeValue(srcDateTime)
Arguments: srcDateTime—A value of type DateTime that you would like converted into a time.
Return Value: A DateTime value representing just the time portion of srcDateTime.
Purpose: In a Plaid script, it is sometimes useful to compare two times, without respect to date. For example, one might want to test "TimeValue(Now( ))>#17:00#" and perform different actions if it is after 5 pm. To facilitate this comparison, TimeValueO converts the date portion to an invalid date if you compare two times, their dates will be equal and just times will be compared.
Syntax: Day(srcDateTime)
Arguments: srcDateTime—A value of type DateTime from which you would like to extract the day in the month.
Return Value: A value of type Long representing the day in the month of srcDateTime. This value is in the range 1-31.
Purpose: This finction is used to just retrieve the day in the month from a given DateTime, which can be useful in producing custom formatted dates or comparisons.
Syntax: Month(srcDateTime)
Arguments: srcDateTime—A value of type DateTime from which you would like to extract just the month.
Return Value: A value of type Long representing the month of srcDateTime. This value is in the range 1-12.
Purpose: This function is used to just retrieve the month from a given DateTime, which can be useful in producing custom formatted dates or comparisons.
Syntax: Year(srcDateTime)
Arguments: srcDateTime—A value of type DateTime from which you would like to extract the year.
Return Value: A value of type Long representing the year of srcDateTime. This value is a four digit year.
Purpose: This function is used to just retrieve the year from a given DateTime, which can be useful in producing custom formatted dates or comparisons.
Syntax: Hour(srcDateTime)
Arguments: srcDateTime—A value of type DateTime from which you would like to extract just the hour.
Return Value: A value of type Long representing the hour of srcDateTime. Since Plaid represents times using the 24 hour clock, this value is in the range 0-23.
Purpose: This function is used to just retrieve the hour from a given DateTime, which can be useful in producing custom formatted dates or comparisons.
Syntax: Minute(srcDateTime)
Arguments: srcDateTime—A value of type DateTime from which you would like to extract just the minute.
Return Value: A value of type Long representing the minute of srcDateTime. This value is in the range 0-59.
Purpose: This function is used to just retrieve the minute from a given DateTime, which can be useful in producing custom formatted dates or comparisons.
Syntax: Second(srcDateTime)
Arguments: srcDateTime—A value of type DateTime from which you would like to extract the second.
Return Value: A value of type Long representing the second of srcDateTime. This value is in the range 0-59.
Purpose: This ftnction is used to just retrieve the second from a given DateTime, which can be useful in producing custom formatted dates or comparisons.
Syntax: Weekday(srcDateTime)
Arguments: srcDateTime—A value of type DateTime from which you would like to extract the day of the week.
Return Value: A value of type Long representing the day of the week of srcDateTime. This value is in the range 0-6 where 0 represents Sunday and 6 represents Saturday. Purpose: This function is used to just retrieve the day of the week from a given DateTime, which can be useful in comparisons.
Syntax: WeekdayName(srcDateTime)
Arguments: srcDateTime—A value of type DateTime from which you would like to extract the day of the week.
Return Value: A value of type String representing the day of the week of srcDateTime. This value is one of the values "Sunday," "Monday," "Tuesday," "Wednesday," "Thursday," "Friday," or "Saturday."
Purpose: This function is used to just retrieve the day of the week from a given DateTime, which can be useful in custom date formatting.
Syntax: Fix(srcDouble)
Arguments: srcDouble—A value of type Double that you would like to truncate.
Return Value: A value of type Long, which is the value of srcDouble without fraction.
Purpose: This function is used to truncate doubles into longs, which just removes the portion of the double after the decimal. Fix and Int are similar, but differ in the way they treat negative numbers. Fix truncates toward zero, so Fix(−8.4)=−8. Likewise, Int truncates away from zero, so Int(−8.4)=−9. Int
Syntax: Int(srcDouble)
Arguments: srcDouble—A value of type Double that you would like to truncate.
Return Value: A value of type Long, which is the value of srcDouble without fraction.
Purpose: This function is used to truncate doubles into longs, which just removes the portion of the double after the decimal. Fix and Int are similar, but differ in the way they treat negative numbers. Fix truncates toward zero, so Fix(−8.4)=−8. Likewise, Int truncates away from zero, so Int(−8.4)=−9.
This finction is broken. It finctions exactly like Fix.
Syntax: Sleep(seconds)
Arguments: seconds—A value of type Long representing the number of seconds you would like the script to wait for an agent to be assigned.
Return Value: none (Void)
Purpose: This function is used to put pauses in a script. Typically a Sleep is placed after one or more enqueue statements, waiting for an agent to be assigned to the task. If a value of −1 is sent to Sleep, then it will sleep indefinitely. However, a script should never end with just Sleep(−1).
Instead it should have the lines
While true
Those lines will ensure the script is not terminated prematurely in certain cases.
Syntax: Trace(message)
Arguments: message—A String value representing a message to be written to the log file.
Return Value: none (void)
Purpose: This function is used write messages to the WebACD log file from within Plaid. For example, you may want to log when certain customers log in or when certain customers wait more the a particular amount of time. In order for this feature to work, the trace level on the WebACD must be at 1000 or above.
Syntax: CDbl(srcInt)
Arguments: srclnt—A Long value representing an integer you would like to convert to Double.
Return Value: A Double value representing srcInt as a Double.
Purpose: This finction is used to convert an integer into a floating point number, which can be important in maintaining accuracy in division and other arithmetic operations. Note that this function is often called implicitly. Any time a value of type Long is used when a value of type Double is expected, this function is called. This also applies to binary operators where one operand is of type Long and the other of type Double. This function should probably take a string, also.
Syntax: CStr(srcLong), CStr(srcDouble), CStr(srcString), CStr(srcDateTime), CStr(srcBoolean) Right now customer and team are also supported, but they don't do anything useful. If you pass an agent, the server crashes. (Will be fixed soon.)
Arguments: A value you would like converted to a string.
Return Value: A String value with the string representation of the specified value.
Purpose: To produce a string representation that can be displayed to the user or placed in a trace. Note that this function is called implicitly any time the concatenation operator (&) is used on non-string types.
Syntax: Say(htmlString)
Arguments: htmlString—A String value representing text that will be displayed in the customer client. This string can be HTML, which allows you to put graphics and formatting in your message.
Return Value: none (void)
Purpose: This function is used to push text to the customer client. Since the text can be HTML, it is also used to liven up the customer interface.
Syntax: PushURL(urlString)
Arguments: urlString—A String value representing a URL that will be pushed to the customer.
Return Value: none (void)
Purpose: This function is used to push URLs to the customer via the Plaid script. The URLs will appear in the transcript just like URLs pushed by the agent. You can use this to push the customer advertisements or forms they should fill out while waiting for an agent.
The following objects in Plaid are defined to access and control various parts of the system. ACD
The object ACD is a global object of type ACD that is the used to retrieve most of the objects in Plaid. It supports the following methods.
Syntax: ACD.GetTeam(teamName)
Arguments: teamName—A String value representing the name of the team to retrieve.
Return Value: A value of type team with the specified name or a value of type team of the default team if there is no team by teamName.
Purpose: This function is used to retrieve teams from the WebACD so tasks can be placed in a queue for the team (see type Team below). If the specified team name does not exist, then a message will be written to the customer client saying the team was not found and which script and version is running. This is so the administrator can run the script and immediately identify incorrect team names. If the team is not found, the default team will be used and processing will continue.
Syntax: ACD.GetCustomer( )
Arguments: none
Return Value: A value of type Customer representing the customer who is running the current task.
Purpose: This function is used to retrieve the customer who escalated so you can get attribute values off of that customer record.
Syntax: ACD.GetAgent(agentName)
Arguments: agentName—A value of type string representing the name of the agent you would like to retrieve.
Return Value: A value of type Agent representing the agent with the specified name.
Purpose: This function is used to retrieve an agent so the task can be placed in a queue for that agent.
A team object is retrieved using ACD.GetTeam( ). Once you have that object, you can execute the following commands on the team.
Syntax: team.Enqueue( )
Arguments: team—A value of type Team.
Return Value: none (void)
Purpose: This function is used to place a customer in queue for a team. Using this function, the customer will be placed in the queue using normal priority, at the tail end of the queue.
Syntax: team.Enqueue(priority)
Arguments: team—A value of type Team.
priority—One of the strings low, normal, high, or urgent.
Return Value: none (void)
Purpose: This function is used to place a customer in queue for a team. Using this function, the customer will be placed in the queue using the specified priority. Priority low is the lowest priority and priority urgent is the highest priority. In addition there is one higher priority called "system" that is not available through Plaid. That priority is used in transfer. All tasks with higher priority will be serviced before tasks with lower priority. For this reason, priority must be used very carefully. If a very large number of urgent priority tasks are assigned to the queue, then low, normal, and high priority tasks may never get answered. A task may be enqueued for different teams, each with a different priority.
Syntax: team.Dequeue( )
Arguments: team—A value of type Team.
Return Value: none (void)
Purpose: This finction removes the task from the queue of the specified team. If a customer waits too long, then you may want to remove that customer from the queue and assign the customer to a different queue.
The Agent object is used to place customers in queue for one particular agent. The methods on this object are much like the methods on the object Team.
Syntax: agent.Enqueue( )
Arguments: agent—A value of type Agent.
Return Value: A value of type Long that represents whether or not the enqueue was successful. If the agent is not signed on, then Enqueue will return
Purpose: This finction is used to place a customer in queue for the specified agent. Using this function, the customer will be placed in the queue using normal priority, at the tail end of the queue. Queuing for agents is done using a barbershop model. As in an old style barbershop, if customer Pat wants to wait for one particular barber, then all customers that arrive before Pat must be serviced before Pat can be considered. Once Pat can be considered, Pat will be serviced as soon as the barber is ready. Note that this implies that a customer who arrived after Pat could be serviced before Pat is. If this behavior is undesirable and you would rather have Pat serviced right away, then Pat can be queued at a higher priority.
Syntax: agent.Enqueue(priority)
Arguments: agent—A value of type Agent.
priority—One of the strings low, normal, high, or urgent.
Return Value: A value of type Long that represents whether or not the enqueue was successful. If the agent is not signed on, then Enqueue will return
Purpose: This function is used to place a customer in queue for an agent. Priority in this function works just like priority when queuing for the team.
Syntax: agent.Dequeue( )
Arguments: agent—A value of type Agent.
Return Value: none (void)
Purpose: This function removes the task from the queue of the specified agent. If a customer waits too long, then you may want to remove that customer from the queue and assign the customer to a different queue.
The type Customer is used to represent information about the customer who has escalated.
Syntax: customer.GetValue(key)
Arguments: customer—A value of type Customer.
key—A value of type String that represents the key of the value that needs to be retrieved.
Return Value: A value of type String that goes with the key specified. If the key was not found, then the empty string is returned.
Purpose: This function is used to retrieve information about the customer. A customer record is a collection if key-value pairs that can be extended by writing a ComHub or CIS servlet. This function allows you to retrieve those values so different routing can be done based on the customer information.
A Plaid script is a collection of statements. A statement can simply be an expression as defined above or one of the control flow statements in the following sections. While
The while statement is used to execute a certain piece of code until a condition is true. The syntax is
While expr
The code represented by body will be executed as long as expr is true. Note that expr must evaluate to a value of type Boolean. This statements is particularly useful for making customers wait indefinitely by using "While true . . ."
An If statement is used to test a condition and then chose a section of code to execute. The syntax is
If expr then
If expr then
The code represented by then-block will be executed if expr is true. If expr is false and there is an Else, the else-block will be executed. Otherwise, processing the script will continue after the Endif. Note that expr must be a value of type Boolean.
Although the invention has been described with reference to particular embodiments thereof, these embodiments are merely illustrative of preferred embodiments of the invention. The scope of the invention is to be determined solely by the appended claims.


text:
Compass Group have exciting opportunities for an experienced kitchen porter on a casual basis. We are looking for experts in back of house service who want to grow their kitchen porter experience. As a kitchen porter you will be working on a relief basis for Compass Group who have over 8000 sites across the UK. We are looking for a kitchen porter who strives for perfection and is ambitious for delivering world class service to our customers.
Kitchen porter shifts may vary, you can work as much, or as little as you wish. Working through Compass Group comes with a range of benefits including;
Flexible Working Hours Supportive Team Perks at Work (Retail discounts, money off cinema tickets, family days out) Holiday Accruement Weekly Payment
The Ideal CandidateWe are looking for a team of passionate and enthusiastic individuals. Experience is not essential but would be beneficial. A candidate who is flexible and adaptable would have the correct mind set to work with Compass Group. The successful Team Member should meet the following criteria:
Have a friendly & approachable character Love providing fantastic customer service Enjoy working as a part of a large staff team Driven to help the team achieve their targets Flexibility to excel in different roles across a diverse business
About The CompanyCompass Group UK and Ireland is part of Compass Group Plc, the world's leading foodservice company. We specialise in providing food, vending and related services on our clients' premises. The company operates across the core sectors of Business & Industry, Defence, Offshore & Remote Site, Healthcare, Education, Sports & Leisure and Vending with an established brand portfolio.
You may return to your current search results by clicking here.
A-Z of our Recruiters
© 2010 - 2019 -
Professional Passport Jobs
- Powered by Professional Passport Jobs
Follow @Jobs_pro
Job Board website by Strategies
This website uses cookies. Read our cookie policy for more information. By continuing to browse this site you are agreeing to our use of cookies.
This website uses cookies. Read our cookie policy for more information. By continuing to browse this site you are agreeing to our use of cookies.
Home > Kitchen Porter Casual

subset: commoncrawl


text:
BIRMINGHAM, Ala.—Led by sophomore Ashley Curry with 26 points, the Birmingham-Southern women's basketball team snapped a four-game losing streak with a 97-66 home victory against Rust College, Sunday afternoon in Bill Battle Coliseum.
The Panthers move to 5-6, while the Lady Bearcats fall to 3-11.
BSC shot a season-high 48.4 percent (31-64) from the field while also committing a season-low eight turnovers.
Curry wasn't the only BSC player with 20+ points, as sophomore Kelsey Brown recorded 22 as well as a game-high five assists. Freshman Jasmynn Batts also had 16 points on 6-9 shooting, and senior Elizabeth Bromirski recorded 12 points.
The Panthers opened the game by quickly going up 5-0 and held a double digit lead by the 17:46 mark. The Lady Bearcats cut it back to five, 15-10, at the 15-minute mark, but BSC used a 16-6 run to go up 31-16 by the 10:10 mark, and led by 18, 48-30, at halftime. The Panthers kept a comfortable lead for the remainder of the game, going up by as much as 36, three times, before coming away with the 97-66 win.
Jessica Brown led Rust with 15 points, followed by Tiesha Tunstall with 13. Four different Lady Bearcats led the team with six rebounds apiece, and Whitney McNeal led with four assists and two steals.
BSC shot 48.4 percent (31-64), a season-high, from the field and 53.3 percent (8-15), also a season-high, from three-point range, and was 73 percent (27-37) at the free throw line. Rust shot 43.8 percent (28-64) overall, 20 percent (2-10) from beyond the arc, and 57.1 percent (8-14) from the line.
BSC also committed a season-low eight turnovers while the Lady Bearcats turned it over 17 times, but Rust out-rebounded the Panthers 41-36.
The Panthers resume Southern Athletic Association play next week, going on the road for the next four games beginning with a match-up against Sewanee this Friday, Jan. 10, at 6 p.m. BSC returns home Friday, Jan. 24, against Hendrix at 6 p.m.