Sonoma Partners Microsoft CRM and Salesforce Blog

Driving CRM Adoption Through Effective Communication

Today's blog post was written by Scott Hinton, Principal Consultant at Sonoma Partners.

CRM implementation success is directly related to the level and speed of user adoption. According to Forrester, 49% of CRM people-oriented project issues reported were due to slow user adoption. Resistance to the change initiative is a major culprit. When a CRM project is announced, it's common for impacted users to experience fear and uncertainty related to leader expectations and how work will be done.

A comprehensive communications strategy, as part of a broader managed change effort, drives CRM adoption and positively impacts behavior change, leadership alignment, change readiness, and training efforts.

Change communication best practice is to launch clear, timely, ongoing, and effective project communications from multiple senders and distributed through multiple mediums with targeted messages. Communications are needed during the full duration of the project or program starting with an official launch long before implementation and continuing through the post go-live change reinforcement phase. Let's take a look at seven ways to maximize communication effectiveness and better meet project objectives overall:

1. Assess the Organization and Build a Communication Strategy

A baseline gauge of impacted users' level of awareness and understanding, as well as the historic level of success of change project communications, provides a starting point and informs the Communication Strategy. The Communication Strategy outlines communication objectives and provides the direction for the project change vision, communication plan, messaging, change branding, and communication roles to best facilitate end user movement from initial project awareness and understanding to buy-in. 

2. Create a Change Vision

The project change vision describes the project "Why." The vision is often referred to as the "Case for Change" and outlines the project value and who it is valuable to. It provides the foundation for minimizing resistance and maximizing adoption and overall engagement. It's also a powerful tool for aligning leaders because it incorporates business goals and defines what project success looks like.

3. Develop a Message Map

Precise messaging improves communication effectiveness. The process that outlines end user change topics is called Message Mapping. The Message Map defines impacted stakeholder expectations (leaders/employees), project benefits (organization overall, impacted users, and clients), where the organization is going and how/when it will arrive at the desired future state. According to Prosci, a global leader in change management research and education, employees want to understand the project "Why" and the risk of not changing. Communicating what's in it for me (WIIFM) based on what users really care about, is often overlooked and a critical communication component. 

4. Build and Manage a Communication Plan

The Communication Plan brings it all together. A few things to remember:

  1. Communication Plans typically include the communication month, date, audience, medium, frequency, key message/s, senders, and creation owners. Ask resources (HR, Marketing, etc…) with specific company knowledge and/or communication skills to review the plan and ensure the communication plan is covered at project team meetings and Sponsor checkpoints.

  2. Leveraging multiple senders beyond the project team including the executive sponsor, sponsor, and key functional managers is encouraged. According to Prosci, "Employees prefer to hear messages about the business issues and reasons for change from the sponsor and prefer to hear about the day to day impact on their jobs from immediate supervisors." Use designated change agents to reinforce key messages. This distributes the role of change leadership throughout the organization.

  3. Utilizing a mix of communication mediums is also important including face-to-face because it's more personal and better facilitates dialogue.

  4. Repeating key messages at least five times increases the likelihood that the information is absorbed.

Scott hinton table 6

5. Know the Audience

A structured change management framework better facilitates adoption because it’s not a one-size fits all approach. Through various assessment tools, unique user requirements and perspectives are captured, and communication can help address particular needs.

6. Ensure Feedback Loops are in Place

Emphasizing listening and providing feedback loops ensures all voices are heard. This allows impacted users to be part of the change; ideas are captured and trends are identified. Feedback should also include pulse surveys to validate communication effectiveness.

7. Create a Change Initiative Brand

A change brand creates message consistency and is a powerful communication tactic for strategic change programs. Branding could include a slogan, change initiative name, and logo. It’s a great way to market the change and develop brand identity, recognition, and legitimacy.

Early communication supports greater project awareness. Thoughtful and deliberate ongoing communication builds understanding, acceptance, and ultimately buy-in. An effective communication strategy will account for and increase the degree of change readiness at the individual and organizational level and result in quicker and higher overall adoption levels and project success.

As always, please reach out should you have any questions.

Topics: CRM Best Practices

Proper CRM Planning in an Impatient World

Today's blog post was written by Scott Zelinski, Senior Director at Sonoma Partners.

The pressure on Sales, Marketing, and IT leadership to deploy CRM quicker and cheaper is higher than ever. In addition, senior management expects CRM solutions to be deployed for their organizations with minimal disruption and immediate business benefit.

Cloud-based CRM platforms like Salesforce release new features and functionality three times a year and bombard their clients and prospects with stories of quick deployments and ROI success in an incredibly short amount of time. Mobility, predictive analytics, linkages, or acquisitions of related applications are announced constantly. On the other hand, research groups like Forrester and Gartner claim nearly half of CRM deployments fail due to lack of adoption and proper planning.

So where is the middle ground? The days of detailed and drawn out strategic CRM planning are over. Current solutions can be stood up in a matter of days and cloud-based licensing begins almost immediately upon signature; the meter is running. Yet standing up a solution quickly and expecting adoption and business return to follow with no plan simply won’t work.

Step 1: Define Scope of CRM

When we begin discussions with our clients and ask them to define what CRM means to them, they often talk only about sales force automation functions – turning leads into opportunities and orders. As depicted in the figure below. CRM encompasses every way you touch your prospects and clients/customers. The customer life cycle stages depicted may not be exactly yours but they’re close, and each is an important piece of your CRM plan.

Step 2: Identify CRM Business Capabilities

The number of solutions, modules, apps in the market today is endless, but the business capabilities that your firm is trying to achieve do not change. Organize your thoughts by identifying the business capabilities that are most critical to your firm. See examples in the figure below.

Step 3: Self-Assess

Rate each business capability on two axes: (1) criticality to your business and (2) how well you currently achieve it. The results will create the starting point where planning and research need to occur. Identify the senior leaders in the business and in IT that will likely need to address improvements and increased business value.

Step 4: Create Your Plan

Make it simple, start with quick wins, especially those that drive the behavior and adoption from the field (not senior management). With the appropriate business capabilities identified, strategic research can be done that focuses appropriately on a smaller number of initiatives without being overwhelmed.

Step 5: Begin to Execute Your Plan

Realize that CRM is a program, not a project. Think in terms of evolution of maturity, the desired future state won’t happen overnight, but each project advances your organization in the capabilities you desire the most. Continue to track and score your organization as priorities will change.

Scott Z blog imgIf you need assistance with these types of challenges in your firm, we welcome the discussion: contact us.

Topics: CRM Best Practices

Artificial Intelligence: All the Rage with CRM Today

Today's blog post was written by Kristie Reid, VP of Consulting at Sonoma Partners.

The latest CRM buzz is around Artificial Intelligence. No, not the kind of AI that allows computers to take over the world (yet) or the latest winner of Jeopardy.  I mean the kind of machine learning that can process your CRM data to reveal some pretty amazing things. Some of the use cases thought of so far include:

  • Predictive analytics for lead scoring
  • Proactive notification to identify deals going south before the sales person recognizes what is happening
  • Understanding customer sentiment without needing to pick up a phone to see if they are happy or dissatisfied
  • Automated email creation that inserts the content before you can even think of what to write Kr 1

Salesforce made a huge announcement a few weeks before Dreamforce about “Einstein.”
This is what they are coining as their machine learning technology built directly into the
Salesforce platform. In true Salesforce fashion, they went big at their annual conference with adorable Einsteins running around with the 170,000 attendees.

Kr 2Microsoft doesn’t have a catchy title like Salesforce (or a cute logo), but they do have Azure Machine Learning. This product is currently more of a platform which can be configured and incorporated into your Microsoft products, including Dynamics CRM (or Dynamics 365 for Sales these days).

No matter which product you use, this is exciting stuff for CRM applications which have historically been thought of as overhead. Imagine telling your sales team that CRM can now write their emails for them!

But before announcing how smart your CRM system is to your organization, here are some things you will want to consider:

  1. You must feed the beast: The predictive analytics engines that power these tools require data for them to analyze. So, for new CRM implementations, this may take a while. Be realistic about what you can expect and when.
  2. Garbage in makes even worse garbage out: Artificial Intelligence does not resolve the age old issue of "bad data in, bad data out." Except now, there may be more risks exposed since "bad data in" could lead to bad decisions.
  3. Who’s right, who’s wrong: What if the output from the machine learning algorithms doesn’t match your rules? These instances can be taken case by case, but this is something that should be monitored by a business sponsor who understands.

Questions/comments/concerns? Give us a shout.

New Call-to-action

Topics: CRM Best Practices

SmtpClient for Quick Notifications

Today's blog post was written by Matt Dearing, Principal Developer at Sonoma Partners.

From time to time we'll need to write a quick script to mass update records in a CRM environment through the API. One of the easiest ways for a developer to do this is through LinqPad. Depending on the number of records that need to be queried and updated, the script may need to run for an extended period of time and most likely at night or on the weekend to avoid impact to end users. An easy way to get periodic status updates, without sitting at your desk monitoring the progress, is to leverage SMTPClient. SMTPClient will allow you to send yourself, and others, email status updates and notifications of any error while your script is running.

At Sonoma Partners, we use exchange online, so an example would be: 

A similar call could be made to send an error message and stack trace. This gives you the ability to fire off your script and go do something else while being notified of progress and of any errors that may occur and require your attention.

Have a question for us on this or other CRM-related matters? Drop us a note.

Topics: CRM Best Practices

Filtering Connection Roles by a Property of an Account

Today's blog post was written by Sonoma Partners' Principal Developer Argyris Anargyros and Senior Developer Jeff Young.

As part of a recent project, we had a client request to limit native and custom Connection Roles available to an Account based on a set of properties on the Account. While it is possible to filter the Connection Role field as you would any other lookup field, there is no native behavior to support filtering based on some specific property of an entity. Meeting this requirement required some custom development and, as we can see this being very useful, we are sharing the technique we developed.

The Use Case

In our case, the Account entity had been customized with a set of Yes/No fields that, if selected, would control the set of Connection Roles available to the Account, defining restrictions on how the Account could connect to other Accounts and Contacts.

Argy young 1

Figure 1: An example of the fields available to our entity. Here we have created a section on our form labelled 'Connection Role Filtering Fields' and added the fields controlling the available Connection Roles. In this example, the Connection Roles associated to fields 1, 3, 6, 7, 10 and 11 will be used to filter the Account’s available Connection Roles. The schema name for the field “Role Filter Field 1” would be new_rolefilter1.

Business logic determined the Connection Roles available to each field; the set of available Roles for the Account would be determined by which fields on the Account were selected as “Yes” and by the type of entity to which the Account was connecting.

Further, all the fields could be selected “Yes” or none could be; there could be any combination of fields.

Our first step was to determine what native functionality we could utilize, then decide how to extend it.

Filtering a Lookup

As we’ve said, CRM provides a way to filter values presented in a lookup field by JavaScript natively. Also, the Connection Roles form is just that - a form - so it’s possible to add JavaScript to it and have it run on form-related events, such as onLoad.

There are two JavaScript methods that are members of the lookup control that are utilized when applying a filter: addPreSearch and addCustomFilter.

addPreSearch is essentially an event listener that is attached to the lookup control, triggered when the lookup control is clicked. The argument for this method is the function that should run when the event is triggered. 

From within addPreSearch (and only from within addPreSearch) the addCustomFilter method can be called. addCustomFilter accepts two arguments: a subset of FetchXML which is the filter applied to the lookup and the schema name of the entity the filter is being applied to. This method is run on the lookup when the user clicks on it, which can easily be confirmed using a breakpoint on your favorite F12 tool.

It’s important to note that when using these methods, promises, or other non-synchronous methods can exit from the closure of the listener method and make applying the filter difficult to impossible. We discovered this as we have an extensive library of JavaScript tools at Sonoma Partners that we use to extend and enhance functionality of the Xrm API, including both synchronous and asynchronous use of the Org Service.

Our original implementation of this solution utilized the asynchronous Org Service methods, which gave us some problems because the promise, once invoked, had lost the context of the lookup (specifically, the closure in which the reference to the lookup had been exited). In our experience, it’s easiest to apply a filter using a sequence of synchronous calls instead of capturing the context of addCustomFilter and passing it to the promise when it runs (perhaps capturing ‘this’ and passing it as an argument to the promised method).

Our next step was to figure out some way of identifying the subset of Connection Roles to apply to the lookup filter.

Configuration Setting Entities

Configuration Setting entities are a common way of managing CRM behavior at Sonoma and elsewhere; giving System Administrators a convenient way to manage CRM behavior without editing code. In our solution for this project, we created a Configuration Entity that possessed simple key/value fields. We utilized these records to manage behavior of multiple entity scripts, just like this example.

For use with Connection Role filtering, we created some Configuration Setting records whose keys were a unique string based on our purpose and the schema name of the fields on the Account entity we wanted to control the filtering. This made the name of the record something like “Connection Filters for your_field_here”. So, if our Account entity had a field named “new_rolefilter1” and this field was checked as “Yes” we would retrieve the Configuration Setting record named “Connection Filters for new_rolefilter1.

Argy young 2

Figure 2: An example of the Configuration Settings record associated with Role Filter Field 1 (schema name new_rolefilter1)


To reflect the business logic the value of these records, then, were the names of the Connection Roles we want to filter by; specifically, comma separated string of the names of the connection roles, such as “Accounting,Administration,Coordination,etc…”

Strings are a convenient way to express this data as we can split them easily into an array once we’ve retrieved the record. They may not be so easy to administer, however, especially if the list of the record maintains becomes long. In this case, expanding the entity to include multiple fields would be one option which would present a more user-friendly way of managing the fields, but we would lose the programmatic convenience of getting and splitting a string and would be introducing issues with forward maintainability; adding Connection Roles would require editing this form, for example. For this reason, we went with strings.

Having all the pieces in place, now we need to bring them together.

Using the Configuration Entities to Filter Connection Roles

We attached a script to run on load of an Account form. This script retrieved the values of the fields that will control the available Connection Roles, determined which fields were set to “Yes” and then retrieved the configuration record for each one of these fields.

Using the value of each configuration record, we build an array of unique Connection Role names (some records may contain the same Connection Roles, see below) by retrieving the value of each configuration record and splitting it by a comma.

Then, using this array, we construct the Fetch XML fragment that will be applied to the lookup. The fragment is part of an ‘AND’ condition appended to the query for the lookup. Because we want to filter on a name or a set of names, we must nest the Role names we want to match against within an OR condition. The final XML looks much like below:

<filter type="and">

<filter type="or">

<condition attribute="name" operator="eq" value="Accounting"/>

<condition attribute="name" operator="eq" value="Advisory"/>

<condition attribute="name" operator="eq" value="Provisioning"/>

<condition attribute="name" operator="eq" value="Communications"/>

<condition attribute="name" operator="eq" value="Scheduling &#038 Maintenance"/>

<condition attribute="name" operator="eq" value="Logistics "/>



The result of applying the filter will look similar to the below image:

Argy young 3

In sum, when we load the Connection Roles form for an Account, we:

  • We add a listener to the Connection Role lookup field.
  • When the lookup is selected, we query the account to get the set of properties that effect the Connection Roles.
  • Using this set, we query for the Configuration Records for each positive field.
  • From this query, we build an array of roles that are available to the Account.
  • From the array, we build XML that applies a filter to the lookup.


As we developed this solution, we encountered a few issues that provided some challenges.

  • Filters must be URL escaped. When testing our solution, we ran into immediate problems with the Fetch XML we were building; CRM was reporting Malformed XML. Looking closely at the XML, we noticed that custom Connection Roles created by the client contained the ampersand and forward slash characters, which are special characters in XML. In order to correctly handle these characters when applying the filter XML, they need to be replaced by their encoded HTML value (‘&’ becomes ‘&#038’ as can be seen in the example FetchXML above).
  • Make sure to remove duplicates from the filter list.
  • Methods used to filter the lookup can’t be asynchronous. Forewarned is forearmed!

We hope that this technique will help you towards your CRM endeavours.

Topics: CRM Best Practices

Enabling Configurable Plugin Trace Levels

As we mentioned last spring, Dynamics 365 now supports tracing messages from plugins without requiring an error to be thrown.  However as plugins become more complex, we often find ourselves wishing for more granular control over the level of detail traced without requiring code recompilation.  With these requirements in mind, we will build an elegant solution that has minimal impact on performance.

First, we'll define an enum that introduces the different levels of tracing we want to support.

This should start to look familiar if you use log4net or similar logging frameworks.  The different levels (Debug, Info, Warn, Error, and Fatal) provide the granularity we are looking for when configuring how much detail we want in our Plugin Trace Logs.  The other two values (All and Off) provide a more explicit way of completely enabling or disabling tracing.

Next we’ll add an internal class to our plugin assembly to wrap all of our trace calls.

The main constructor starts by getting the ITracingService from the passed in IServiceProvider and storing it in a field for later use.  It then goes on to look for a shared variable on the IPluginExecutionContext which will define the minimum tracing level to trace.  If that shared variable doesn’t exist, it defaults to the minimum level passed in to the constructor.

Now we’ll add a method that will actually perform the tracing.

The Trace method takes a level, a format, and an array of arguments.  If the level is at or above the minimum, the format and arguments are combined and then passed to the previously saved _tracingService.  We prefix the message with the trace level, to provide extra detail.  This could be further enhanced to provide timestamps if you are investigating performance concerns.

Finally, we’ll add a few convenience properties and methods to our Tracer class just to make it easier to use.

The properties provide a quick way to check and see which trace levels are enabled.  For simple messages there isn’t a need to check these properties, but some more detailed traces have to build up a complex messages.  In these cases, it is worth it to check and see if the targeted level is enabled before building the message.  The methods here are simple shortcuts for Trace with the level specified as the method name.

Now we’re ready to write a plugin that takes advantage of our new class.

While this plugin’s logic is very contrived, it demonstrates how to use the Tracer class.  There are examples of tracing at different levels and checking which levels are enabled before composing a more complex message. 

We can register this plugin to run during the Create of a contact using the following configuration:


If the plugin is left registered by itself, it will always be configured to run at the “Info” trace level (The simpler Tracer constructor it uses defaults to TraceLevel.Info for the defaultMinimumLevel).  If we want to change the level without making code changes, we’ll need to introduce another plugin.

The TraceConfigurationPlugin uses the Unsecure Configuration value to set the TracingLevel shared variable on the execution context.  As long as we register this plugin to run before any of our other plugins, it can specify the level the plugins following it should use.  We could even register multiple steps for the same message with different Execution Order values if we wanted to have different trace levels for different plugins.

Here is an example of how we could register this plugin to run before the BusinessLogicPlugin and set the trace level to “Debug”:


Now we can use the Tracer in all of our plugins and feel comfortable adjusting the trace level as more details are needed during troubleshooting.  No additional API calls are made to read the tracing configuration values, so this will have a minimal impact on performance.

To see how to enable tracing and where to read the logs, please reference our earlier blog post.

Topics: CRM Best Practices Microsoft Dynamics CRM Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

Branding Your CRM for Successful User Adoption

Today's blog post was written by Ariel Upton, Marketing Manager at Sonoma Partners.

Don’t underestimate the power of personalization.

There’s a reason your mom wrote your name on your shirt tag at camp, why monograms have such staying power, and why pet owners choose to stitch Fido’s name directly on to their leash. Take a look at your mobile device – nearly every component, from wallpaper and lock screen display to icon orientation and brightness, is customized to your personal preference.

Regardless of the use or intention, there is a unique value to personalized possessions, and your CRM system (and subsequent user adoption) could greatly benefit from some personal branding.

In this post I will highlight some explanations for why personal branding is essential to promoting user adoption in addition to outlining some tactical approaches you can use within your organization.

People carry their good (and bad) brand experiences with them.

It’s more than likely that your team has encountered some sort of customer relationship management software during their career. Whether that experience was positive or negative will greatly impact the success of your current or future deployment.

If their previous experience was good, they may expect to similarly model your CRM environment and pushback on any decision you make to go in a different direction. If their previous experience was bad, they may refuse to use the same system (even though it’s a new deployment) and sour the opinion of fellow coworkers.

And for this very reason, we highly recommend that you brand your CRM in a unique way to replace your team’s prior experiences with a particular platform.

Choosing and implementing a successful CRM program has nothing to do with the technology.

It doesn’t matter which software your company selects, the success of your CRM program relies completely on how well it’s implemented and how well it’s adopted. Knowing this, you should be whole heartedly focused on creating a system that’s personalized to fit the needs of your company, your employees, and your customers. Spend less time communicating the feature/function comparison between platforms and more time crafting an internal plan and message for how you’re going to personally brand the tool for your company’s specific use cases. The more you can make it yours, the better off you are for promoting high levels of user adoption. 

Okay all of this is great, but give me the good stuff. How do you actually brand your CRM for success? Here are a couple of tactics we use internally and have borrowed from our customers:

1. Give it a name.

At Sonoma Partners we refer to CRM as Grapevine or GV for short. The name is personal to our business (you know we’re crazy about the wine theme) and gives the tool a unique name that can’t be confused with any other system.

Here’s another example. One of our customers named their Salesforce deployment, Mark. Yup that’s right. Mark. No one on their team refers to CRM or Salesforce; they only refer to Mark. They even have beautifully designed Mark-branded pullover sweatshirts. This commitment to personalization not only makes the tool feel like something that is uniquely theirs, but it also creates internal buzz and greater organizational awareness of their CRM efforts.

Bonus: Giving your system a unique name is an easy (and free) method for personalizing your CRM.

2. Employ UX.

Pro Tip: Devote some of your CRM project hours to a User Experience Architect. A dedicated UX resource has the ability to understand your team’s motivations and is extremely receptive to what your users actually need vs. what the business thinks they need. Furthermore, UX resources are excellent at determining what data needs to be surfaced in CRM and creating a personalized look and feel for your system and your system alone.

3. Make it yours with mobile.

If you’re still on the fence about investing in a mobile CRM solution for your workforce, jump off right now. Providing your team with a tool that is built for them and that they want to use? That’s a grand slam for successful user adoption. Mobility boosts your credibility in the eyes of your customers, especially when the app you’re working in is personalized to your business.

We’re here to help you personalize your CRM for successful user adoption. Contact us to learn more.

Topics: CRM Best Practices

It’s Not You, It’s Me: How to Best Break Up with Your Current CRM Partner

Today's blog post was written by Kyle Gerstner, Principal Architect at Sonoma Partners.

I've recently been working with two different clients who were both in a situation where the relationship with their current partner had soured. In listening to these clients, I was shocked to realize it took a final straw for them to start seeking a new partner. So many problems had happened throughout the relationship, but they had waited, trying to stick with it and work it out. As an outsider, I initially thought, what took them so long?

But the reality is – just like in our personal relationships – breaking up with your current CRM partner is hard.

The most obvious reason for this is money. At some point, you've invested so much money into the initiative with the partner, you just want your money's worth. The second is that now you feel jaded. How do you properly vet the new partner? You feel like you just got burned and are unsure of how to move forward. For help on that, we have some tips here.

Once you've made the decision to end the relationship with your current partner, there are a few things you should do to protect yourself:

  1. Don't let on right away that you are going to end the relationship. Letting them know can either change nothing or make the situation worse. Your current partner could just focus on salvaging the relationship or write you off and become unresponsive. Either of these two things will make the next steps harder, so its best to keep a lid on it.

  2. Get access to the codebase and ensure you are getting daily updates. Review the code internally, or if you have found a new partner, have them review it. Not having this could mean starting from scratch with your new partner. You also want to have assurances that the outgoing partner is staying above board as they roll off. Getting your new partner involved in the review helps ramp them up and drive the discussion for the next two points.

  3. Review your documentation. Determine what hasn't been done and what was changed. Update the documentation accordingly. This documentation will help you prioritize what needs to be done next. While its fairly easy to determine that a whole feature is missing, its harder to determine if the execution of the features was to spec. Once you have the documentation updated, this can also be used by your new partner to ramp up.

  4. Start asking questions. What tools are being used? What environments are setup? What servers are we using and what are they being used for? Has the partner used any of their own IP and who owns it? Your outgoing partner did all of that work FOR YOU. You should know all the ins and outs of what they are using in order to do that work. If they used something and you don't know about it, it may cause issues down the line. Also, use this as a way to track what they have access to, so you can turn of that access when they are gone.

  5. Once you've selected a new partner, let the old one know you are going to end the relationship. Schedule an end date and some knowledge transfer meetings. Ideally, get your new partner on these meetings. The goal is that these meetings will be fairly quick, because you have done steps 2-4, so there shouldn’t be too much more to learn. Your old partner may not agree to these and just want to let you go on your way, but you should be confident that you can.

It’s not easy to find the right partner, nor is it easy to end a bad relationship. There are steps you can take to protect yourself and help facilitate the transfer to your new partner.

And, as always, we’re here to help.

Topics: CRM Best Practices

3 Tips to Get Your Seasoned Sales Team to Use CRM

The other day, we had a client in the office who told us about his ongoing challenges with user adoption. His story was one we have heard before.

He works at a large manufacturing company implementing a CRM system for the first time.

Their sales force consists of seasoned professionals who have 30+ years of experience in the industry; experts who manage their expansive client list in Excel, Outlook, in their heads, or some combination of the above.

In his attempts to onboard his team onto CRM, he is oftentimes met with resistance, frustration, and concern from several of the senior sales reps.

Getting a seasoned workforce to care, and effectively use, a CRM system can be a challenge. If you’re facing a similar challenge, we thought we’d provide you with three steps you can take to set yourself up for success in getting your senior sales reps on board with CRM.

1. Point to the positives. 

If you are implementing CRM for your organization, chances are you have a pretty good reason for doing so. You’ve been witness to your organization’s inefficiencies or struggled with cross-departmental communication. Maybe it’s a merger or acquisition that prompted you to reevaluate CRM and reduce process redundancies. It could be a lack of flexibility in your current platform and lack of mobile functionality you’ve heard complaints over. Your employees want the ability to incorporate data and CRM into their work processes seamlessly in their daily routine. You selected a platform that might not fix all of their problems, but the mobility offered by the new system is a serious advantage for your team. At the end of the day, you pick and choose which features are most important to you and your team. State these facts clearly to help demonstrate the importance of this resource you’re providing.

CRM is not going to be the answer to all of your prayers – just see my next point – but you can certainly paint the picture for your change-averse employees. Make it clear that this is a priority because of the impact it’s making on your organization, your processes, your efficiency. This will help them understand and hopefully, motivate them to use the tool.

2. Set expectations from the start. 

In conversations with your team, set expectations when you outline the business goals of your impending CRM implementation. Maybe one of your senior sales reps has seen CRM fail before. They’ve been promised that this magical new tool will come in and instantly make their lives easier. This expectation cannot always be achieved with CRM. It takes time to onboard an organization to a new system. It means changing mindsets, individual work behaviors, and thoughtfully evolving organizational processes. Good work like this is not done overnight but through time and effort, finessing and tweaking. Ultimately, the reward is a well-built solution that proves a true asset to your organization.

3. Offer support and guidance along the way. 

It is entirely possible that your seasoned work force is extremely technically savvy. We have, however, witnessed situations where our clients struggle to break down barriers with a work force carrying many years of experience. They find it difficult to try something new and unfamiliar, especially if using a platform they find intimidating and challenging. It might be worth offering that an extra level of support to those who express or seem resistance to adopting this new tool. Maybe all they need is a little bit of reassurance to get started.

Ultimately, approaching your seasoned sales force with CRM strategically can make all the difference for your CRM implementation. CRM takes time and work, but the benefit is enormous when done correctly and adopted fully.

Need help with your CRM implementation? We can help.

Topics: CRM Best Practices

50 Ways to Name Your Test Cycle

Today's blog post was written by Jen Ford, Principal QA at Sonoma Partners.

One of the things that has stuck me over as I work with different QA departments is how different companies name their Test Cycles. Company A conducts ‘Acceptance Testing.’ Company B says they are doing ‘Ad Hoc Testing,’ not Acceptance Testing. Company A’s Acceptance Testing involves coordinating Super Users to test using a minimal test case structure and making sure they’ve covered all of the functionality they expect to be in this software release. Company B’s Ad Hoc Testing involves coordinating Super Users to test using a bullet-pointed list of items to test and make sure they’ve covered all of the functionality they expect to be in this software release.

These are the same thing. Call it Acceptance Testing, call it Ad Hoc Testing; the definitions these two companies apply are the same.

True, there are some testing types that have a clear definition. White Box Testing, for example, is the testing of code paths and deriving test data from what is known about the code. Only a tester that understands how the code was developed will be capable of doing a decent job at White Box Testing. However, White Box Testing also has many different names: Clear Box Testing, Glass Box Testing, Structural Testing, or Logic Driven Testing, to name a few.

The point here is not to get hung up on how the Test Cycles are named. What is important is that when planning your testing, go through the exercise of naming each Test Cycle and defining what type of testing will occur, the roles of the testers, and what test cases will be executed, in each cycle so everyone is on the same page.

For example, testing could be defined this way:

  • Unit Testing – testing done by a developer before code is deployed to QA
  • Integration Testing – testing done by QA, but only of systems integrating with each other and how data is passed between the two
  • System Testing – testing done by QA to make sure the code updates meet the business requirements
  • Acceptance Testing – testing done by Super Users and Business Analysts to make sure the code meets the business’ needs.

The ultimate goal with testing is to make sure that we are delivering a high quality product to the customer, and what you name the Test Cycle doesn’t achieve that purpose. Give your Test Cycles a name and definition early on to provide consistency on the project, and then you won’t have to worry about mixed messages on what you are testing.

Happy Testing!

5 Questions to Ask When Evaluating CRM Consulting Firms

Topics: CRM Best Practices