• Don't introduce all new labeling
• Don't introduce new ways of formatting (example: show $ sales in 1,000s)
• Don't change sequence of fields
• Don't omit information relied on today

Use similar terminology, formatting, and ways of presenting data that the users are already used to seeing.

Let's buy it.
The benefit of an out-of-the-box solution is to bring economies of scales to the smaller firms that don't have the resources to develop their internal SFA solutions. If you have less than $50 million in revenue, then you probably don't have the resources to invest in a customized solution. If you have greater than $50 million in revenue, you should probably consider at least partnering with an experienced firm to help you customize and/or build your own solution.

Don't forget to allocate resources to develop our user handbook.
Forget about it! If you have to create a handbook to explain how your system works, then you've missed the mark.

Anthony Pericle has a broad background in distribution with management positions in sales, finance and information technology. A speaker and author on business intelligence, he is a consultant to both the Fortune 500 and the $5M distributor. He can be reached at tony@gmail.com.

boxes and how to use technology creatively to solve sales/business problems. The IT department should serve in a supporting role to advise.

Let's form a committee.
There is a law of diminishing returns that states that for each additional person added to a committee beyond 4-5 people, the less effective that committee becomes.

We recommend selecting a core group of individuals (3, no more than 5) to serve on the main project committee and that one person has ultimate power to direct the project (the business leader). This is your primary project committee. Then form other committees to support efforts.

We need the System Design Methodology document completed before we begin.
There are many IT professionals who think they can work in a non-iterative manner in developing solutions. They believe a detailed script will give them what they want most and that is a schedule that can be well-planned, consistent, and non-interruptive.

They are correct that a process like this leads to a "nice schedule." But relying solely on documentation has not, cannot, and will never produce the optimal SFA solution.

Key point: You can't replace personal interaction between the project leader(s) and the IT personnel with the "perfect" document. We believe the best format for documentation is to require the business to create prototypes of their solutions (using such tools as MSExcel or MSAccess), then supplement with explanations on how the user interacts with the system.

Prototype, document, and allow for scheduled daily interaction between the business and IT people.

Creating the best solution = solving as many problems as you can.
This one should be obvious. There is no perfect solution. If you try to put too much into your first generation solution (version 1.0), you will fail. Identify 3-5 areas of greatest need, and solve those first.

Java is best.
We were involved in a project some years ago where we were given the task of replicating an SFA application that was written in C and was tablet-PC based. The leader of the project wanted to use the "hottest" technology of the day: Java. The developer had a difficult time with even the most simple tasks such as sorts and filters.

While Java can be the best technology for Internet-based applications, it was the wrong technology for a tablet-PC based application. After one month, the project was scrapped.

Educate yourself on which technology works best for the platform you are going to use. Don't use technology for technology's sake.

The data looks good.
The greatest single threat to any SFA project is not having credibility with the basics. If users look at your application and see sales of $12,052.76 for a given customer, they want to be able to see that identical figure (to the penny) in their legacy system. If you can't tie out the numbers, you will fail.

Often, SFA projects are focused primarily on the development of the application with little or no resources on data integration and most importantly data quality assurance (QA). And when there is a QA effort, it is superficial at best.

We were involved in a project where our first step was to replicate the legacy system's data transformation process. The client was questioning our methods as they thought they were paying us to develop a sales force related application. But after just a few weeks, we were able to uncover inconsistencies that were imbedded in the legacy data.

Let's not worry about what the sales rep is used to seeing.
The best chance for adoption is to bridge the old (legacy system) with the new (your SFA application) via some common ground.

A few critical rules:

For the past decade, distributors have been working to automate their sales forces. More have failed than have been successful. This article examines why these projects have not delivered on the promise of increased efficiency and sales rep effectiveness.

The goal of sales force automation is two-fold:

• To maximize the efficiency of the sales representative
• To optimize the decision-making process of the sales representative

Customers are better served when their sales representatives are in a position to quickly and accurately respond to customer inquiries. And when customers are better served, increased revenue and higher margins are likely to follow.

I started as a distributor sales representative for a medical surgical company in the early 1990s. Back then, the primary sales information available was as follows:

• A dot matrix print out of the local inventory listing
• A green bar report of the items and/or product categories sold to each customer
• An 800 number to the local branch

While customer questions could be answered in a general fashion, most questions were deferred until the sales representative was able to talk with someone at his local warehouse.

As technology advanced, many companies attempted to automate" their sales forces. The first attempt at automation was the introduction of the personal computer (PC). Later on, the laptop offered improvements in how quickly answers could be retrieved. However, the problem with the laptop was that while on the surface it seemed portable, in many cases it was not convenient for the sales representative and the manner in which most sales calls are made.

In recent years, technology has evolved to address the "portability" issues faced by sales representatives. However, hardware is only a small part of the equation. The most important part is the software and how a sales representative uses it.

CRM, SFA… It's all the same.
There has been significant hype in recent years about Customer Relationship Management. On the surface the goal of CRM and SFA should be the same. However, most CRM companies have one primary goal: to enable a sales representative to manage hundreds or thousands of customers and potential customers. That's the key difference. Most distributor sales representatives manage just 25-100 relationships.

Many distributors make their first fatal decision by engaging CRM vendors to solve their sales automation challenge. The problem:

• They don't have a distributor perspective
• Their core competency is not presenting transactional data (history, inventory, pricing, etc.) in a meaningful manner to the sales rep

If you want to make those that manage the relationship of existing customers as efficient as possible, then don't worry about sales funnels, graphs and charts. Stick with solving what your sales representatives really need: To be able to answer questions like "Do you have this in inventory?" or "What's my price?" or to identify and solve problems before they become problems to the customer.

Let's let IT lead the project.
The beginning of the end for most SFA projects is to rely solely on your IT department to solve your SFA needs. The best qualified person to lead your SFA project is someone who has sold something, understands the operational logistics of your business and has a passion for efficiency and simplifying the life of the sales person.

We know of a company where the IT department leads product development for all SFA-related projects. Not one of the members of this department has been in distributor sales, let alone successfully sold anything to anyone. And it shows.

The best leadership for your SFA project should be a sales-centric person who understands your business logistics of moving