2

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

  1. 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".

  2. 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.

  3. 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.

  4. 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

1
  • I've not used Case hierarchy quite like that, my use case/s were that it was one issue that affected multiple customers. So one parent Case with THE issue in and one child Case for each affected customer. I'd ask on how the business would like to report on it, do they see it as 2 distinct work items/action points (i.e twice the work) or just want the ease of recording something happened and that something was done about it.
    – Girbot
    Jun 9 '15 at 22:17
4

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. 1 case for both issues (broken printer + new monitor)
  2. 2 cases, unrelated, one for each issue (broken printer, new monitor)
  3. 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.
  4. 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.

3
  • Thank you for the thorough answer. My concern here, then, is twofold: 1) How do I report on, e.g., "Average Number of Calls per case for Printer Service issues"? 2) How do I expose the content of the phone calls on the parent case to people viewing the child case? Jun 10 '15 at 14:51
  • 1
    Great questions, Charles. Personally I think "average number of calls" is a bit of a misleading metric, as it doesn't account for the duration of each call. But if you need to, I think Option 4 would be the cleanest way to separate the concerns and report on each issue separately. But for your consideration, from the customer's perspective he only has one case number. So when the customer calls in, he will likely ask for status updates on both issues. In this case, not only will you have two child cases, but I imagine you would also log two activities for a single call.
    – Marty C.
    Jun 10 '15 at 18:23
  • Regarding your second question about exposing the activities on the parent case to people viewing the child case, in Summer '15 you would still need a custom Visualforce page embedded on your page layout to expose that information. In the future Lightning Components will probably be the preferred approach, but right now Visualforce is the go-to for custom UI components. I did consider simply using hover details, but for some reason in my test org the related lists are not appearing.
    – Marty C.
    Jun 10 '15 at 18:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.