A question about how best to structure our SharePoint solution. As a consulting company, we deliver pieces of work to a large number of clients. For each client, we generate documents related to the sales and contracting process, and then for delivery and follow-up of our services. For some clients, the documents are mostly ad-hoc, and not very numerous. For other clients, we deliver comprehensive projects, and so generate a larger amount of documentation and data related to each project. There are likely to be more than 1000 clients.
In our current SharePoint design, we store documents related to clients in two places:
A Library called “Clients”, where we add all ad-hoc type client-related documents. Here we tag each document according to client and service/product line.
A set of Project sites, where we create a new Project site for each client project that we initiate. All documents related to the project get stored in a documents library in the client site.
This means that for the same client, we often end up with documents stored in the “Clients” library and in one or more Project sites. We suspect that this is not an ideal storage architecture for our client data. We could have stored all client data in the single “Clients” library, but then we would lose the ability to easily locate all documents that belong to the same project or piece of work.
On an old-school shared network drive one way to achieve a more integrated client storage functionality would have been to have a set of client folders listed alphabetically, and then within each client folder store projects and ad-hoc client documents. But that approach of course means losing the more flexible tagging-based functionality that SharePoint provides.
What is the current best practice storage approach/architecture for organisations that face this type of challenge?
