[SalesForce] How to deal with Activities in a Case Hierarchy

Let's consider a Case in the service sense of the word – a caller calls up with a situation ("My printer's broken."). Now, maybe the caller calls up about more than one situation ("My printer's broken and I need a new monitor").

For statistical purposes, and as far as the caller is concerned, I'd like to treat this as one call. However, it's clearly two separate cases (in our example, one case goes to Service and the other to Fulfillment or Sales, and they clearly have different timelines).

Some use cases

As a call center manager, in order to understand how quickly my agents deal with a particular type of issue, I would like to report on, e.g., "Average Number of Calls per case for Printer Service issues".
As a person in Fulfillment assigned to a Case, in order to better and more-quickly resolve the Case, and in order to maintain customer satisfaction by not asking the customer for the same information twice, I'd like to have access to the content of all phone calls about that Case.
As a department manager, I'd like to know the status of each part of the Case, and to be able to report on how quickly that part was closed.
As a call center agent, I'd like to have an easy interface for entering in data.

One solution

My guess is that Case hierarchy is a good way forward on this, but I'm at a loss regarding exactly how to model the Case tree and the activities.

Do I duplicate the Activity, marking one as "real" for statistical purposes?
Do I make a shell parent Case, two child Cases, and keep the initial call on the parent (and then provide a UI on the child cases to see the activities on the parent)?
Do I do something else entirely?

References:

Official admin documentation

How to set up a Case Hierarchy

Developing with the Service Cloud

Best Answer

To borrow a consulting cop-out, I think the answer depends on your business processes and objectives. Girbot made a great recommendation to engage the business in conversation on this topic. Or, put in other words, please consider your organization's unique context.

With that said, let's explore (thinking out loud) a few business considerations, and then examine some options. Hopefully we'll arrive at some guidelines for using the Parent Case field, that you can apply to your unique organization.

Why do front-line staff care?

Typically front-line staff care about two things:

Avoid the stick. This means completing the work, so that they don't get disciplined or terminated for dropping the ball with a customer.
Get the carrot. This means getting credit for the work they did, in a way that maximizes the impact (read, calculated result) of the work on any incentive payouts for which they are eligible.

Both of the above concerns usually drive a need to have a system that allows for efficient routing and handling of cases, so we assume that users want to close cases as quickly as reasonable.

Why do managers care?

Support managers usually care about a couple of things:

Volume and quality. How many cases are coming in? And is every case is closed in a timely manner, to the customer's full satisfaction?
Address strong and weak team members. Since staff live in the world of customer service via cases, the data captured in cases should help identify or provide evidence to support strong and weak team members.

Managers usually look at data in aggregate, which in Salesforce means using Salesforce1 Reporting (formerly known as Salesforce Analytics).

Four technical options

The hypothetical call about a broken printer and a new monitor you described can be logged in one of the following ways:

1 case for both issues (broken printer + new monitor)
2 cases, unrelated, one for each issue (broken printer, new monitor)
2 cases, one parent and one child (user's choice for which gets created as the child case). This assumes that your Fulfillment department uses the Case object to manage new monitor requests and not something else, like the Order object.
3 cases, one parent case for the call (broken printer + new monitor), and two child cases (broken printer, new monitor). This is similar to what Girbot explained in his comment, using the case hierarchy to split a large problem (the parent case) into smaller problems (child cases).

Option 1: Probably not what you need

You've already noted that two departments are involved, one for the broken printer and one for the new monitor. If you're not using Case Teams, you probably will need or want to create a separate case and assign that to the other department.

Plus, if your organization reports on the number of cases handled by reps, chances are those reports are based on Case Owner, in which case the rep in the supporting department won't get credit for working on the case.

Option 2: Acceptable, not great

Having two cases solves the work routing and crediting problem, to distribute work to two departments. However, at a glance you won't be able to tell that a related case was created. Furthermore, you're building a habit that is not conducive to introduce any kind of automation for related cases (e.g., time tracker roll-ups).

Option 3: Acceptable, better than the previous option

Basically this is the previous option but with a link between the cases. The relationship allows for quick visibility to see that a related case exists, and the relationship would facilitate any kind of "related case" automation you may want to add.

To keep things clean, and to simplify life for the customer by just providing the customer one reference number (i.e., Case Number), I suggest:

The person who handled the inbound call owns the parent case.
The parent case number is given to the caller.
Since caller only has one case number, all activities are logged on the parent case.
The parent case owner creates the child case, and assigns it to an appropriate user or queue
Internal collaboration on the child case happens via Chatter or Case Comments
The parent case remains open until the child case is closed

Option 4: Probably overkill

If only two people are involved, this would really seem like overkill. However, for more complicated problems or situations where the primary support rep is not the one working to solve the problem, you may want to go this route.

One example that comes to mind is a technical support call that reveals two deeper, distinct problems, requiring involvement from separate R&D departments. I may call Premier Support about a Visualforce page, and that ends up being escalated separately to the Visualforce team and the Apex team.

Direct answers and closing thoughts

Sorry for the long-winded response, but here are my direct answers to your questions. It bears noting that in the scenario you described, I think the third option (2 cases in parent-child relationship) is probably optimal.

Do I duplicate the Activity, marking one as "real" for statistical purposes?

No. I don't recommend duplicating activities (i.e., Task records). Log customer interactions only on the parent case.

Do I make a shell parent Case, two child Cases, and keep the initial call on the parent (and then provide a UI on the child cases to see the activities on the parent)?

No. This is the fourth option I described, and I do think it's overkill for the scenario you described. Using two cases will probably meet your business requirements.

Do I do something else entirely?

Yes. Create two cases in parent-child relationship. This makes it respect the reality that you described, "as far as the caller is concerned, [we'd] like to treat this as one call." One case number given to the customer, two case numbers known to the organization.

Related Solutions

[SalesForce] Can someone explain how Salesforce works with CTI? (Avaya)

Salesforce doesn't provide any way to track these things. As a developer you have to do this. We have setup for Genesys and Avaya in our organization and we have built CTI adapter for salesforce with genesys.

Let me tell you few things, SF doesn't know your dialer. Its your responsibility how you implement it with Open CTI API. Sf will just pop up records which you invoke through Open CTI API. rest you have to decide how you want to handle call flow.

In our Genesys CTI Adapter we track talk, ring, warp, etc in out adapter and later we update same in sfdc via API.

Sfdc API will help you to search, load customer record based on phone number or other parameters. But its your responsibility how you are going to track it.

[SalesForce] Need help on SOQL to query all related child case records

The basic idea is to create a formula for Ultimate Parent

BLANKVALUE(Parent.Parent.Parent.Parent.ParentId,
    BLANKVALUE(Parent.Parent.Parent.ParentId,
        BLANKVALUE(Parent.Parent.ParentId,
            BLANKVALUE(Parent.ParentId,
                BLANKVALUE(ParentId, Id)
))))

Then, you can get your relevant cases as follows:

Set<Id> parentids = new Set<Id>();
for (Case newCase : trigger.new) parentIds.add(newCase.parentId);
List<Case> relevantCases = [
    SELECT Id FROM Case
    WHERE Ultimate_Parent__c
    IN (SELECT Ultimate_Parent__c FROM Case WHERE Id IN :parentids)
];

You might be able to use recalculateFormulas() to get the values without doing an inner-join-sub-select, but there is a known issue dealing with cross-object logic, so I have my doubts it would work.

Update

The recalculateFormulas method does give you the correct value, but also causes an exception if you execute it on the trigger records:

System.UnexpectedException: Unable to create/update fields: LastModifiedDate, IsDeleted, SystemModstamp, CreatedById, CreatedDate, LastModifiedById.