Inevitably the question arises at some point about how the users of Microsoft CRM can store large amounts of documents efficiently and properly structured so that users can access them quickly.
Chances are if you are thinking about implementing CRM and have the overall idea of "all customer information in one place" then you might be wondering as well how this is accomplished and be puzzled with the idea.
Microsoft CRM is great for tracking all lines of communication in and outside of your business. Everything involving sales force automation, service automation and specific customer information tracking is where Microsoft CRM really shines.
The problem
Microsoft CRM employs a method of file storage that's design is Account or Entity specific storage. This can make finding particular information that is structured, such as opportunities that have definable associations, really easy in CRM.
For example if you have renewals that are stored for customers you could easily create a new entity named renewals and enter them in future in CRM to track them. This is generally Entity specific and has a link back to the main Account it is entered against.
Traditional networks don't employ customer specific storage
The problem comes with unstructured storage on the network that you are implementing on. One example that i ran into recently was a customer that had hundreds of spreadsheets that they have kept that pertained to a specific customer over the past 10 years.
Can you imagine trying to add all of these documents and creating entities for each document type so that they can be stored in CRM and revision controlled? This would get out of hand really quickly and you would find that the user interface would become complex; it would be hard to understand what information is stored at which location. This is the worst of all possible dangers in a CRM implementation as you must keep it simple and build from the foundation you have laid to layer on functionality.
A solution for structured and unstructured storage
The solution is to segment what should and shouldn't actually be stored in CRM.
But the truth is by segmenting your storage types you define what information is feasible to actually store in CRM, and what information should be "linked" or "surfaced" to CRM. The end user experience is the same and the user gets the impression that everything lives in CRM when that isn't the case.
But back to file storage, and how do I solve this problem?
This is simple... use a product that was designed specifically for file storage. One that employs smart storage for revision controlled documents and provides file and content indexing such as Microsoft SharePoint. Microsoft SharePoint and Microsoft CRM are both .NET based applications and work extremely well together in this solution.
In my previous example a solution was to simply display SharePoint data when users clicked on the accounts entity in CRM. The user had a new tab in CRM called Network Files that directly surfaced the information for that customer from SharePoint. This brings home the complete idea that surfacing information from other systems is truly the key to "all information in one place".
The interface for CRM is great' it's accessible from outlook or the web and provides a way to surface just about anything you can imagine to the end users of your CRM implementation. This is one of the primary ways to build a quick-win in your organization for a CRM effort. Give users access to data that was before hard to find or involved many systems and bring them together through the use of CRM.
Nicholas Cole - ,
