At its most basic, the sync process is file transfer -- sales reps sending a file of work completed to a corporate client server where the customer data resides, and conversely, the corporate server sending the sales rep updated information.

Actually, syncing ability would seem to be a no-brainer for buying organizations. Of course, an SFA would provide remote access to a roving sales force -- that is just about the heart of how sales are made and managed. And in reality, sync technology is common to most SFA applications -- so common that users never even think about it. "Synchronization technology, is, or should be, invisible to the user," Chris Reich, SalesLogix's director of product management told CIO Today.

"It's not an issue users concern themselves with -- unless it is not working."

Checking Under the Hood

So, even though examining a vendor's synchronization technology and processes is probably the least sexy part of SFA due diligence, it needs to be done. It is a process that should go beyond just checking whether a vendor offers the capability. While the feature sets of most SFA vendors tend to be the same, the underlying technology is not -- and no more so than with syncing. In essence, there is no standard way to perform this task.

To be sure, some companies have tried to offer a standard sync technology that could be incorporated into an SFA engine. For the most part, those endeavors never took off --mainly because the solutions were not as bulletproof or elegant as enterprise-software vendors would have liked.

So, those companies set out to write their own standards and technology, most of which are proprietary and hence difficult for buyers to compare. Indeed, most analysts will tell you the best way -- no, make that the only way -- to get a good handle on what works well and what does not is actually talking to users in the field.

Does the system have automatic retries? Can it recover data if the connection crashes (always a concern when using a dial-up ISP in a hotel room)? This so-called "dirty line" quality problem is of particular interest to users. No one appreciates spending two hours to send updated data only to have the connection crash near the end of the process. (continued...)

1  |  2  |  3  |  Next Page >