sfNet:

new

approach

for

Territory

Management
SfNet proposes a different approach to the implementation of CRM software for the Pharmaceutical Industry. Typically, other vendors are using a one-size-fit-all model, offering the same product for different industries like, for example, Traditional Trade and the Pharmaceutical Industry. This strategy forces the usage of concepts like Accounts, Contacts, Opportunities, or other base concepts that are not always fully compatible to the sales representatives attending the typical customers of a Laboratory. Instead, SfNet offers a new set of Foundation Objects to work with, allowing a much more prescriptive approach in the modeling of a Pharmaceutical Marketing operation. The Foundation Objects are described below: Properties definition The first important Object to identify is the Properties: instead of defining a fixed field structure for the different entities in SfNet, the Properties definition let the Administrator define during the Setup phase of the implementation the actual structure of a particular entity type. The functionality highly exceeds the typical model of the custom fields: the Administrator describes each field with its label and data type, grouping them under similar concepts called Property Groups. In this way, when the application (both the Web Interface and the PDA Interface) needs to show the entity information, it will render the screen according to the definition of it fields. In the objects described below, the Properties will be used intensively.

Customer Type & Customers To provide the Administrator with the necessary level of abstraction to design the marketing operation, the first thing to do is to create the type of Customers that will be managed inside SfNet. This definition is made during the Setup phase, not only defining the Customer types, but also describing the fields (Properties) they will present in the User Interface. For example, a basic setup of SfNet will include the definition of Customer types like: Physicians, Patients, Hospitals, Drugstores, etc. Each one of these types will have an own definition of its Properties: the Physician can have First name, Last name, Identifications, Specialty, Address, Category, etc; the Hospital can be defined with Properties like Name, Address, Contacts (multiple), number of beds, etc. Extending the example, the Administrator will have the flexibility to define the rest of the Customer types structure needed. Once SfNet is deployed and the users starts to operate the systems, each actual customer of a type will be browsed and used as it was defined in Setup time: the Physicians module will present a grid list showing the selected Properties for Preview, and editing one of them will open a screen showing the defined Properties.

Relation Types, Relations & Relation Groups Once the Customers are defined, the next step for the Setup of SfNet is to describe the Relations among them. The Relation is used to extend the definition of a particular Customer type, and describe the relationship it has with other Customer types. For example, if the Administrator defines the Physicians and Hospitals

customer types, its necessary to create a Relation type call Works in to identify the fact that a particular Physician A works in Hospital B.

During Setup phase, the Administrator will define all the necessary Relation types, defining which Customer types can be nodes of the Relation, and also defining the Relation type with its own set of Properties. In the example above, the Relation type Works in will have some properties to describe the practices of the Physician A at the Hospital B: days and hours of attention, specialty in the Hospital, etc. The combination of Customers and Relations let the Administrator describe the base of customers on a more realistic approach, not being tight to a rigid structure. To provide a better way of managing the Customers and Relations, SfNet provides another Foundation Object: Relation Groups. Once defined, the users will have access to their Customers and Relations through the Relation Groups they have privileges, allowing the possibility of segmenting the database in minor portions.

Agent Types, Agents & Hierarchy The next step during the Setup phase of SfNet is to define the Agent types that will use the application. The Agents are the final users of SfNet, but to allow the necessary level of security and accessibility limitations for the different type of users, is necessary to describe the levels of the Organization Chart as Agent Types. Also, SfNet provides a module to define the Hierarchy between the different Agent Types, ending up with a real Organization Chart that will be used to allow the proper operations to each user according to the security settings. For example, the Agent types can be Product Manager, District Manager, Supervisor, Sales rep, etc.

Once the Agent types are defined, and the actual Agents are entered into the database, is necessary to assign which Relation Groups will have access. For example, the Sales Rep Agent B will be assigned to the Relation Groups he will have access, containing the different Customers (Physicians, Hospitals, Drugstores, etc) he will interact with during his daily work.

Interaction Types & Interactions In line with the model presented above, an Interaction can be defined as the concrete action executed by an Agent and one (or more) of its customers. For example, an Interaction can be a visit to a physician, an order put by an account, a participation on an event, an inventory track in a drugstore, etc. Divided by Interaction types, during the Setup the Administrator will create different Interaction types, according to the marketing activities executed by the different Agents. Also, one Interaction type has its own Properties set, and a group of business rules to accommodate the functionality: which Agent types can execute the Interaction, which Customers types can participate in the interaction type, etc.

Other modules Several modules were designed to support the model explained above: Filter Engine: powerful tool to search among the different entities and their properties. Territories: logical groups of Customers & Relations, different from the operational concept of Relation Groups, useful to analyze statistical information from diverse angles. Re-alignment: flexible module to reallocate the sales force to different territories. Timeline: configuration of different sales cycles per business unit, to allow better measurement of performance indicators.

Interaction Plan: projected number of Interaction types (visits, orders, etc) per user or business unit, with support for Interaction script (Product Plan, etc)

Activity reports: tool for reporting and analyzing activities besides marketing actions (trips, team meetings, etc).

Conclusion In summary, identifying and defining the different Customers and Relations, grouping them in Relation Groups, laying out the different Agent types that will participate, assigning the Groups to the particular Agents and segmenting the marketing activities of the sales team into individual Interaction types will end in a detailed and deep understanding of the whole ecosystem of the Companys Marketing management, allowing to measure and project the effort. This approach will present a strong grip not only for the operational tasks but also showing new metrics to measure performance and planning sales target.