8 Essential Service Cloud Workflows

Share this article...







Salesforce Service Cloud comes standard with pretty limited automation out of the box, which for smaller, less experienced businesses doesn’t really pave the path for what can be achieved. Throughout my days as working as a Consultant I’ve come up with and seen quite a few easy to implement workflows that can really reduce the admin side of things, reduce human error and overall make for a smoother experience! So here’s my brief description of 8 Essential Service Cloud Workflows, I have included detailed implementation guides as well for those that are not to familiar with Workflow’s

1. Key Customer Case Notification

An easy and effective workflow that can really help you maintain your SLA’s and relationships with your key customers. This workflow requires you to create a field on the Account Object called “Key Account” or similar, Sales can then mark this as true for all accounts that you need to take particular care over. You can then base various workflows off of this to make sure the relevant people are being informed when something is happening. This can be done in two ways, task notification or email notification. I tend to use the latter in these types of workflows as I find emails are global and everyone knows how to use them, Salesforce tasks on the other hand are a bit hit and miss. In this example we will be notifying the relevant parties when a case is opened for a key account. Read More…

2. High Priority Case – Notify relevant people

Following on from notifying relevant parties if a key account case is opened, it is advisable to set up notifications when a high priority case is opened. Hoping that they are rare in your business, its of course of the up most importance to get these turned around and solved as quickly as possible. The worst scenario in this case is if it goes unnoticed, violated SLA’s and leaves you with a very unhappy customer. This of course can be taken a step further and merged with the Key account parameter to inform someone higher up the hierarchy if a high priority case from a key account is opened. As per my first example I tend to prefer using email notifications when the information is important and something needs to be done about it quickly. In this example we will be notifying relevant parties when the highest priority case is opened. Read More…

3. Warn people if a high priority case goes unassigned.

It’s fine notifying people when a high priority case comes in but what happens if no one pays attention or assignment rules cannot find a suitable match? Then we end up with an important case sitting in a queue of which everyone has already been notified and forgotten about. That’s why I always think its a good idea to notify if it goes unassigned for a short period of time. It is probably a good idea to send this notification to a small number of people or an individual manager that will take responsibility if this fails to be assigned again. In this example we will be using a time-dependent workflow to notify parties. Read More…

4. New Case – Auto response to customer

A standard feature across the online support world so why shouldn’t you have it?! Probably the easiest workflow to implement but has the greatest impact. Let your customer know that they have successfully created a case in your system giving them peace of mind while also letting them know key bits of information like support agent (if assignment rules are used as it will be assigned instantly), their case number and also reminding them of the reason why they submitted the case in the first place. Read More…

5. Move Spam and unregistered contacts to another Queue

This is an excellent way to ensure that only your customers gain access to your support agents. This workflow requires a bit more thought than just creating the workflow so in the tutorial I will explain all the steps that are necessary. The principle behind this is that we will get Salesforce to check if the case has contact attached to it, if it doesn’t we can assume that this email is not a contact of ours and is therefore spam or someone we don’t recognize as a customer. The great thing about using a process like this is that the cases never actually get deleted, they just get moved to the spam queue out of everyone’s way. So in the case where someone is actually a customer, we can simply add them as a contact so it doesn’t happen again and move them out of the spam queue. Read More…

6. Chasing up customers and automatically closing a dormant case

Presuming you have a case status for when it is in the customers hands and you are awaiting a response, it is probably a good idea to automate one or two emails to chase up the customers. Depending on your business processes and SLA contracts these could come in different varieties. You might decide that you never want to close a case automatically unless you have spoken to the customer first, in this case a couple of chasing up emails should do the trick spaced however far apart you feel necessary. If they still haven’t responded after this amount of time then it will probably be a good idea to ring them to verify the closure of it (It can’t be very serious). Of course we can also automate the closure of a case if it falls into particular parameters for example a Low to Medium case that has not changed from the customers hands for 14 days can be closed. This of course can be coupled along with a few warning emails to make sure the customer is aware of whats going on. In this example I will work through a few different examples. Read More…

7. Update Case Status when sending or receiving an Email

This is probably one of my favourite automation features that you can add with a simple workflow. The principle behind this workflow is to automate a status change which alternates between two statuses depending on who sent an email last. Obviously the two statuses will be different depending on your support process but I’m sure they will be something similar to “Awaiting customer response” and “Customer response received”. This workflow is based off the Email Message object, we can tell the difference between an email that was sent out and an email that was sent by the customer because there is a field called “Incoming”. This field is automatically populated by Salesforce depending on whether the email was incoming or not. Read More…

8. Update Case Status when the customer or agent leaves a case comment

Similar to the above workflow this is really essential if you are taking advantage of the portal and the case comment feature. What we can do here is update the case status depending on who wrote the case comment (Portal user or internal), as there is no “Incoming” field or similar. This is identical to the workflow above in the way it works as we can alternative between two case statuses. This of course can be combined with the email workflow to make sure the case status is updated no matter how the customer interacts with the case! Read More…

Hopefully this post has provided you with a few workflows to try out and at the very least given you a few ideas!