Task driven CRM

Synopsis

A discussion on the integration of task focused UI approach to customer relationship management (CRM) applications.

Introduction

With the emergence of CRM in the 1990 came the promise of changing the way businesses interacted with customers. However delivering on this promise is a challenge - the high volume of records involved are difficult and expensive to keep, track and maintain.

CRM grew out of database marketing into advanced market specialised systems able to track customer activity and spending patterns, translating it into incentive programs and integrating with ERP systems. The scope and depth of CRM applications grew considerably making it of strategic import to the major software vendors.

Why change the CRM UI approach?

Figure 1: Siebel On Demand Sales Automation site-map

The site-map above was derived from the Siebel OnDemand CRM application for Sales Automation. One may ask if this information architecture is Siebel specific. However on analysis of two other major vendors in the same space Sales Force and Sugar show a similar approach.

Example 2: Sales Force Sales Automation site-map

Example 3: Sugar CRM Sales Automation site-map

While the functional capabilities of CRM systems has matured the same cannot be said for the way which users interact with these systems. As mentioned previously CRM grew out of database marketing and it seems these roots are still clearly evident today. Currently the majority of CRM systems bind their information architecture (navigational structure) on the table structure of their underlying database schema.

It is suggested that this database schema to information architecture binding was not so much of an issue in the early days of CRM where the number of entities being kept, tracked and maintained was small. However over time the number of entities has expanded considerably. It is clear the functionality of CRM has outgrown the implemented user interface approach.

This author describes such a user interface approach as schema driven. This approach can be powerful for users who are intimate with all the tables and their associations. Such "power users" are able to quickly navigate to the required table making updates and using reporting tools to retrieve knowledge from the system.

However the same approach can be daunting to novice users who find it difficult to navigate and understand how the entities relate to each other and how the UI makes it easy/adds value. The schema driven user interface reviews badly in usability research (see HFI report on Astra Zenica). This is probably due to a testing culture which pre-supposes a requirement for all software applications to be intuitive, not requiring all users to be power users to take advantage of their UI approach.

The CRM UI dilemma

The current dilemma for CRM UI designers is the age old battle between pandering to legacy "power users" and growing the market with novice users. CRM is a relatively mature market sector with large numbers of legacy users (in the 100's of thousands) with growth figures considerably smaller than the heady hay days of the late 90's. What really is required is an approach to modifying the UI approach which adds value to both the power and novice users.

The Microsoft Office analogy

The Office functional footprint has grown considerably over the years with basically no change to UI approach. As a result it continually came under criticism from users as suffering from feature bloat - "lots of powerful features, but I never user them".

However Microsoft was never in a position to slim down and increase the user experience for fear of suffering the consequence of taking out "important functionality" for specific users. It solved this dilemma by completely rethinking the UI approach, incorporating the "ribbon" concept.

It successfully sold (in this author's view) this new UI approach to the market by supplying data showing that both legacy (power users) and novice users benefit from the (radical) UI change. The new product initially slows power users down but after a few weeks have been shown to become faster than they were with the old UI approach and novice users show a marked speed improvement in take-up of features both standard and advanced.

The fighter airplane cockpit analogy

The following is an image of the instrument panel of a world war one bi-plane fighter and beside it is a screen grab of one of the first interation of Siebel CRM

The cockpit

It is easy to see even at the early stages of their development aircraft required pilots process a considerable amount of data. In this case one can see there are three main gauges six smaller gauges and assorted switches that control the various functions of the aircraft. During this time pilots flew "by the seat of their pants". Instrumentations was important but not nearly so much as their ability to "keep their eyes peeled", spot the enemy and point their "kite" and go in for the kill.

The CRM screen

Here one can see that the application only has a few tabs with simple functionality within an individual page. This application looks to be quite approachable even by a novice and quickly mastered by a power user.

The following is an image of the instrument panel of an early cold war jet fighter and beside it an image of a modern day CRM application screen

The cockpit
It is immeadiately obvious that this is a considerably more complex aircraft to fly. The number of gauges looks to be at least quadruple that of the previous cockpit as well as includinig numerous switches, levers and joystick toggles. At this time the ability to accurately process the information presented was the difference between life and death, placing huge strain even on highly trained pilots.

The CRM screen
Here you can see the application has many more tabs and the screen is full of panels with different types of information. All this information places load on the user - quickly overcoming the comfort level of the novice and placing considerable strain even on the power user.

The following in an image of a modern jet fighter cockpit.

This cockpit while still highly functional is considerably less confusing than the previous example. New digital screens are implemented instead of gauges and the number of switches and toggles has been reduced and made more consistent design. While flying this type of jet still requires considerable training, the intrument panel has been designed specifically to reduce pilot information load by providing the information needed at the time it is needed.

It is proposed that the user interface for CRM needs to mimic that of the modern jet fighter by completely re-inventing the way the system presents information - compressing the user interface by displaying just that information required at the point that is required.

What is the solution to CRM UI dilemma?

This paper proposes that a task driven UI approach as a model for achieving the very same results Microsoft has with Office. Initially slowing down legacy power users but in a short period adding value to their experience and significantly reducing the time for novice users to become proficient in what previously have been regarded as complex CRM transactions.

At a high level task driven CRM looks to heavily leverage pre-packaged sequences of screens (trains) to guide users on the completion of common CRM tasks. A common objection to the task approach is that while it is good for novices it restricts/slows down power users who can work faster accessing data in a non linear manner i.e. jump ad hoc from schema item to schema item.

The proposed solution to this objection is to integrate non linear access to the set of tasks that make up the application. This can through the integration of smart follow on tasks. Smart follow-on tasks are a list of tasks contextually driven by the current screen focus.

The following examples demonstrate how users can access entities within the system in a non linear manner:

Smart follow-on tasks example 1

• The user searches the system.
• The system returns a set of results of different entity types - accounts, promotions, products, visits.
• The user selects one of the items (an account)
• The system adds below the table of results a list of tasks that can be performed on the selected (account) item.

Smart follow-on tasks example 2

• The user runs the task to chart an account
• On completion of the task, under the chart the system adds a list of task that can be performed with the charted account.

Continual prompting users with contextually relevant tasks promotes logical non-linear movement between entities.

UI adaptation feature

Potentially the list of contextually relevant tasks could be automatically generated by the system based on the current entity focus and ordered based on the number of times the presented follow-on task had been off taken previously. Such a system would adapt over time learning a users particular working methods bring the most likely follow-on to the top of the list.

It is suggest that such an adaptation feature would be especially effective in environments where users tended to be novices. The following is an example of a Bank Teller product with the task driven UI approach:

1. The teller enters the customers account ID
   
2. The system returns a list of all the transactions previously completed by the customer ordered by frequency
   
3. The teller asks the customer what transaction he/she would like to complete (it is suggested that over time the mostly likely answers to this question will appear in the generated list already infront of the teller user reducing the time taken to complete the service of said customer).
   

What would a task driven CRM UI look like?

I seen previously the schema driven approach to CRM UI leads them contain a large number of navigation items. The normal impact on the user on such large numbers of navigation opportunities is information overload. Interestingly one of the major impacts of implementing the task driven approach is a significant reduction in the number of required navigation items.

Information Architecture

The task driven UI approach will have the impact of significantly compressing the number of menu items required to support even the most functionally rich CRM applications. There are many ways to skin a cat, the following is just one example of what the site-map for Sales Automation based on the task driven approach could look like.

Figure 4: proposed Sales Automation site-map

In this case the number of 1st level navigation items has been reduced from 12 to 4. In the task interface UI approach groups of tasks are logically grouped under a small number of menu items, in this case "Manage Customers" and "Manage Opportunities". The "Home" tab provides three pages - "Overview" - a dashboard screen which rolls up important content to the user to promote off-take, "Find" - a search screen where users can interrogate the system for entities in a non linear manner, "Add" - a data capture screen. The final 1st level navigational item is "Analysis" which would contain reporting tools.

Figure 5: proposed navigation system

It is proposed that an opportunity exists to add another higher level of navigation to the application UI framework to enable on screen navigation between application types - for example between Sales Automation and Service. In the case of multiple application implementations the opportunity also exists to add a "Portal" menu deliver a dashboard which roles up content to users who have roles across applications.

Screen Architecture

Figure 6:proposed screen architecture

The extensive use of trains within the task driven approach requires that the main screen area be broken up into two parts - a contextual pane and content pane.

Screen Flows

The following is an example of a Chart account flow. The user starts in the "Products" application in the "overview" page, navigates to "manage accounts" page, selects the "Chart Account" task following the task to completion.