Work Items

Work items are structured, inbound tasks that NiCE CXone treats like interactions so they can be queued, routed, tracked, and handled by agents using the same workflows and reporting as voice or chat interactions. Work items are not interactions, but instead are tasks for agents to complete, such as tickets or issues from Salesforce or another CRM application.

To use work items, you must set up a work items channel in NiCE CXone. Routing for work items is defined by ACD skills and Studio scripts. Agents process and disposition work items in their agent application, just as they would any other interaction.

Bonita Peep is a manager in the Operations department at Classics, Inc. Her team, the Shepherds, deals with lost demo book claims from field representatives. She wants claims submitted to her team either by a phone call or through a new app that the field reps use. When submitted by phone call, the answering agent will create the claim while on the call. But for claims submitted through the app, Bonita configures a work item point of contact in NiCE CXone to route the claims to her team members. Claims submitted by the app will be handled in the order received with the phone calls.

Bonita worked with one of the script developers at Classics, and with NiCE CXone Professional Services, to configure NiCE CXone and create Studio scripts to receive claims through the app. They worked in this order:

  1. Bonita created the skill for the work items.
  2. Bonita then had her Classics team create an empty Studio script called “Claim Work Items” as a placeholder for work to be done by NiCE CXone Professional Services to route work item claims to agents.
  3. Next, Bonita created a work item point of contact in NiCE CXone, and in it referenced the skill and the empty Studio script.
  4. Bonita had her Classics developer create the claim app to collect the needed claim information from the field reps. They used the NiCE CXone Work Item API call in the code of the app to submit the claim to NiCE CXone through the point of contact Bonita had created.

    The API call sends the following information to NiCE CXone from the app:

    • pointOfContact: Name of the point of contact that Bonita created.
    • workItemID: Any unique ID for this contact, which for Bonita’s system was an incrementing, unique number.
    • workItemPayload: The information agents will need to process a claim. It is a string, in a format similar to a JSON string with ordered pairs such as the following:

      {"RepID": 1234567,"RepFirstName": "Bonita","RepLastName": "Peep","ClaimInfo": "Book lost on Rocky Ridge","ClaimValue": "$127.36","FurtherInfo": "Call me at (123) 123-1234 if you have questions about this claim."}

    • workItemType: A preferred descriptive string to differentiate types of work items, such as “Lost Book Claim”.
    • from: A “from” string of choice, describing where the work item came from “Field Rep Claim API”. This is only for reporting, such as the Contact History report.
  5. Bonita worked with a NiCE CXone Professional Services programmer to have the script created, which replaces the empty script she created earlier. Each time the Classics API submits a claim to the point of contact, the script runs. It receives the information from the API call, requests an agent on the appropriate skill, and upon receiving the work item, presents it to the answering agent, through the RunApp action.

You can see Bonita's work in the task instructions and screenshots for setting up work items.

In the Bonita Peep example, the payload of the Work Item API call is fairly detailed. For payloads with less information, you could instead turn on screen pops in the skill, which automatically show the raw contents of the payload.

Work items can be used for inbound items only. They require initial configuration by Professional Services.

Persistent and Real-Time Work Items

When you set up an ACD skill for work items, you can choose which type of work item the skill works with: 

  • Persistent: An asynchronous queue, similar to a backlog. The system requests an agent, then waits until one is available.
    • The Studio script pauses after requesting an agent (when the Reqagent action fires). It remains paused until the work item is delivered to an agent.
    • The script cannot perform additional actions on the work item while it waits to be delivered. However, the PUT /persistent-contacts/{contactId}Icon of a square with an arrow point from the center through the top right corner. API allows you to modify persistent work items in the queue.
    • Work items are fully tracked, reported, and queued in the time between requesting and agent and delivery.
    • The persistent queue is ideal for large volumes of non-urgent work.
  • Real-time: The system delivers work items to agents as soon as an agent matching the required ACD skill becomes available. Real-time work items behave most like live interactions. Additionally: 
    • The Studio script continues to run until the work item is delivered.
    • The script can continue to perform actions on the work item while it waits to be delivered.
    • The real-time queue is best suited for time-sensitive work that should be handled as quickly as possible.

Work Item Queue Capacity Limits

Work items count toward the total number of interactions the system can handle at one time. The two types of work item queues have different capacity limits. The limits are governed by two related but distinct system limits: 

  • Queue-specific limits: The different types of queue, real-time and persistent, have different limits.
  • Total script count for the business unit: Each business unit has a limit of 15,000 concurrent Studio scripts that can run at the same time. A single interaction equals one script.

The way these limits work together results in different capacity limits for each queue type. Plan your queue configuration carefully to ensure that work item traffic does not impact your other channelsClosed Various voice and digital communication mediums that facilitate customer interactions in a contact center..

Persistent Queue Limits

A business unit can have up to 100,000 work items in the persistent queue. This is because persistent work items "sleep" while waiting for an agent, and so do not affect the total script count. However, when a persistent work item is delivered to an agent, its script wakes up and is included in the business unit's total script count.

You can safely accumulate a large backlog of work items, but you must ensure that you have script capacity available for the number of work items that may be routed at the same time.

Real-Time Queue Limits

Real-time queues can hold a maximum of 10,000 work items. However, because real-time work items do not sleep, they always count toward the total script count. This means they impact the capacity for handling other interaction types.

For example, if you have 15,000 work items in the queue, they consume the entire script count and the system cannot process other interactions until some of the work items are completed.

 

Transferred Work Items

When a work item is transferred, NiCE CXone maintains the relationship between the initial contact (Master Contact IdClosed The master or parent ID for one or more related contacts. A new master contact ID is assigned if a contact is transferred three or more times.) and the new contact (transfer). Following is an example from another department at Classics.

A work item enters the system and is assigned the same value as both master contact ID and contact ID: 234. Agent Dorothy Gale receives the work item.

Dorothy is unable to handle the item and transfers it to John Tinman. The master contact ID for the transferred item is 234 and the contact ID is 567. A relationship to the original item is preserved.

If John needed to transfer the work item again, the master contact ID for the newly transferred item would be 567 and the contact ID would be 891.