COE

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.

If you asked most companies why they bought Salesforce, “speed” or “agility” would probably top the list. Companies gravitate to a platform like Salesforce because they want a tool that will help them automate time-consuming manual processes and capitalize on new opportunities faster than what is currently possible with their existing systems. 

If a company’s goal is to move fast, it’s easy to see why many might resist the idea of a Center of Excellence. To these resistors, COEs = process, and process = bureaucracy. Few people think of bureaucracy and think speed. However, I can tell you from experience that Salesforce COEs — if done right — can in fact help an organization increase its pace of innovation. 

The Value of a Salesforce Governance Model

One of the primary jobs of a Salesforce COE is to establish and enforce an effective governance model around the platform. In essence, to provide the structure – the systems, principles, and processes – that a growing organization needs to take full advantage of a platform like Salesforce. 

Salesforce has become a sophisticated platform that can now cross multiple functions and touch nearly every role in a business. Without some kind of governance model in place, IT teams and their business partners will spend more time dealing with conflicts and managing rework than making sure the organization is using the system to its fullest potential. A governance model helps in three ways:

It aligns system decisions with business priorities.

As requests for new features, fixes, or components come in, a governance model can make sure they are evaluated and prioritized in a way that will have the greatest business impact and will ensure the appropriate people are involved in making decisions.

It speeds decision-making.

A governance model lays out who is responsible for what and establishes decision criteria and dependencies at the outset to make sure decisions can happen fast and not get stuck in limbo.

It increases system usage and adoption.

The processes and principles laid out in a governance model make sure executives and stakeholders are involved in key decisions and milestones, which not only helps identify issues early on but also increases support and communication around changes. More on change management later in this blog.

How to Establish a Governance Structure That Works

A governance model can’t be created in a vacuum. It needs to be a collaborative effort between the business and IT. However, the enforcement of it ultimately rests with the COE lead, or in larger organizations, a governance board. Below is an example of how a medium to large organization might structure its governance model and the groups that are involved. In a smaller organization, you might have members spanning multiple committees, roles, and responsibilities.

For more details on the specific roles within a COE and these steering committees, check out part 2 of our COE blog series. 

A COE’s Role in Communicating and Managing Change

Change management is something that needs to be thought through for any major business investment, and it is a critical function of any Salesforce COE. I separate change management into two areas — managing change with people and managing change within the system.

Let’s start with the people side as that’s typically the more difficult aspect of change management. Plenty has been written about humans’ natural resistance to change, and how change triggers our instinctual fight or flight mechanism. However, research also shows that if you can help people understand what change is coming, why it’s happening, and how they might benefit, they are much less resistant to that change. Even better if you can get them involved early on. Once people are bought into what’s coming and why, giving them the tools and time to deal with change in their own way can make the difference between success and failure. 

Salesforce COEs play an important role in evaluating how new features or changes to Salesforce will affect an existing implementation and the users who depend on that functionality. A COE should establish a two-way communication structure to communicate changes early and often and make sure feedback from affected parties reaches the appropriate decision-makers. Unfortunately, many companies take the Field of Dreams approach of “If we build it, they will come.” That only works in movies, and there is no such thing as too much communication when it comes to change management.

Once changes are decided upon, communicated, and built, it’s time to take them to primetime and release them. This gets us into release management, which is essentially the process by which you introduce change into your Salesforce environment.

Move Fast But (Try Really Hard Not to) Break Things

Release management relates to planning, scheduling, and managing a software build through different stages and environments, including testing and deploying software releases. Some companies release continuously, which means as features are developed they move through different testing and production environments in near real-time. Others stick to milestone release schedules where features are released in bulk on a scheduled basis. You can read more on how leading organizations handle release management in our Salesforce Best Practices research.

Whether you are a large organization releasing continuously, or a small organization with a few external developers releasing once a year, it’s critical to establish a process for how you are going to move changes into production. We see too many people not using the developer sandboxes that come with their Salesforce licenses, and working directly in production. If you do this, 10 times out of 10, you will get an error or will end up overwriting or breaking something in production. 

There is a range of tools to help Salesforce teams manage releases – from Salesforce Change Sets at the basic level to more sophisticated tools like 10K Connect which can instantly simulate a deployment and validate changes before they are pushed to production. The important thing is to pick a tool and process and hold to that.

All of this takes a certain level of time and preparation. A governance model isn’t established overnight, and it should be evaluated on a regular basis to make sure it’s still working inside the organization. Change management and release management processes take time and forethought to establish and enforce. But I guarantee you that a small investment up front will pay dividends down the road for your users and the overall health of your Salesforce system. 

Part 5 of our COE series covers how to give end-users the support they need and how to ensure their feedback is incorporated into your Salesforce roadmap. 

Download our guide to maximizing your Salesforce program ROI.

Our last blog in the Center of Excellence (COE) series described the team, roles and structure that will help organizations run a highly successful Salesforce program. In this blog, we’ll focus on how those experts work together and execute in the most efficient and productive way possible.

Let’s start at the beginning. The purpose of a COE is to manage your Salesforce system in a way that delivers on near-term needs while ensuring long term performance, and that all comes down to execution. More specifically, managing your implementation as part of a cohesive program, not a series of one-off projects. It’s not unlike a relationship. Serial dating might keep you busy and happy for a while, but if you want a long-term relationship, you’re going to have to put in some work. And like any relationship, it’s always good to set some standards upfront.

Set Your Standards

Standards set the bar for what is expected, and establishing them at the outset will ensure teams understand what is expected of them and result in higher quality deliverables. Standards, if they are set early and communicated often, will also help guide internal team members and external vendors to look at the Salesforce system in a cohesive way, ultimately reducing your technical debt over time. For Salesforce COEs, at a minimum, you should be considering technical standards and delivery standards.

Technical standards include things like:

Metadata creation: These are things like naming conventions, descriptions, and the help text that will help give you a more consistent and easily maintainable implementation.

Feature usage: Depending on the specifics of your implementation and the skillsets of your team, you may choose to use certain Salesforce features over others. Documenting how and when to use features like workflow, process builder or flow, versus writing code, is an important distinction to make. This also extends to how you use add-on features such as CPQ or Field Service Lightning in conjunction with the standard Sales and Service Cloud features. 

Coding: Coding standards ensure your developers (which may be in-house or outsourced) craft code that is easier to maintain, and if done correctly, performs better. This includes documenting naming conventions, code style and structure, the use of trigger frameworks, test classes, and more. Here is an example of what a document like that might look like, albeit dated.

Delivery standards include things like:

Requirements definition standards: These definition standards outline what information has to be included when defining user-centric requirements and ensures that those collecting and writing requirements know which questions to ask. This will also guide how to document the answers, which will allow for a more efficient handoff to the delivery team.

Success criteria/metrics: One of the most important questions you can ask your business stakeholders when interviewing them is “How will you measure success?” This can sometimes be a challenging question to answer, but it is very valuable as it adds context to the requirements. It will also help ensure the solution is designed in a way that allows stakeholders to achieve those measurements.

User acceptance criteria: Along the same lines as success criteria, user acceptance criteria provides context around the specific actions that users of the solution should be able to accomplish. When these are clearly defined they are not only helpful in solution design but also very effective for quality assurance and testing.

Proposed solution design: This is a written and/or visual explanation of how a solution should be developed and includes information about the technical components that should be used by the delivery team. This is very useful for stratified teams where an architect or tech lead reviews a solution design prior to development.

Define Your Delivery Process

Once you have your standards documented and communicated, you need to think about how the delivery process will work across your Salesforce COE. There are many different delivery methodologies that range from agile to iterative to waterfall to everything in between. Which delivery process you choose will depend on your organization’s overall maturity in IT delivery. Some companies enforce a business-wide set of processes that are tightly coupled across teams while others allow more autonomy. The majority of companies today use some sort of agile-like process, ranging from strict adherence to Agile methodologies such as Scrum to a basic iterative, story-based process. 

Delivering on the Salesforce platform is different than most other technologies because Salesforce is both easier to customize and sees more frequent platform updates. Salesforce issues three releases and hundreds of new platform features every year, so regardless of your situation and your broader IT process, you’ll likely want to tailor certain tenants of your delivery process. For example, our research into Salesforce Best Practices shows that more than half of Salesforce program owners do production releases at least every other week or more often. This may be different than how other systems are handled in your organization. 

Plan Holistically

As you outline your process, it’s important to think about it as a journey and consider every milestone along the way, from the moment work has been scheduled to when it is released into production. In our experience, work typically breaks down into the following major categories:

1) Requirements definition, sizing, scoping

2) Backlog review and scheduling

3) Capability delivery (development, testing)

4) Release (environments, regression testing, production)

Each gate should have clearly prescribed entry and exit criteria, including who is responsible. Here is an example of the entry and exit criteria that we use for 10K Connect:

One of the best ways to document the different steps and owners is to create a swim lane diagram, which is a high-level flow outlining the end-to-end delivery process and the interdependencies. For more complex processes, it may be helpful for you to create multiple diagrams. For example, one outlining the high-level delivery flow, one for the detailed development process, and one for release management.

Once you’ve documented your definitions, process, and owners, don’t forget to communicate it!  You can’t hold people accountable if the standards and process aren’t communicated clearly and often. Using tools that align with your specific delivery process (vs. a generic tool, or worse no tool at all) can help immensely with communication and ensure your teams will adopt the right process. 

Part 3 of this series covers release and change management. It will also highlight the COE’s role in governance and ensuring the process, standards, and flow are top of mind for everyone involved. 

Download our guide to maximizing your Salesforce program ROI.