Is customer relationship management (CRM) shortsighted? For example, I missed a connecting flight with a major airline and proceeded to customer service. While waiting an hour in the customer service line (there were four people in front of me), I heard the customer service representative have a commiserating chat with her co-worker about how she resented working mandatory overtime. By the time I reached the counter, following my long wait in line, there were no more flights available that evening; therefore, the CSR booked me on a flight the next morning and sent me to the hotel shuttle bus without ever looking up from her reservation system. Sharing the bus ride to the hotel, the other customers and I were amazed at the lack of customer care, poor service and ineffectiveness of the customer service representative.
Ironically, I participated as a consultant in a large CRM initiative for this airline; and their goal was to treat each customer with great care, dignity and service. However, throughout the organization, there was much less emphasis on relationships with their employees, partners and suppliers. How is it possible to build strong customer relationships without healthy relationships between the people that provide the service or product to the customer? When I commented to the customer service representative that it appeared as though the airline didn't treat its employees very well, she replied, "Oh, they are awful to me." It is possible that perhaps I did not receive good customer service because she was not treated well as an employee.
If all relationships are important, wouldn't it be wiser to focus on relationship management (RM) instead of just CRM?
Are customer relationships more important than employee relationships, supplier relationships and/or partner relationships? After all, "the customer is always right." Additionally, in tough economic times, if you don't have enough customers, you could go out of business. Therefore, how can you not focus on getting customers?
While I believe that any viable business focuses on its customers, I contend that all relationships are important. To have too much emphasis on customer relationships without also focusing on employee, partner, supplier and other relationships is narrow-minded. If there is a reason for the relationship in the business chain, you must honor it. If you don't have motivated employees (including yourself, if you are a sole proprietor), you will eventually be out of business. Your suppliers and/or partners, who contribute to your service or product offering, will ultimately affect the quality of your offering as well as customer satisfaction. Perhaps we should broaden our focus and practice RM instead of CRM.
Relationship Management or Relationship Development?
To further expand the term CRM, let's consider the meaning of the word management. According to Webster's dictionary, manage means: 1) To control the movement or behavior of; 2) To have charge of; direct. Using the same dictionary, develop means: To make fuller, bigger, better, etc.
Therefore, customer relationship management means controlling the movement or behavior of your customers. Anyone experienced in customer relations realizes that while one can perhaps influence customer behavior, controlling customer behavior is a flawed strategy (as it may be with other relationships as well).
Relationship development means making your relationships fuller, bigger and better. Depending on your intent, you may want to re-evaluate what it is that you are attempting to do and then call it by a name that conveys its meaning. My goal is to develop rich relationships. Therefore, I prefer to think about (and act upon) relationship development.
A Universal Data Model for Relationship Development
There are universal principles that govern relationship development. For example: What goes around, comes around. Similarly, there are "universal" truths regarding the nature of data within relationship development. For example, people and organizations may play many roles over time or at the same time, and they may play them within multiple relationships.
Universal data models exist for relationship development. If we can first understand the true nature of data within relationships, we can build much more flexible, maintainable and effective databases that track information to help enhance relationships.
Figure 1 provides a universal data model for relationship development. The most significant entities in relationship development and in this model are PARTY, PARTY ROLE, PARTY RELATIONSHIP and EVENT.
Large Image: Click here to view in a new window.
Figure 1: A Universal Data Model for Relationship Development
The PARTY entity maintains information about the PERSON or ORGANIZATION such as name, Social Security number and demographics independent of the role(s) that the person plays.
The PARTY ROLE entity maintains information associated with each role that a PERSON or ORGANIZATION plays, thus providing a more complete profile of each party by identifying all the roles played by each party. Thus, if a person is both an END-USER CUSTOMER and a CONTRACTOR (as I was in the airline example), then it is possible to see a more complete profile of the involved party. In many enterprises, employees purchase products from the enterprise and are not recognized with any special consideration, which could be frustrating. (For example, people can play the role of EMPLOYEE and BILL-TO CUSTOMER at the same time.) Similarly, when evaluating vendor proposals, it may be important to know if one of the organizations that is a SUPPLIER also plays a role as a CUSTOMER, even if it is in another division of the enterprise.
While the PARTY and PARTY ROLE entities maintain information about a single person or organization, the PARTY RELATIONSHIP entity maintains information about two parties within the context of their relationship. This data structure provides the capability to view an integrated profile of all the relationships in which a party is involved. For example, knowing that an organization has a PARTNERSHIP relationship with a part of the enterprise may be important to know when forming an ORG-CUSTOMER RELATIONSHIP (customer relationship between organizations) with another part of the enterprise. Other information related to PARTY RELATIONSHIP is the RELATIONSHIP STATUS (active, inactive, dead, etc.) and the PRIORITY TYPE (high, medium or low).
The EVENT maintains information about any activities, which may occur within the context of relationships. Events may be COMMUNICATION EVENTS such as phone calls, meetings and other contact events, as well as TRANSACTION EVENTS such as orders, shipments, payments and other business transactions. The EVENT ROLE maintains the type of role that each party plays in the event.
Distinguishing Between Party, Party Role and Party Relationship
In order to provide meaningful relationship information, it is essential to distinguish which information should be stored with the PARTY, which information is associated with the PARTY ROLE and which information is associated with the PARTY RELATIONSHIP.
For example, many CRM packages do not distinguish between these entities and simply maintain a CONTACT table with fields such as the first name, last name, title, address, status and priority, and a NOTES table to maintain narrative comments about conversations and/or meetings that took place. This seems adequate until data issues arise. For example, a sales representative may record the priority of his contact (John Smith) as "high" because John buys a great deal of products from him. Another salesperson may sell training to John Smith and override the priority field with a "low" priority because it is unlikely John will purchase much training in the future.
The problem with only having CONTACT and NOTES tables is that the priority field does not belong in the CONTACT table. It is information that is associated with the relationship. In the previous example, each salesperson has a unique relationship and should be able to update the priority of his/her own relationship with John Smith.
It is amazing that many CRM systems are missing the most important entity (or table) for maintaining information about relationships the RELATIONSHIP table! Many CRM vendors will just say that each person can enter his/her own contacts. The problem with this is that then John Smith's name, address, phone number and other information are redundantly entered. Thus, it is important to appropriately associate personal and organizational information with one of the following:
PARTY: Information about the person or organization independent of role. For example, the information about a PERSON may include current first name "John," current last name "Smith" and Social Security number 111-22-3333. This information is independent of any role that "John Smith" plays; and regardless of whether John Smith is a customer, a contact or an employee, the information will be the same. The point is to maintain this information only once at the PARTY level and then associate the party to various roles.
PARTY ROLE: Information about the party that is associated with a role. For example, the data model shows an attribute of "current credit limit amt." This attribute is not about the party (John Smith); it is about John Smith in his role as a BILL- TO CUSTOMER.
PARTY RELATIONSHIP: Information about two parties and their relationship. For example, the PRIORITY TYPE is related to the PARTY RELATIONSHIP, allowing each relationship to establish its own priority. John Smith may have two customer relationships, each with a different priority: one for the relationship that John Smith has with the product salesperson and another for the relationship that John Smith has with the training salesperson.
With these distinctions in mind, where would one put the status of John Smith? It depends on what is meant by the status. If the status refers to the status of the relationship between John Smith and the product salesperson (i.e., thriving relationship, extremely active, not engaged, inactive, etc.), then it should be associated with the PARTY RELATIONSHIP. If it refers to his status as a BILL-TO CUSTOMER (i.e., preferred, active, delinquent, etc.) then this status should be related to PARTY ROLE. If the status relates to the personal condition of John Smith and is independent of any roles or relationships (i.e., dead, alive, ill, etc.), then it should be directly related to the PARTY. If all these statuses are needed, then there could be subtypes of STATUS TYPE for PARTY RELATIONSHIP STATUS TYPE, PARTY ROLE STATUS TYPE and PARTY STATUS TYPE. The point is that with these three distinctive types of entities, we can make much more intelligent choices about how and where to maintain person and organization information.
One of the most important aspects of relationship development is tracking the communication and transaction events that occur within the context of each relationship. If these are favorable for both parties, the relationship will flourish. A relationship development database can assist by maintaining the details of these communications and transactions so that important events (past and future) are easily accessible.
The data model shows that each PARTY RELATIONSHIP may be the context for any number of EVENTS. EVENTS may be either COMMUNICATION EVENTS that represent interactions within the relationship or TRANSACTION EVENTS that represent recordings of business exchanges that took place. TRANSACTION EVENTS include commitments (COMMITMENT TRANSACTIONS) or fulfillment of those commitments (FULFILLMENT TRANSACTIONS) and OTHER TRANSACTION EVENTS. A good deal of the activity within a relationship involves communications between people as they make commitments (in business this may represent setting up deals) and fulfill (or don't fulfill) those commitments.
COMMUNICATION EVENTS maintain mail and paperwork that has been exchanged (CORRESPONDENCE); phone, fax, teleconferencing or other TELECOMMUNICATIONS; e-mail, chat, FTP or other INTERNET COMMUNICATIONS; meetings, personnel reviews, lunches or other IN- PERSON COMMUNICATIONS; and any other type of interactions where communications take place (OTHER COMMUNICATION EVENTS).
By tracking key communication events along with their start dates/times ("from datetime"), completion dates/times ("end datetime") and accompanying narratives (notes), a complete picture of the relationship communications can be maintained and accessed.
TRANSACTION EVENTS maintain COMMITMENT TRANSACTIONS including reservations, sales orders, work orders, service orders, statements of work, agreements, contracts, invoices and any other transaction recording an obligation from one party to another; FULFILLMENT TRANSACTIONS including shipments, work effort fulfillment, payments and any other transaction recording fulfilling obligations; and OTHER TRANSACTION EVENTS such as proactive projects, market research, infrastructure setup and other transactions not involving commitments or fulfillment of those commitments.
Each EVENT may have many EVENT ROLES that maintain the various PARTIES involved and ROLE TYPES that each party plays in the event. For example, in a COMMUNICATION EVENT of a phone call, "John Smith" may have played the ROLE TYPE of "receiver," "Mack Deals" may have played the role of "caller" and "Jerry Rite" could have played the role of "data entry person." Thus, the data model is very flexible and accommodates for any number of people that may be involved in any capacity within any event of the enterprise. EVENTS may have an EVENT STATUS TYPE maintaining the status of the event (i.e., scheduled, pending, in progress or completed).
While the heart of relationship development centers around some of the entities covered in this article, there are many more universal data model constructs associated with relationship development that have not been covered specifically in this article. For example, a relationship development model could also include entities to maintain party contact mechanisms (the actual phone numbers, fax numbers, e-mails and other ways of contacting parties), party classifications, geographical information, communication event follow-up, call center management and case management. Also keep in mind that these universal data models offer reusable constructs to be applied and customized as appropriate, and they are not a substitute for proper information requirement analysis. For more details about additional universal data models for relationship development and other common subject data areas, please refer to my book The Data Model Resource Book, Volume 1 (Wiley, 2001).
While tracking customer relationships is critical, why not expand the vision of CRM to include the tracking of all relationships? Customers will only be appropriately served if the people taking care of them are also well treated. If we are concerned with CRM, be careful to also consider employee relationship management, partner relationship management, supplier relationship management and, ultimately, management of all types of relationships. Furthermore, it seems that focusing on relationship development (RD) would be more effective than relationship management.
The data structures for maintaining information on these various types of relationships are very similar; they each involve tracking the people, organizations, roles, effective dates, statuses, priorities and events associated with the relationship. The universal data model can consistently and effectively handle capturing the information needs for all relationship development while providing a broader, more complete view of the people and organizations and their associated roles, relationships and events.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access