Archives for March 2020

The previous posts in our Center of Excellence (COE) series have covered everything from team roles and structures to delivery standards and processes to effective governance models for your Salesforce COE. In this post, we’ll focus on the support processes you need to establish for users and why that is vital to the success of your COE.

When it comes to products, great customer service plays a critical part in strengthening brand and product loyalty, and the same holds true for your Salesforce program. The right support structure and processes, established at the outset of a program, can not only make sure people are using the system to its full potential but also help turn them into evangelists for your program. If done right, a well-oiled support process can also provide valuable insight into user behavior, needs, and potential improvements that are invaluable for future iterations of an ever evolving platform like Salesforce.

Here are seven steps to creating an efficient and effective support process that can scale as you grow, and evolve as you do.

1.Outline your rules for engagement.

The first order of business is to establish the structure for your Service Delivery — clearly outlining and defining the different tiers you will use to address issues. Not all problems are created equal, and you shouldn’t treat them equally.  For instance, you wouldn’t make an appointment with an orthopedic surgeon to figure out the best way to get a splinter out of your finger. You’d probably just Google it, right?  

Tier 0: This initial self-service tier can be used for roughly 50% of all support needs, giving users a first point of contact for content, whether it’s process related questions, technical documentation about how the system is supposed to function and why, or guidance for different business functions related to your Salesforce system, such as sales stage definitions, lead conversion criteria, required data for certain records, etc. The goal here is to minimize the number of cases that need to go beyond this tier by providing users with the resources they need. Remember that scene in the late 90’s film Jerry Maguire where Tom Cruise implores Cuba Gooding Jr.’s character to “help me help you?” It’s kind of like that. If these resources can’t provide the answers that users need, then they move down the funnel to Tier 1.

Tier 1: Tier 1, essentially the “help desk”, can be accessed in many different ways depending on the organization and its resources — calling a 1-800 number, through a Slack or text-to-chat option, or by filing a formal support ticket. This tier is capable of handling programmatic administrative functions, and it acts as a gatekeeper, escalating cases to the appropriate team or individual as needed based on its discretion. That’s where Tier 2 comes in.

Tier 2: As the escalation point for Tier 1, Tier 2 is for cases that might need to be routed to a functional expert for non-standard process questions, or to a specialist for complex requirements or sensitive legal issues, or to an IT specialist for deeper technical issues. If one of those doesn’t solve it, then on to Tier 3.

Tier 3: Tier 3, which should comprise only about 10% of your queries, should either be an escalation point for strategic issues related to business performance or for technical issues and enhancements requiring code fixes and/or customizations.

Like in any good relationship, it’s important to create boundaries, and these tiers can help keep your high level technical staff focused on the right problems rather than handling every single request that comes in. Based on the size of your company, the make up of these tiers will vary. For smaller companies, you’ll probably have fewer tiers and/or the same people or groups handling responsibilities for multiple tiers. Larger companies, on the other hand, may have more stratified layers of support. However, even larger companies shouldn’t have too many levels for users to have to go through.

2. Determine what tools you’ll need. Now that you have your tiers outlined and a clear scope, it’s time to define the tools needed for work intake, prioritization and execution. Such tools could include Salesforce Knowledge for self service, Salesforce Service Cloud for case management, and omni-channel tools for advanced case handling (e.g. chat/phone integration). Once you have those established, it’s important to make sure you align your entire team around this set of tools, making sure everyone is educated and able to use them. 

3. Assemble your team. With the structure outlined and necessary tools in place, now it’s time to define the responsibilities of the various roles across the different tiers and begin training them.  Don’t forget to ensure that security is configured appropriately for all team members based on their defined set of responsibilities.

4. Empower super users. Try pinpointing certain users as “Super Users” and empower them with the necessary tools, training and permissions to help with training, to answer common questions, or to resolve basic issues. This will allow the COE and support team to focus on other areas that will add more value to the business.  

5. Build an internal knowledge base. Next, make sure you establish an internal Salesforce Knowledge Base which can be used for Tier 0 self-service as well as for the support team to reference. Doing this preemptively rather than after the fact will help deflect many cases that may otherwise have ended up taking up more valuable time and resources. A knowledge base can be built in many ways, but is typically created using release notes and/or documentation from the change management function.

6. Map feature requests to the roadmap. While the primary purpose of most support processes is to make sure users get the answers they need as fast as possible, it’s also an intake mechanism for feature requests, bug fixes and other enhancements that could add more value to the business. When outlining your support processes, make sure to clearly define your process for how service requests turn into feature requests which then flow back to the COE for roadmap evaluation.

7. Continuous improvement. Occasionally support requests come through because of a legitimate issue with the system. These instances need to be prioritized with the delivery team, and the necessary fixes should be incorporated within a defined release process. Sometimes support requests are enhancements that also need to feed back into the delivery process for prioritization. For more on this, you can revisit our post on delivery process and release management.

These seven considerations can get you well on your way to a fully functioning COE support center. Like most things in life though, communication is key. It’s important to communicate the process early and often, both to the team providing the support and to the users in the organization. People move around and things change, but your process should remain as consistent as possible so it becomes entrenched in your organization. A problem I see often with companies is that while the support teams have a clear grasp on the process and what needs to happen, the users themselves don’t and thus aren’t fully capable of properly using the system that was designed to support their needs in the first place. All because it wasn’t communicated well.

In the meantime, we’d love to hear about your own COE experiences on social media using the hashtag #SFDCCOE or if there’s a topic we haven’t covered yet that you think is missing.