CRM Usability Issues

One of the biggest challenges users have with their CRM systems is the fact that the systems, while powerful, are rarely easy enough to use.  While CRM is used in a variety of industries, for the sake of this post we’ll refer to sales professionals, with the following users being considered:

• Inside/outside sales professionals.  On the ground, directly connecting with customers.  These could be support staff, marketing professionals, etc..
• Sales manager (focused on one sales team, typically a line level manager)
• Sales executive (responsible for several sales teams)
• IT.  The internal technology team focused on deploying and maintaining the CRM.
• Customers (existing and potential).

Inside/Outside Sales Professionals

These people are in direct contact with your customers, and potential customers on a daily basis.  While we often focus CRM deployments on how to gather rich data for analytics we must balance that focus on easy, low-friction, entry.  Remember that you’re CRM must fit into how your team works, not how you want them to work.  While many disagree (at least in their actions if not their words) you will only find success if you deploy the solution to match this criteria.

1. It is often difficult to change sales people’s habits and get them into the CRM on a regular basis.  These people are either living in Outlook, on the phones, or running from customer to customer.  Your CRM must provide methods for lead entry from:
   1. Their mail client (Microsoft Outlook, Lotus Notes, Google Mail, etc..).  Provide easy methods to shift information that lives in e-mail directly into the CRM without duplicate entry.
   2. Mobile Access.  You cannot avoid this interface.  Obvious, yes, but there are still too many organizations that err on the side of security restrictions instead of helping their sales team be successful.  Provide a CRM interface that enables very simple data entry (limited # of fields).
   3. Look at speech to text solutions.  Let your mobile workforce call a single phone number, press a couple of options on an IVR, and record the message they want entered into the CRM.
2. Model your process but simplify it over the older, paper-driven, processes.  I see too many organizations that want to simply mirror their processes in their CRM.  As you automate, seek to simplify where possible.
3. Help the sales person do their job better, do not make it just about data entry.
   1. Use location awareness to help the sales person efficiently map out their sales calls.
   2. Provide rich relationship information so that the sales person can get introductions, referrals, etc.., through friends of friends.
4. Integrate social information.  Tap into the dynamic nature of social media to identify potential customers and automatically feed these leads to your sales team.  Do not force them to spend hours on Twitter, Facebook, LinkedIn, give them the data they need now.

Sales Manager

 These people are responsible for hitting their own quota and for managing and mentoring a team.  Oftentimes they are in this mixed job role, it is a very challenging role.  In addition to the changes above, help them out:

1. Provide clear reports on their strongest and weakest performers.  Revenue generated is key, obviously, but make sure the sales manager can measure the other key data points (leads generated, overall sales activity, etc..).
2. Provide real forecasting tools that enable them to provide numbers to the executive team, numbers that they can stand behind.
3. Identify at risk deals (or customers) by analyzing a combination of CRM-documented behaviors (lack of payment, # of support tickets) combined with social data (buzz about the company’s financial stability,  for example).
4. Identify potential growth areas, other potential customers to reach out to, etc..  For example, show me all businesses within 30 miles of Boston that have revenue in excess of $10 million that sell high definition TVs.  Give me answers even when I do not know the questions.

Sales Executive

You want to see a stressed sales executive?  Give them a sales target and then do not provide them visibility into the sales pipeline.  While this can be fun to watch it is never a winning strategy for the company.  Still, it happens.  The sales executive needs the data the sales manager needs, but at an even higher level. In addition, they need tools that can help them:

• Understand the levers they have at their disposal in terms of the incentives sales people earn.  If I change the incentive program, what is the outcome.  Ideally, help me model the results so I can make intelligent decisions before I make any changes. 

IT

•  You should not have to be a master of the dark arts to install the CRM.  Unfortunately, most on-premise solutions require a Master’s Degree in Statistical Analysis just to run the installer.
• Data quality management should be simple.  Identify potential data quality issues, don’t force the company to invest in hiring dozens of analyst to keep your system running.

Customers

Customers…..  Why is it that CRM systems seem to ignore the customer?

• Provide value to the customer.   If this is a support CRM system, make it easy to get answers.  If it is a sales system, make it easy for them to get answers.  Sounds simple.

What am I missing here?  Do you disagree with anything you’ve read?

John

Response to comments on UI automation of web applications

I was happy to receive a very well thought out response to my recent post (thank you Martin) on the lack of ROI for developing GUI automation for web applications.  Instead of burying the response in the comment section, I have posted the poster’s comments and interspersed my thoughts as well.

Here are Martin’s comments with my responses in quotes throughout.

——————————————————————————— 

Unfortunately, your blog entry does not mention how automation was done in either of the mentioned cases. It also does not seem to consider that test automation often is or should be aimed at regression testing (finding new issues in existing functionality that was changed). But I would like to take a step back for a moment.

John’s first thoughts:
“
Automation always helps to reduce the time to complete regression testing, and portions of your automation should also be run as part of your regular build process.  The important point, though, is that you can build solid automation focused on at other levels (web services, unit tests, etc..) that will be far more reliable to run and maintain, providing huge value without the same maintenance requirements as you will find with GUI-based automation.

I have been building web applications for years and know that the above types of automation find the majority of the bugs.  You will, of course, find a large #s of bugs is in cross platform, cross browser, tests cases.  For example, you will often find bugs on the Mac with Safari that you do not see on Windows XP with IE 7.  The problem, however, is finding GUI automation tools that are capable of running across the platforms you must support.  If you can find, or build one, you must often build additional complexity into your test automation framework, leading to larger maintenance headaches.  I still contend that these types of issues can be found more cheaply by manual resources.
“
Let us consider what factors affect the ROI of a test automation project, for functional testing. Actually, the kind of interface (web, GUI, messaging, whatever) is not the essence, so the below would seem to apply to all test automation.

First of all, how do you define ROI? In terms of money only? That would depend on why you are automating in the first place. What business objectives is it meant to support? Lower cost? A common objective, certainly. But shortening time to market, higher quality, a better grip on the test process, and more effective use of scarce resources can also play their roles. Often a combination of these is desired, and sometimes cost is considered rather less important than others. But to keep it simple, I will focus on cost here.

John’s response:

“Businesses must always focus on ROI in terms of money, both short term expenses as well as long-term investments which include everything from maintenance costs to turnover of employees that are not happy with their career growth.  While I will not go into a thorough multi-page analysis of the ROI, consider the following:

• Ignore the cost of the tools.  10 years ago these tools were expensive and they no longer are.
•  The yearly salary of automation engineers is significantly higher than manual testers.  My preference would be to have a smaller number of automation engineers focused on unit testing, web services testing (more expensive, I agree, than GUI automation engineers) with a few more manual testers. In simple terms I can replace every GUI automation engineer with two manual testers, a good trade-off for test coverage and for our economy with more workers working.
• From a career growth perspective, QA engineers have a better career path because those doing automation are working with languages like Java and C# as opposed to tool-specific languages (like SilkTest 4Test as an example).
• The cost for each business will vary from company to company.  However, analyze the bugs in your product for the last year and ask yourself:
  • What % of bugs would have been found with unit or web services testing?
  • What % of your application bugs were platform specific?  With those bugs would a manual tester have found the other UI bugs as well?  You need to invest in testing the other platforms anyway and you cannot do it with most functional automation tools.
  • How many hours per week do you spend in maintaining your automation?
  • When you run your entire automation suite, how many hours of manual testing are you replacing it with?
  • For the location that you are hiring at, do the skills exist to hire/replace existing people will needed?

There are clearly more questions but those listed above are the most critical.”
Also, it is not so much the extent to which the testing is automated that matters. Dorothy Graham says it could make sense even to automate just 2% of your testing, and I would agree. The question is whether the investment pays off, not how much you invest or how much you automate. An for a pilot project, trying out automation on 2% could also be a good idea.

I think what determines ROI is (mainly) the following:
- The setup cost (licenses, perhaps servers, training),
- the cost of creating the testware (automated test + supporting framework / software),
- the cost of maintaining the testware, and
- the cost reduction in manual testing.

John’s response:

“
You are right, of course, regarding the fact that you do not need to automate 100% of the test cases.  In fact, you would fail if you tried to automate all test cases, but that’s another discussion entirely.”
The setup cost depends on whether you buy or build, whether you use open source or commercial tools, etc. More and more people are finding out that free software can offer a lot of bang for no bucks (with no vendor lock in …).

The time and effort spent on creating the testware is interesting, but usually much less than the time and effort spent on maintaining it, as with all software. So let us consider the total effort. It depends to a large extent on:
- The development process (e.g.: how much time between releases),
- The product planning (e.g.: how much change per release),
- The test automation approach (an advanced one using a DSTL requires much less maintenance than Record & Playback; is automation complete when the product is ready for testing or is that when automation can start – DSTL=Domain Specific Test Language), and
- The skill of the automator (the quality of the DSTL, the maintenance sensitivity and maintainability of the testware).

The cost reduction I will leave for you to determine.
The amount of time between releases does not have to be an issue if the amount of manual maintenance is low enough. A good DSTL (high level, no irrelevant execution details, tooling details and interfacing details in the test) helps a lot by reducing the maintenance to the test. A good automator helps a lot by reducing the maintenance to the rest of the testware. The page object concept, for example, can be a great help here, both for web and GUI apps.

John’s response:

“
Again, good points.  However, the number of great automators vs. average automators ensures you never achieve the ideal situation above.  Even if you do, however, investing in other forms of automation combined with manual testing against the web front end is almost always cheaper.
“
One guy’s research indicated that about two out of every three test automation projects fails sooner or later. A major factor is that many are not aware that test automation is software engineering, and people with the wrong skill set do it. As a result, they may work hard, but not very smart. It is a bit like the guy who is asked what he would do to empty a bath tub when given a tea spoon, a regular spoon and a really big spoon. When he choses the big spoon to be able to work faster, he is asked why he does not simply pull the plug …

Of course, there are limits even to what a skilled automator can do. But in my experience of 10+ years of creating solutions for automated testing of all sorts of systems, maintenance was never a problem.
John’s response:

“
While I don’t know who this ‘one guy’ is, the numbers make sense.  Software projects fail at a high rate, a rate that is sometimes overblown due to the lack of a solid definition of project success versus project failure.  Automation development, if you ignore simple record/playback, is software development.

I am fine with agreeing to disagree but wanted to thank you for the detailed and passionate response.  Passion is what makes life great, don’t lose it.
“

Building mobile applications for CRM systems

As I noted in an earlier post there are many obstacles to a successful CRM roll-out.  However, once you’ve gotten past those issues your roll-out will only be successful if your users adopt the system.  A CRM system, as I’ve noted elsewhere, is just a tool.  If this tool is not used than you wasted your money buying it.

If your company has a combination of inside and outside sales people it can be especially challenging to drive CRM usage.  The outside sales people are constantly on the road with little time to make updates to the system, lowering the overall value of the system.  That’s where a strong mobile implementation makes all the difference in the world.

I wanted to spend some time in this post discussing the mobile solution that we’ve implemented at Swimfish, using it as a guide for how you can build your own mobile applications.  This is by no means a complete discussion on the topic as their are many other valid approaches, but this is one that has worked successfully for us.

Before you begin building the solution, you need to consider:

• What target devices will you support?
  • If you’re only supporting Blackberry devices consider building on the Blackberry Enterprise Server Mobile Data Software.  If this is the ONLY platform you’re supporting it is a good starting and ending point.
  • If you’re trying to support a broad set of platforms look for a strong toolkit.  We are currently using the ASP .NET Mobile controls.  They are acceptable but I will likely be looking for another alternative soon.  The controls work great but they can sometimes force you to make akward design decisions, ones that I want to avoid if possible.
  • In the name of code re-use we also use the same underlying code for our iGoogle Gadget and our SharePoint Web Part.  Code re-use is a good thing.
• What should your user interface look like?  With a variety of mobile devices on the market your challenges range from screen size, rendering differences, and lack of JavaScript support (on most devices).  You need to consider:
  • The complexity of your UI.  Keep your pages small and focused on single actions.  If you do not it will be easy for users to get lost.
  • Performance of pages.  Keep your pages simple, limit graphics, avoid pulling down lots of data.  Mobile performance is getting better in most of the world but it is still slower than your users will encounter running in their home offices.
  • Defining a user interface guide.  Yes, this applies to all of your applications, but with limited page sizes UI inconsistencies will be even more obvious.  Document your guidelines and use them.
• What functionality will you expose.  Your road warriors are not going to need every single function in the application exposed.  These folks are running from customer to customer and need to perform some key functions.  Identify those requirements, validate them, do usability testing, roll it out to these users and correct from there.

Sounds easy, right?  It should be, but this world is new for many people and odds are you won’t get it right the first time.  We’re on version 3.01 and, while I am very proud of what we’ve built, there are always things I want to improve upon.

I’ll quickly walk you through a few screens to give you a feel for the type of UI we’ve built to get a feel for the points I’m making above:

• Viewing working list
  •   A few key points that I wanted to note:
    • Headers and footers are available on every page, providing users with a consistent interface where they always know where to go to search for contacts, find help, or reach out to support for help.
    • Every page clearly identifies the purpose of the page as well as the object being worked on.  I find that it is much easier to lose track of where you are when working with mobile applications as the interruptions seem to come more frequently.  Providing users with helpful hints is a major help.

• Viewing a search results list.
  • A few key points that I wanted to note:
    • Search results are displayed in a consistent manner.
    • The use of icons that match what are found in the main desktop application provides users with easy to understand clues without forcing them to learn new standards.



• Viewing contacts
  • A few key points that I wanted to note:
    • There are many useful mobile applications that you can leverage from within your application.  Google maps, for example, can easily be linked to providing your mobile staff with additional functionality, at low cost.  Remember the environment that the user is working in and ensure that you deliver value to them in this mode.

If you want to check out our implementation more closely, let me know and I can hook you up with login information.

I hope this helps.  Let me know how you’re building your mobile apps.

John

Visual Thesaurus

If you ever use a thesaurus take some time and check this site out:

http://www.visualthesaurus.com/trialover/

The manner in which Visual Thesaurus visual maps our potential alternatives is highly intuitive and is by far the best alternative I’ve seen to date. While I could never convince myself to pay for the product I would consider buying it if I was a professional writer.
For user interface designers, engineers looking for new ways of building user interfaces, this is a site you should check out.

-John

Mistakes made by US-based SAAS applications?

If you’re from outside of the United States, do you have stories of foolish mistakes that you have seen in US-based SAAS products? Share with the group or drop me an e-mail.  I’d like to see if we can get some of these out in the open and try to improve upon past mistakes.

-John

My favorite search application

If you haven’t tried SearchMe (http://www.searchme.com/ ) you are missing out on a very cool search application.  Applications developers should check out the interface as we can all learn a few things:

• The iphone style interface where you can easily flip through search results is extremely easy to use.  Instead of scanning pages of text for results, as with google, you see the pages and can easily dig in when you see what you want.
• The ability to zoom into pages without fully launching the page makes the search process even easier.  With most search engines you are constantly drilling down, then back up, until you find what you want.  Searchme goes above and beyond in making it easy to avoid this behavior.
• The interface is actually fun to play with and you find yourself exploring and seeking to learn more about it as you’re searching for your results.

I won’t give away more secrets, explore and learn what’s out there.  The web keeps moving quickly, don’t let it get too far ahead of you.

-John

A few thoughts on UI design on a budget

I am currently working on a user interface guide for my company.  I joined the company in November and I was fortunate to inherit a few powerful applications that are loved by our existing customer base.  While these products do a great job of solving problems for our customers they sometimes look like they were designed by different groups at different times and by teams that did not communicate.  We have made strides but still have further to go.  Here are some of the items I will be discussing in our guide:

-  Style guidelines.  We use CSS but sometimes new styles appear to be created without enough thought.  You have to keep your CSS files clean and well documented.  Review them on a regular basis to ensure that new styles are only being added when needed.
-  Define guidelines around button placement and ordering.  It is far too common for people to order Save/Cancel differently from page to page, leaving customers confused with every new page they encounter.
-  Define load time expectations.  While many U.S. customers now have high-speed connections this is not the case throughout the world.  Make sure that your user interface loads consistently, and within a reasonable amount of time, for all of your target customers.  If your users regularly go get a cup of coffee while waiting for page loads, you’ve got the wrong user interface.
-  Avoid jagged interfaces.  Use rounded corners everywhere.  We are NOT there ourselves but we will be.
-  Use of descriptive text.  What types of information should be provided to users?
-  How are errors and confirmation text displayed?  Do you take users to error pages or show messages on the page.  Pick a method and stick with it.
-  Do you use pop-ups?  If yes, how should they display and what behaviors must they support.
-  How are lists displayed?  For example, if a lists of users is returned by a search make sure they are always displayed the same way.  In our mobile application, for example, we return lists of users on various pages.  This code needs to be common and the display of the users should clearly be the same on every page.

I know, as some have already pointed out, that this list is not comprehensive and only begins to scratch the surface; there is a lot to cover on this topic.  I definitely appreciate any thoughts you can add to the conversation.  Let me know what user interface standards you have.

-John