In this episode we look at Cases – the core object of the Salesforce Service Cloud. We start by covering how you can use Cases to track issues, questions or requests to resolution. We discuss some of the special features that are only available in Cases as well as the different methods you can use to create a Case. Lastly we wrap up with a review of the key standard fields you need to know.
View this video on YouTube https://youtu.be/_dfPGaIr5gM
Transcription of video:
Hello everyone, welcome to ShellBlack Whiteboard, where we help you get the most outta the Salesforce platform. I’m Shell Black, president of ShellBlack.com, and Salesforce MVP. The topic today is Cases. So let’s jump in.
So let’s first start with a definition of a Case. And I am going to keep this a little broad, because over my experience working with my clients, Cases are pretty flexible, and can be applied in a lot of different ways. So I’m going to define Cases as a method for handling, or tracking a problem, issue, request, or question to resolution.
A little broad, Cases are a standard object, and if you’ve heard me before, standard object gets standard fields that come out of the box, you can add custom fields, you can have multiple page layouts, record types, validation rules, etc. Cases are the core of the Service Cloud, which is a big offering. So if you think of Opportunities as the core module inside the Sales Cloud, Cases for customer service is the core object inside the Service Cloud.
So to help you understand the different ways, and the flexibility in which you can use Cases, let’s walk through some scenarios. So the one that I think most people think about is I’m supporting my customers, and they’re calling with questions about products, maybe billing, or how do I do a return. So really you’ve got a group of people fielding Cases and creating Cases that are issues coming from your customers. You can also use this as an internal help desk, or an internal way to handle requests coming from your internal users, or employees. Maybe I’ve got to provision a login, or reset a password, or maybe you want track the process of on-boarding an employee through Cases. Also they can be used to track back office requests.
So let’s say that we’re a financial institution, maybe a bank, wealth management shop, we do stock trades, or maybe we’re an insurance company, and so maybe you want to have a more formal way to track these requests other than a Task, because a Task isn’t quite sufficient enough. Some examples of a back office request that can be handled, maybe I need to perform a trade, I need to open a financial account, maybe I need to do a change of address on one of my accounts, maybe I need to do a change of beneficiary on an insurance policy, and you want to have a little bit more information that’s a little bit more special than just a Task. And you want to make sure that that request gets tracked to resolution, so Cases could be a good way to handle that.
Let’s also talk about some special features that are available with Cases. So for example, Assignment Rules. So what an Assignment Rule is, is when a Case gets created you can have an Assignment Rule evaluate the information on that Case and decide who should work it, either a specific user, maybe tier one, tier two, or assign that to a queue, which is really an unassigned bucket, so you could have a new Case queue, a tier one queue, a tier two queue. So maybe you’re a tier one support agent, but the question is too complex for you, you don’t know who in tier two should get the Case, you just assign it to a queue, and then someone who works that queue can grab that Case and start working it. It’s really the ownership of the record.
Escalation Rules. So Escalation Rules are really helpful to make sure that something doesn’t fall through the cracks. So maybe if a Case has been opened and a “New” status for three days, that’s too long, and you want that Case escalated to a team lead, or maybe you want that Case escalated and reassigned to a manager. Again, something sitting out there too long, you want to make sure a Case doesn’t fall through the cracks, Escalation Rules are a great way to dynamically and proactively reassign and escalate those Cases.
Entitlements. So what Entitlements are is say contractually when working with a client that you’ve come up with an SLA, or a Service Level Agreement that says, When you open up a ticket with us we’re going to give you some type of initial response, or initial acknowledgement of that Case within four business hours, and maybe contractually you’re obligated to have that Case resolved within, say, five business days. So those types of timing milestones are handled with Entitlements inside Salesforce.
Another feature that you can use is a Knowledge Base. Very cool feature. A Knowledge Base is really a library of Articles, Knowledge Articles that you write, some people call them FAQs, and they’re used to help speed Cases to resolution. So maybe you have a new agent that doesn’t know how to handle a certain problem, they can search the Knowledge Base, or as you’re filling our the details of the Case, a Knowledge Base can be recommending Articles it thinks are a good match based on the information you’re capturing on the Case. So Knowledge Bases can be used internally, you can put them on a Community. But really the whole idea of a Knowledge Base is to help speed to resolution, and maybe even deflect Cases from even getting opened if you had them on a Community. So, a pretty cool feature. So let’s flip to the other side of the board, and hit some other topics.
Let’s talk about the channels of how Cases come in and how they are created. Very commonly they are created manually. So maybe you’re on a call center, and you’re taking a request, or a question, or a problem from a customer and being on the phone, you’re just going to manually type in that Case, and open that Case. There’s some automated methods on how Cases get created. You can have an email address on your domain, maybe “support@yourcompany.com,” and sending an email to that email address, Salesforce can automatically create a Case. It can look at the sender, of who sent that email, and try to match it up against a Contact in the database inside Salesforce to automatically open that Case against that Contact. Let’s say that they sent an email from an email address you’re not aware of, your Yahoo, or Gmail, or a personal email address, the Case still gets created, but it’s not related to a Contact. Kind of a neat feature of Email-to-Case is that you can send attachments through emails, and those attachments will come in and get associated to that Case automatically.
Another vehicle to automatically create a Case is through your website, so a quick HTML form, very similar to a Web-to-Lead form, is a Web-to-Case form where they can put in their name, email address, company, short description of the problem that they’re having, hit “Submit.” That will come in and automatically get created as a Case. You can have Cases created on a Community. So a Community is a special license from Salesforce, but you can have a portal or a Community where your end customers can come in, browse a Knowledge Base, look at old Cases, and open a Case and self-help. And so instead of having an agent involved in creating that Case, the end user client can create their own Case on a Community.
Another method is Live Agent. Live Agent is a special license from Salesforce, but it basically is live chat on your website. And through a chat conversation an agent can go ahead and kick off a Case and maybe that they can’t answer the question right there on the live chat, or maybe they want to log that as an issue and create a Case from that chat dialogue.
Okay, standard fields, there are over 40 standard fields on Cases. I don’t have time to go through them all. So I’m going to hit the big ones that you’re going to come across most likely. Two lookup fields that are very key, one to the Account, the company, one to the Contact, so really you want to open Cases against a Contact who made that service request. And by default, that contact typically works for an Account. There’s an auto number field called “Case Number,” so every time you click the new button and create a Case, Salesforce is going to assign it automatically a number and increment it by one every time you create a new Case, very similar to Quotes that have a unique number, Orders have unique numbers, Cases also have unique numbers.
A Case Owner, it’s the record owner, can be a user, or as we’ve alluded to previously, a queue. Subject line and Description I want to talk about together, so think of this in the analogy of an email, an email has a subject line, which is a short snippet about what the email is about, and then the body of the email has more narrative. So same thing, the Subject line of a Case is a short narrative of what the issue is, and the Description field has a more comprehensive narrative of the details about that Case.
Let’s roll into a handful of picklist fields that I think are pretty important. So Origin is really the channel that the Case was created from, so it could be the web, email, phone, really good for reporting. Type is a picklist field that you can use to help segment or categorize your Cases. So was this a Case about a problem, was it a feature request, was it about training, was it about documentation, was it about billing? It’s just a way for you to categorize your Cases. Status, key field, this is the lifecycle or business process field. So we’ve talked about lifecycle fields before, the Lead Status field on Leads, Opportunity Stage is another example of a lifecycle. So it’s where is this Case in its lifecycle or business process? Is it that we just opened it, it’s a “New” Case, or is it “On Hold,” we’re “Waiting on the Customer” for more information, how we escalate it to another group, has it been resolved or is it just been “Closed” out? Again, your lifecycle business process field. And lastly the Case Reason. So when you close out a Case, typically you will give it a disposition and close it out with a reason of why that Case came to be. Was it because there was inadequate information on our website, maybe the documentation on the product that we shipped was inaccurate, needs to be updated, was it a problem, feature request, existing problem, new problem, however you want to do a disposition on that Case is typically through this picklist field called Case Reason.
All right, Case is a huge topic. There’s a lot of associated products, there’s a lot of functionality. Again, Cases are the core of the Service Cloud, so this is really more of an introduction to Cases, but I hope you enjoyed that. If you have any feedback on how we’re doing, or want to reach out, you can hit me on Twitter, @Shell_Black, or you can send me an email at whiteboard@shellblack.com. Thanks so much for tuning in, we hope to see you soon.