Last time, we discussed Alembic Java’s general requirements for Entitlements Management. If you haven’t read that post, I’d suggest taking five minutes to look it over. Even if you have, let’s refresh on the 30,000 foot view:
Alembic Java is a mid-sized company that supplies high-end Coffee subscriptions and services. Their market is offices and homes throughout the US. Besides coffee, they also provide coffee-brewing equipment and classes in brewing and appreciation.
- 60 support reps.
- Over 5000 customers and growing.
- Customer base is both commercial and residential.
- Two different support processes – one for commercial accounts, one for the residential accounts.
- The support process is First Response, Update the Customer, Resolve the Issue. The timing is different when the priority is higher.
- At the moment, the support reps verify customers by checking the account record. They look to see if there is an asset on the record. If so, Alembic will offer support.
When we sit down with Alembic, the first step is to get more clarity around item four. Two different support processes suggests that we might have two different milestone timelines. Maybe not. I haven’t written that far ahead yet!
So we looked into this, and here is what the folks at Alembic told us:
“We have two different approaches to supporting our customers. One for the commercial accounts and one for the residential accounts. Commercial makes up more than 80% of our revenue. A commercial subscription is going to be anywhere from 20 to 2000 times the size of a residential. We aim for 100% happy customers, but we do focus on a quick response for those large accounts. In our day to day, this means that we have a tighter turnaround for responding to our big customers. That said, we also rank being responsive on social media channels quite high. We want the public to witness our helpfulness even if it’s a one person account. That improves our goodwill.”
Hmmm… sounds great, except for one problem. They haven’t explained how there are two support processes. I don’t know about you, but I count one process that happens at different speeds. Let’s try again:
“I guess maybe we don’t follow different steps for different accounts. At least not in the support process. Large accounts do have dedicated account managers. We make sure the managers receive a notification if a case comes in on one of their accounts. If it’s a high priority case, the account manager also gets an action item to follow up with the customer. That usually happens within 3 business days of the case getting resolved.”
Ah! There we go. So that tells us that both types of accounts have the same steps in handling their cases. If you will recall, these steps are milestones. This is good to know for our purposes. Now we can get into creating some milestones.
Note: I hope that by now, your curiosity has gotten the best of you. If so, you’ve already set up a dev org and enabled entitlements management. If not, you should. Salesforce makes it easy to set up a dev org. They also make it easy to enable entitlements. Do those things. It will make the rest of this series a lot more useful.
So we’re in our org and have enabled entitlements. What we want to do now is create some milestones. Milestones are the atoms in the molecules called Entitlement Processes. They are the ingredients in our Support Soup. Milestones represent the building blocks of an entitlement process. Thinking back to item number five in Alembic Java’s list, they listed three steps:
- First Response
- Update Customer
- Resolve the Issue
These are three steps common to a lot of support organizations. Let’s walk through creating them:
- Each milestone begins at Setup::Customize::Entitlement Management::Milestones. Go there to get started.
- Click the button, “New Milestone”.
- We’ll make the First Response milestone first. Fill in the fields as follows:
- Name: First Reponse.
- Description: First response to the customer.
- Recurrence: No recurrence.
- Click “Save & New”.
Ok. You just created your first milestone! Admire it. It’s the first step in your gradus ad parnassum to Service Cloud excellence. Now that you’ve finished admiring it, let’s talk a little bit about those fields you filled in. The first two are self-explanatory, but that last one is a little less obvious.
When we talk about recurrence in milestones, what we’re getting into is repeating a step. Recurrence in a milestone means that it might happen more than once during a case. Non-recurrence means that you’re going to do it once and that’s it. Looking at the milestones for Alembic Java, they break down like this:
- First Response
- Resolve the Issue
- Update the Customer
So let’s move to the other non-recurring milestone, which is Resolve the Issue. Use the steps defined above to create the milestone. The only difference should be in the Name and Description. Otherwise, it’s the same type of record.
Two down, one to go! I’ve saved the best for last. Setting up the ‘update the customer’ milestone should feel familiar. It’s almost the same as setting up the other milestones. The only difference is, we have to address this question of recurrence. Like you learned, recurrence means the milestone might happen more than once. Updating the customer is a great example of recurrence. If the case is taking a long time to resolve, then you may need to check in with the customer more than once. The question that comes up is this:
“When does the clock get set back to zero?”
Consider the following scenario:
- It’s 9am on a Thursday. There is a case that comes in and it is an emergency.
- Your policy to update the customer every four hours if it’s an emergency. You update the customer at 11am. Is your next update due by 3pm or 5pm?
If it’s due at 3pm, then you have an independent milestone. Every time the previous milestone is complete, the new one starts. If you updated the customer at 11am and noon, you’d still have another update due at 4pm.
If it’s due at 5pm, then you have a sequential milestone. There is a defined start time to each milestone, and that time is when the previous milestone was due by. If an update is due in four hours, the next update (assuming another one is necessary) is due in eight hours.
So with independent milestones, the clock is reset as soon as the prior milestone is complete. With sequential, the clock starts at the target date of the prior milestone.
Another Salesforce expert contributed some good material on this topic. If you want to read more on it, you could do worse than to go here. In the case of Alembic Java, the Update Customer milestone is sequential. They want to keep in touch, but they don’t want it to get weird. So, let’s go ahead and get that milestone built for them.
Once again, we’re going into Entitlement Management::Milestones::New Milestone and setting up a milestone. Under recurrence type, choose “Sequential.” That’s it! You’ve created a recurring milestone. It’s a lot like creating a non-recurring milestone. The difference is now you understand it a bit more.
Creating the Entitlement Process
So, 1300 words in we’ve gotten to the point of creating the milestones. That’s our first step, but now we’re going to want to create an entitlement process. If you’ll recall, milestones by themselves are only the building blocks. When we put them together in a meaningful way, then we’ve made the entitlement process. The entitlement process is also referred to as the SLAProcess, so you can expect me to use both terms.
To start, let’s get into the screen for making the entitlement process.
From the Setup Menu:
- Entitlement Management
- Entitlement Processes
- New Entitlement Process
A new screen appears with some fields for you to fill in. When we fill these in, we are defining Metadata that we will be able to call on in the future. Here’s how I filled mine in:
- Entitlement Process Name: Caffeinated Customer Support
- Description: Standard support for Alembic Java customers
- Active: True
- Default Version: True
- Version Notes: I left blank
- Case enters the process: Based on case created date
- Case exits the process: Based on when case is closed
- Entitlement Process Business Hours: blank
You could choose to do something different here. I’d recommend exploring your options. Think about why you might select a different point in which the case enters or exists the process. Consider the possible options around business hours. One thing I’ll mention right now is that you get a lot of choice around business hours and entitlements. You get to define them at the process level, the entitlement level, and even the milestone level. Like I’ve said, it’s a flexible system!
While you were considering your options, I clicked Save and now we’re onto a different screen. This one has a cool timeline on it and is where we get to define the actual steps in the milestone timeline. To place a milestone into the timeline, find the Milestone list at the bottom of the layout and click “New”. Another page will open and this is where we begin to put a milestone into a meaningful context. It starts with selecting which milestone you want to use.
- Select the Milestone Name dropdown
- Select “First Response”
Next, we decide the ‘time trigger’. For now, think of this as how long the agent has to complete the milestone. Alembic tries to respond to all cases within four business hours. This field is in minutes, so with some quick math we decide to put in the number of 240.
Start time for this one is the same as when the case shows up. So we’ll select “Entitlement Process”. This means that when the case happens, the clock starts ticking.
For business hours, we want to use the same hours that Alembic’s support team works. In this case, we’ll select the option of Business Support Hours. What is nice about this is that you are not limited to one set of business hours in a support process. The most specific ones will always apply. You might use this to create some milestones that have extended hours. You could use this to make milestones with narrower business hours. It all depends on the business requirements, but it’s good to be aware of the options.
Moving on, we want to set the order to 1. This is the order in which this milestone appears on the list of milestones on the page. Don’t confuse this with meaning this is always the first milestone. This is sort of like defining assignment rules – it’s a question of what is the first match. And that brings us to the last bit of this page, which is criteria.
The criteria refers to the conditions required for this milestone to exist in a case. If the criteria never match, the milestone never happens. For this one, we’re keeping it simple. Set the criteria to be when the Case Status is Equal to New and then let’s leave it at that. Click Save and there you are, creating the beginnings of an entitlement process.