In our last article, we took up the fact that one type of CRM administrator acts as an architect of the CRM for the company. We’re going to now go into detail with the concepts this person needs to deal with in properly setting up CRM.
Working Out Company Structure
As described in the last article, we have two different administrator roles—one being the regular administrator and one being the architect administrator. One person might fulfill both roles or, in a larger company, two separate people might be required. In this article, we’re going to focus on the architect administrator’s role.
The first thing this architect-administrator has to work out is the company structure. How is it constructed? It could be based geographically—for instance, the company has divisions in Europe, America, and Asia. The company could also be divided into various business units, or perhaps by different product types or by type of industry. For example, Pipeliner is divided geographically between Europe, America, Asia, and Africa and is also divided between products and services.
If these divisions are not clearly laid out and understood from the beginning, it could make for CRM problems down the road. It will be the basis of what a user—regular or advanced–will be able to view and access.
We have a clear structure at Pipeliner. We have a program called Pipelinerpreneurs, in which people have their own businesses selling and using Pipeliner CRM. People in that program can only view certain data types within CRM—they don’t need access to everything to do their job and from a security point of view, we need to restrict some areas. We also have Advanced Pipelinerpreneurs, however, and they have more access and can view more data.
The company’s structure is critically important and will be the basis of how your CRM is set up. Every company is different, so there needs to be an architect administrator who fully understands their company’s structure and can implement it within CRM.
Users and Roles
Once this company structure has been fully established, it is then used to define what the CRM users can view in terms of data and what access they have. With Pipeliner, you can add as many regular users as needed. They can be imported and exported—a feature not many CRMs offer. When a user has been created, their activities can be monitored. You can see if and when the user has used the system and what they did.
Beyond just the ordinary users, the administrator architect must define user roles. Roles are critical and are conceptually tied to the unit. A significant benefit of Pipeliner is that roles can be instantly changed within CRM when needed.
Within Pipeliner, you can also create “super-users.” This could become necessary in a larger company where, for example, you have more than one CRM administrator. These administrators would have specific functions such as consistently updating the company’s product or service catalog. They wouldn’t, however, be able to remove a user. There would be the “super-admin” who had overall authority and the final say.
Keeping It Simple
In thinking through the various units and roles, we see that the “architect” has been appropriately named. They are actually building a structure. If they’re constructing a large building, such as the tower in Dubai, they must dig deeper to construct the foundation. Or if it’s going to be a simple structure like a beach hut that sits on the sand it will be far simpler.
When creating the roles with CRM, the administrator must think through what this person is really going to need in terms of information. One serious flaw in traditional CRMs of the past was overloading the user with far too much data, way more than they needed. With Pipeliner, you can provide a role with only the information they really need, and no more.
Will the role need access to all features? Is this a power user? Do they need to import and export data? Do they need to be able to create automatic processes? (Note that only Pipeliner offers the capacity for a user to create an automatic process, to optimize workflows, with the Automatizer feature.)
If, for example, a person will only be responsible for contacts in accounts, they’re not going to require dashboards, advanced reports, or the Archive. Such information would only prove distracting. The more a person can remain focused, the more productive they are going to be.
Then, finally, what rights will a particular role need when it comes to the various entities within Pipeliner—accounts, contacts, leads, opportunities, pipelines, tasks, and appointments. Should they see only their own records or records of others? Should they have read-only access or reading and writing privileges? These same kinds of permissions would also be granted through the APIs when needed.
Before anything else, the user roles and the various units must be very well defined from a business perspective. Once these are fully understood, then properly setting Pipeliner up becomes painless, and you can proceed to a technical guide that will show you how users and roles are set up strictly from a technical aspect.
Comments