Case lifecycle model (Salesforce Service Cloud)

In this article:

• Lifecycle model overview
• Units of work for omni vs. non-omni cases
• Queues and exclusions in Assembled
• Channels in Assembled
• Appendix

Lifecycle model overview

Our new case lifecycle model enables teams to forecast, staff, and report on the units of work that comprise a support case. Key benefits include:

• Forecasts that account for all “touches” / units of work done by your agents
• More accurate staffing for cases that transfer or escalate
• Visibility into case breakdown (reopens, transfers, etc)
• Optimize staffing to meet SLA requirements for each touch

Units of work for omni vs. non-omni cases

In Salesforce, cases can be routed in two ways: Omni-channel routing and manually. It’s common for customers to use both types of routing methods. In this section, we’ll walk through how units of work are defined for both types of cases.

Note that in the instance that a unit of work is not created in Salesforce, we consider that excluded and it will not be added to the ticket volume in Assembled.

Omni cases and units of work

Definition:

• Cases routed automatically via omni-channel routing. When routed through Omni-Channel, an AgentWork object is created.

Omni units of work:

• Begin when an AgentWork object is created.

• AgentWorks are mapped one-to-one to units of work in Assembled.

AgentWork basics:

An AgentWork object is created when a case, live chat transcript, or other work item is routed to an agent via Omni-Channel. This can happen under several circumstances:

• The work item enters a queue with Omni-Channel routing enabled and is directly assigned to an agent.
• The work item is transferred or reassigned to another agent.
• The work item status changes from a completed to a non-completed state (e.g., a case is reopened or re-engaged).
•  

Non-omni cases and units of work

Definition:

• Cases routed manually without Omni-Channel.

Non-Omni units of work:

• Created using an inference model since no AgentWork objects are created.
• Begin when the case history shows:
  • Transfer: Case is transferred to a new Assembled mapped queue AND the Owner or Status of a case changes
  • Reassign: Case is reassigned to a new agent. (i.e the case’s Owner changes)
  • Reopen: Case is reopened (ie. Status goes from solved or closed to open)
  • Re-engage: Case is re-engaged (ie. Statusgoes from paused to open)

Example of how omni & non-omni periods combine to create units of work in Assembled

Queues and exclusions in Assembled

For both omni and non-omni cases, the queue, channel, and status of a case are determined by its final unit of work.

Omni configuration

Out of the box, for omni-channel routing cases, we support skill-based or queue-based queue & exclusion configurations.

Queue-based omni-channel routing

• Create queues in Assembled based on the Queue ID field, matching the OriginalQueueID on AgentWork.

Skill-based omni-channel routing

• Create queues in Assembled based on the Skill ID field, matching any skills tagged on AgentWork.

Note: We have the option to use custom non-omni fields as well for queue configurations. This requires backend configuration, so please contact us for help.

Non-omni configuration

Several options exist for defining queue and exclusion rules for non-omni cases:

Owner ID (inferred)

• Use the Owner ID field on the case object.
• Use the case history to infer the owner at any given time, determining the queue for each unit of work.

Skill ID (inferred)

• Use Skill IDs from previous omni-routing segments to determine skills on manually routed units of work.

Custom non-omni field (inferred)

• Use a custom field on the case object.
• Use the case history to infer the custom field at any given time, determining the queue for each unit of work.

Channels in Assembled

Several options are available for defining unit of work channels, independent of routing type:

Custom non-omni fields (default)

• Use the history of a custom field on the case object to infer the channel.
  • i.e. there’s a channel field that tracks changes to the channel

Queue-channel mappings

• For queues with specific channels, determine the channel of a unit of work based on its queue.
  • i.e. units of work in queue A = chat channel, queue B = email channel

Default channel

The simplest channel mapping strategy.

• Map all units of work to a single channel per object type
  • i.e. Case = email channel, LiveChatTranscript = chat channel

Case Origin mapping

Recommended for cases that don’t generally switch from asynchronous to synchronous interactions (or vice versa) during their lifecycle.

• Map Origin values on the case object to a channel, ensuring consistency across all units of work for a given case.
  • i.e. Units of work from a case with Web origin = email channel. Units of work from a case with API origin = chat channel.

Appendix

Related Case Lifecycle articles: 

• Case Lifecycle Staffing Timeline
• Case Lifecycle Real-Time Dashboard 
• Case Lifecycle Metrics