I’ve used Salesmetric (www.salesmetric.com), a hosted, web based sales lead tracking system, for a couple of years. (The provider calls it a “sales force automation” tool.) In this report I describe my experiences using it and some of the things that I have learned.
Overall I’m very pleased with the system.
With clients, prospects, and other consultant/employees spread throughout the country, Salesmetric works well. Sometimes dozens of users were registered and actively using the system, at other times, just a few.
Users can access Salesmetric while on the road by using a public web terminal or a networked laptop to create or update prospect records. Users can transfer documents to colleagues in other cities by uploading and attaching them to a company prospect record. Individual users can check their personalized Salesmetric “dashboards” to see what sales related tasks are due by date. Using the “attach documents” feature it’s easy to share RFP’s, contact records, and relevant news reports about an individual sales prospect.
Prospect managers can assign dated follow up tasks (“tickler files”) to themselves and to others. When task assignees log in, they see their dated tasks on their individualized “dashboards.”
For large client or prospect companies where there are multiple people working in multiple departments and talking about multiple business opportunities, it is easy to generate a single view of the activities and people with relationships at that company. By assigning ownership of a single sales prospect or client to a single staff member, managers can bring together responsibilities so that – in theory at least – a single individual on staff can keep track of communications with a single company even when these communications are taking place throughout the world.
This is a lot of power to be able to access through a simple web browser, and I assume (although I have not checked) that other web-accessed hosted sales tracking systems share some of these same features.
There are a few downsides with Salesmetric. I don’t know if these are typical of this type of a service. Whether these should be considered as “serious” will depend on your expectations.
We augmented the standard Salesmetric report generation scripts with our own, mainly for technical and content reasons. The built-in Salesmetric report generator will generate reports in HTML or Excel format; that is fine for generating easily updated lists, but sometimes we needed a bit more in terms of sorting and data display. We built our own reporting routines based on a daily download of data from Salesmetric to our own Microsoft Access database that we maintained on our own network. This required the maintenance of a “shadow database” and all that entailed in terms of cost and maintenance. Whether other users would require this I can’t say. We had the technical capability to do this external reporting database and we did it.
Would we have done this had Salesmetric, out of the box, supplied 100% of what we needed? Probably not. But I could also argue that when we initially subscribed to Salesmetric that we did not have a total understanding of how our requirements might evolve.
One issue that eventually surfaced was that the underlying data model of the Salesmetric database may or may no be adequate to the needs of all organizations. In our case we found some subtleties in underlying data structures that had some interesting impacts on our uses of the system.
One instance where this happened was our need to “slice and dice” assigned actions and sales prospects in terms of not just the Salesmetric system’s table based standard industry designations (which we could easily modify) but also additional codes designating time bounded “campaigns” where targeted the selling of particular services to particular groups of people or prospect companies.
We needed to establish multiple classifications for “sales campaigns” of varying sophistication and duration. We “re-purposed” some unused data fields and re-defined them using our own criteria, then used these to sort the data when we exported activity records to the external MS Access database. Occasionally this got messy since we’d want to track progress by industry as well as by campaign and the core system didn’t’t always make this very easy. (Perhaps if we had been more willing to spend money on customization by Salesmetric for our particular requirements this would have been solved but at the time we were not willing to do this.)
There was no direct connection between Salesmetric and our company’s HR system or financial systems. Lists of customer account codes and staff members, which were used to populate pulldown lists and menus in Salesmetric, had to be inserted manually in Salesmetric. Sure, automated processes could have been generated to support these update activities but when you are a small consulting company there’s a limit to how much effort you want to put into systems integration like this.
Despite these issues I was pretty pleased with the arrangement, even though the system was not 100% the way I would have liked it. My core function, after all, is not sales tracking and prospecting, it’s consulting. Adjusting to others folks’ idea of “best practices” as expressed in a vendor’s standard offering seemed in this case to to be a very reasonable thing to do.
What Was Learned
Keep in mind this experience was based on a couple of dozen consultants using the system, many of whom had had little sales training but who were comfortable using automated systems.
INTEGRATION. Think about whether you absolutely need to combine (or exchange data with) lead and sales tracking with time reporting, HR, accounting, or other systems. In our case we had to implement some manual workarounds due to the lack of integration (e.g., manually updating things like individual company account numbers), but that was not too big a big deal. It might have been had we been managing a sales force measuring hundreds of people, however.
REPORTING. Some of us were real “dweebs” when it came to report generation and would never be satisfied with somebody else’s “canned” reports. In general, the reports from Salesmetric were decent and could easily be generated using the standard product’ standard features. Report generating scripts could be classified as “public” (available to all users) or “private” (available only to the author). In general, that seemed to work for us — but we did continue to build a separate set of reports around the daily download to our own server and our own Access database.
FUNCTIONALITY. Being able to track sales prospects and communications with them by a multiple people who are constantly traveling makes for a powerful tool. Perhaps a true “sales professional” would feel differently, but I was fairly pleased, especially with the built in task-dating features. My main advice here would be, when considering this type of tool, think in terms of the variety of roles of people who will be using the system, and work through the details in advance of how the system will look to them. Obvious roles include individual sales people, managers overseeing the activities of multiple people, people with responsibility for selling into/delivering services to different industries, and system administrators. And since in a small company the same individual may wear multiple hats and perform multiple functions, take that into account as well, i.e., how easy is it for someone to move from being viewed by the system as an individual user to being viewed by the system as an administrator or a group manager.
DATA MODEL. This topic tends to get a bit esoteric but we did not find out until we had been using the system for some time that there were just certain things the basic system could not do simply because of some of the underlying data structures embodied in the various tables on which the core database was built. Most of the time this caused no problem, but we found it an issue, for example, when we could not easily switch back and forth between different management and reporting perspectives, especially when we had to view data and events sorted by “industry” and by “campaign.” Was this a big deal? Maybe not, but every time an exception to the standard data model was introduced, this added an overhead of development and maintenance time.
PRICING. We paid on a “per user” basis. We also paid for storing documents on the vendor’s own servers. We were constantly deleting or rolling back documents being stored in order to cut down on storage fees. Had there been a simpler method to link into our own servers for document access, that might have been useful, but that is not something we ever explored.
STANDARDS. To use a shared system like this requires that people adhere to certain standards on updating their prospect records, keeping track of their phone calls, and generally, using the system in a consistent way. Do you, for example, record all the phone calls you make to an individual during the day, or only one? This is a “business process” issue that goes beyond whether or not you are using a hosted web based service, but you need to consider how you will encourage people to use the system consistently if you intend to do any kind of statistical tracking or analysis. We convened many conference call to discuss process issues like this but consistently a few individuals, God bless them, would insist on doing things their own way. Sigh.
Thinking back over our use of the Salesmetric system, I am pleased with the sophistication of the product and its flexibility. Yes, there were some glitches in data structures and flexibility, and we did build and maintain a separate database and reporting service separate from it, but I would recommend it to others where a hosted service make sense.
About the Author
Dennis D. McDonald, Ph.D. is a management consultant who lives in Alexandria, Virginia. He has experience in research and project management associated with system development, process improvement, customer relationship management, electronic publishing, intellectual property management, and strategic planning. For a short bio, go here.