Customer service coding tipsCustomers tell me that they have a problem with their agents cherry-picking cases and leads. They use assignment rules to assign the objects to queues, but once they're in queues, the agents look them up in list views and accept them from there. This can give opportunistic agents the ability to screen cases and leads, assigning to themselves only the easiest cases or the most promising leads.

Today's post offers a new way to perform this assignment. Using some simple Apex code and a custom button, I've created a Get Next button that works on both leads and cases. This button sits on the case or lead page. It looks up the queues that the agent is a member of and finds the next open case or lead assigned to one of those queues. If one is found, it then assigns the case or lead to the agent, and navigates the page there so the agent can begin working it. It's pretty quick and intuitive. Here's the code for it. The sample code as posted is somewhat generic, so you may need to modify it, particularly the one for Lead to identify more tightly what constitutes an "open" Lead for your agents. 

You may notice that these code samples are part of our ever-growing Developing With The Service Cloud wiki page -- if you haven't seen that, it's worth a look. It's full of goodies.

These buttons aren't the whole solution for the cherry-picking problem, however. For a complete solution, you'll need to prevent the agents from seeing list views, and you'll also need to prevent agents from "peeking" at cases or leads and then throwing them back in the queue if they seem too hard.

The former, preventing access to list views, is fairly simple. The simplest way to do it is just to deny access to the Case and/or Lead tab by hiding it for your agents' profiles. Another option is to replace those tabs with a simple Visualforce page which just has a button that calls the same Get Next code and pulls the next case or lead for the agent to work.

The latter, preventing peeks, is a little more tricky, and something you need to think through. You can't completely prevent the agent from changing ownership of cases or leads, since they need that ability to make the Get Next button work. You can, however, add a validation rule that says that for a given profile, once a case or lead has been assigned to an agent, that agent cannot change the owner. That validation rule might look like something this:

AND( $User.Id<>OwnerId, $User.Id = PRIORVALUE(OwnerId), $Profile.Name = "Agent" )

Be careful though! Your agents may actually on occasion need to change ownership of a case, for instance if they're leaving for the night or on vacation, or if they need to escalate the case to another tier. So you might need to make exceptions to your validation rule for this. The above rule is therefore only a sample.

An alternative would be a softer approach; you could allow your agents to reassign cases back to a queue, but when they do, add a workflow that emails the agent who reassigned the case and his supervisor. That way, if an agent were doing a little too much peeking, the supervisor would be well aware of it (and the agent would know that the supervisor knows).

Preventing cherry-picking is never an easy problem with a one-size-fits-all solution, but with a little customization, it's generally not so difficult to arrive at a solution that will work for you.

This post was originally written by Marco Casalaina.

MC_BlogButton_SC-Trial