You can please some of the bosses all of the time and all of the bosses some of the time but you cant please a managing director....
OK, this CRM thing doesnt look too hard. All we have to do is install it, right? Wrong. The problem with Dynamics is that it is almost infinitely configurable. To a techy, that's just plain cool, but from a business viewpoint in a multi-tenanted environment, it's a recipe for disaster. I mean, can you imagine all the permutations of all the customers busily customising the CRM interface with no documentations...urgh! How to support this, how to document it? The mind begins to boggle. The answer is of course to lock the users out of the settings tab and only allow customisations that have been requested and approved with a sign-off procedure. But that isn't the end of the problems.
How to sell a multi-tenanted environment in the first place. I'm not talking about the glossy sales and marketing brochures, I am of course referring to the real implementation planning, the discovery meetings to determine what the customer wants, the explorations of their own business processes and then...of course, there's the data. Most businesses are really messy when it comes to data. Some is in Excel and if you're lucky, some is in an access database. How to import all of this? The rabbit hole goes deeper of course. You can happily import data from almost any source by converting it into a CSV file, but how do you import the data in the heads of users. All of the myriad different ways of doing things within the business, the customer contacts that are never written down, the special contact numbers one learns to use when calling customers in order to bypass the telephone robot etc.
So. I decided to write a document. It's the only thing management really understand anyway. Here it is reproduced below.
Q1. What is the structure of the client company
Assuming that the client approaches SomeCompany Ltd in order to provision their CRM and host it, SomeCompany Ltd would be advised to engage the customer in an initial planning and discovery meeting. The purpose of this discovery meeting is to establish a business model for the client company that can then be represented by the CRM. No two companies are alike although they must necessarily maintain many common business processes in order to function in an accepted way. Most companies therefore, will employ a top-down business model with a CEO or Managing Director in overall charge, various directors of their respective spheres will report to him. Most companies will have a department devoted to Sales, another to Customer Contact, another to Service and perhaps one for Marketing although this is often amalgamated with the Sales department since that department will require marketing materials in the form of documents, brochures etc. Finally, there is the Production department who will draw information from all three higher level departments. The needs of the Production department must be taken into account since in order to fulfil their jobs and ultimately make money for the company, they must have the information to hand, organised in an easy and efficient way. The structure of the company is therefore very important to the way that the CRM is provisioned and although at first glance, the structure of a company would seem to be self-evident or worse simply ignored, it is in-fact pivotal to the correct operation of the CRM and the design of the workflow methods and rules.
In short, Microsoft CRM can be viewed as more than simply a database or a product, it is really a way to manage the business and as well as the CRM being customised to suit the business, there are instances where the business would do well to customise itself to suit the CRM. This can be evidenced by stringent workflow methods. A company may be used to doing something one way, but perhaps the CRM has scope to improve the efficiency of that same business process if only that process were regulated by the CRM.
Further to the structure of the company, the organisation of the company should also be examined. This will assist the deployment team with the task of assigning security roles and customising the user interface to suit. For instance, the CEO of the company may require super-user permissions or more pertinently, only require an extremely streamlined overview of the day to day business. The CEO is often engaged in other business and therefore the day to day business decisions are left to the managers who would require extreme access.
Q2. How many users require access to the CRM
The number of proposed users accessing the CRM and their types are critical to the correct deployment scenario. There may be 50 employees in a client company, only 25 of which require read/write access. Those in the service department may only require ‘read-only’ access, especially if the information they require is presented in an efficient manner. Further, users in the Service department would not necessarily require full and unfettered access to information stored by the Sales department, such as quotes. The client company should be urged to think very carefully about who should have access to which information and for what reason.
This type of forward planning and examination my assist the client company in keeping the cost of CRM implementation to a minimum or at least within the realms of reality. The client company may well be urged to complete a ‘user survey’ questionnaire prior to commencement of the project. This document could form part of the deployment rollout procedure since such documents will be regulated by ISO requirements and tracking. This document should also incorporate the proposed security role assignments. This information may be discussed with the client in more depth at a later time, but still the project should not proceed without a completed ‘sign-off’ of this stage. Simply rushing into a deployment without considering all aspects of it could lead to additional work and cost in future as efforts are made to rectify mistakes.
Q3. What existing data is held by the company
The corollary to this question should also be, ‘and in what format’ since this is also critical to an efficient deployment. Many companies are very untidy with their data. Some information is held within bespoke databases, some in excel spreadsheets, some in the minds of the employees. This is where the real wealth of the company resides. Employees carry vast amounts of information regarding business processes, methods, protocols and customer networking. All of this information is required by the business in order to run and in some cases, people are literally indispensable due to their knowledge of the business. The client should be urged to review all sources of information. Information can be imported into the CRM but in order to function effectively, that information needs to be associated with other pieces of information. Therefore, it is no good simply having a list of names and addresses if there is no other relevant information such as the place within the business role. Are they customers, suppliers, vendors or just contacts. The client should be presented with an ‘audit’ form in order to record such information. Better yet, the client should be educated with the skills to extract their own information and present it in a manner that is ready for incorporation into the CRM. In order to present to the client, a clear plan of integration, the deployment team must understand some of the business processes, i.e, how this information relates to other pieces of information, the way that the information is stored and the purpose of storing that particular piece of information. This will play a large part in the way that the data is bound together for retrieval.
Further, the client may routinely record a piece of information for which there is no logical place within the CRM. In this case, a new entity will be required and this would mean a significant alteration to the original installation. In this case, it is proposed that a document be employed which will record this alteration, the purpose of that alteration, the risk assessment, the final sign-off etc. All such departures from the standard installation should be carefully documented in order to help support personnel in the future. The permutations of many customers being able to apply undocumented structural alterations to the CRM are truly frightening. Over time, this scenario would become unmanageable and un-supportable. It is proposed that the ‘Settings’ bar be disabled by default in any new deployment and that any and all structural alterations to the CRM should adhere to a strict ‘change request’ protocol.
Q4 What does the client envisage the CRM doing for them
This is perhaps the most pertinent question that should be the first point of discussion at the discovery meeting as the answer will dictate the entire design of the deployment scenario. Another question that could be asked is “what is the main purpose of the CRM in relation to the client business”. There are essentially 4 main modules to the CRM and those modules can be used as stand alone entities or in combination. Crudely, they are :
-
Sales
-
Marketing
-
Customer Contact
-
Service and Scheduling
If the client simply envisages using the Sales and possibly the Marketing capabilities of the CRM, then existing business processes should be taken into account. The CRM is capable of managing Bulk Email, Mailmerge, Sales documentation and much more. The Customer Contact capabilities are extensive and procedures to handle telephone calls, emails, letters etc will need to be designed to meet client requirements both existing and planned. The service and scheduling capabilities are incorporated within the Client for Outlook and both the CRM and the Outlook Client are mutually updating. The CRMs’ main point of entry is the Customer Contact database which holds information for both existing customers, prospects, contacts, competitors and vendors. Therefore, the Customer Contact module is pivotal to the overall design and should be carefully considered from all aspects. The method by which the client acquires contacts that will become prospects and ultimately customers is also pertinent to this discussion.
Q5. What information does the client wish to retrieve from the CRM
This is not just a discussion of reports and pivot tables, this is also a philosophical question that will also dictate the design of the CRM interface. The information retrieved will dictate the business processes in the marketing and sales modules assuming the client wishes to avail themselves of those capabilities. Does the client simply require a dry list of facts and figures, or something a little richer. Does the client use a list of contacts as a basis for cold calling, or will they require the design of a new HTML bulk email template. How are reports used by management to dictate the day to day activities in the Sales, Marketing and resource management departments. In order to answer this question, the client should be encouraged to consult with managers within their enterprise in order to draw on the experience of those people. Further, integrations of this short are always easier if the people being required to use the software have had a hand in designing it and it has been tailored to suit their specific job requirements. An examination of the existing report structure and process would also be helpful at this stage. After all of the design requirements have been examined, a procedure should commence that begins with the detailed documentation of such requirements, the draft design, and the proposed timescales. This should be followed by another ‘sign-off’ milestone.
Q6. What information is available to users at the moment such as scripts, documents, company info and written procedures.
The CRM has the capability to store more than just the cold data of names and addresses. The workflow capabilities can be leveraged to incorporate existing client business documentation which can be read, authored or appended to outgoing correspondence. The customer contact department may wish to use a specific script scenario for cold calling, the Sales and Marketing departments may wish to have company brochures on hand to send by email to customers, the service department may require specific answers to common questions etc. All of this information can be incorporated into the CRM, but it is necessary to know exactly how the client wishes to use this information. The client should be encouraged to review all such documentation and provide examples of these in the first instance (preferably in an electronic format). Further, the client should be advised to examine the accompanying business processes to determine the customer contact points and how best the documentation and information can be used to assist those customers and their own employees.
Post Deployment Considerations
It should be noted that the CRM is of sufficient complexity that it is not immediately obvious how best to utilise it to serve a specific purpose. Many of the preceding questions and discussions will serve to assist in clarifying this, but still, users will require some form of training on the CRM before commercial implementation and ‘go-live’. The client should carefully consider how many of the users require such training, how many can be quickly promoted to trainer level with just a cursory explanation and examination of the CRM. There is a user manual available from www.redware.com but this alone will not provide sufficient insight into the workings of the CRM. The client should consider the possibility of an independently tailored and authored technical manual. Whether this is produced ‘in-house’ at the client premises or as part of the service SomeCompany Ltd offer, is a matter for further discussion and is outside the scope of this document.
The client and the deployment team in conjunction will also need to identify the business impact of deployment and areas of potential disruption to the existing business procedures.
Careful thought should also be given to preparing and planning for modifications to the CRM to compliment the evolution of the client business.
