Don't treat your software like a database
It's easy to think that CRM systems are "just a database," since they hold parametric and text data and handle it more or less transactionally. While parametric CRM data is the core of many a report and dashboard, it's actually not the most important data about the evolving customer relationship. Because parametric data represents only the current state of play, to understand the history means following the sequence of changes in audit trails: quite difficult, and less than enlightening.
The juicier data about the customer relationship, both in marketing automation and traditional CRM systems, is in a sequence of records that are mostly text and are more like a journal than a transactional history. The simplest of these records is a free-form notes record, which is almost invariably entered manually. Notes records track the author, time of creation, time of update, access privileges, a subject line, and a free-form text field. Notes are typically attached to main CRM records (such as lead/contact, account, deal, order, contract, or case). While notes are easy to use, lack of parametric data makes these text records almost impossible to report on. Even so, it's way better for users to put running commentary in notes than in the main record's comments or description field because the notes will be smaller, less likely to be erased, and can be easily sorted by chronology, topic, or author to provide a low-grade thread view of long conversations.
The next level of text-based relationship tracking is the task, meeting, event, or activity record. While each CRM system implements the details differently, these activity records provide more parametric data and structure to a free-form text field. Like notes, these records can be attached to nearly any main CRM object, anything that might require action. Activity records are used to initiate and track pending action items and to record the results of meetings or events. Typically, activity records include fields such as type, priority, status, due date, participants, notification parameters, and pointers to the people or entities to which they relate. Activity records may support document attachments, but it is typically not a good idea to use attachments here, as they can be easily missed by users, effectively buried in the system's object tree. Activity records are typically extensible with a few custom fields and are accessible via the system API. They are rich enough to support simple workflows (e.g., task started, task handed off, task completed), and are sometimes used by applications to record activities or state changes. Consequently, activity records are frequently used for reports, dashboards, and triggers for alerts or workflows.
While activity records are a powerful (and typically underused) functionality, they have limitations. The main actors in activities must be system users, so recording customer initiated actions in an activity is counterintuitive. In a latter-day version of reverse polish notation, recording a customer action as an activity looks like this: "UserName noted CustomerName action." Further, activities are typically one actor and one or two participants, which means that recording group actions is clumsy. When a large group of participants each responds on their own schedule, recording each of these responses as an activity can become ridiculous.
Next Page: Campaigns
Campaigns are a relatively recent development, designed to resolve the limitations of activities and serve as the focal point for the marketing features of CRM systems. Campaigns are also poorly appreciated and frequently underutilised. Campaign records are highly structured and can hold dozens of parameters, and the tables are fully extensible. But their real power comes from the number of objects that point to campaigns, the number of objects campaigns point to, and its related table (called campaign members in Salesforce.com, but the table name varies by CRM/marketing automation system vendor). For each campaign, the campaign members table shows all the participants (leads or contacts), their current status, and their membership join or update date. This collection of information lets you understand things like:
* How many times have we touched a lead?
* What are each of the activities they participated in?
* What items did they download?
* Which topics did they receive e-mail blasts about?
* What e-mail messages did they open? Respond to?
* When were they sent their renewal notice?
While the Campaign record doesn't do all this for you automatically, it is the most logical place to store all these data (typically from outside systems such as e-mail blasters, website, advertising engine, etc.). While you could put all this information into a long series of activities, the data would not be well structured for viewing, reporting, or dashboards. When evaluating external applications, look for how deeply and tightly they integrate with the CRM system's campaign records.
In addition to a rich data structure, campaigns typically have a lot of business logic to support pipeline and marketing impact analysis. The system may tabulate the number of responses, new contact conversions, new sales opportunities, and the pipeline value for each campaign. While there are a lot of assumptions behind these calculations and the numbers are often wildly misinterpreted, they are a powerful tool for understanding and optimising marketing spend.
The Right Tool for the Job
Understanding the state of play in the evolving customer relationship means a lot more than just parametric data. CRM systems need to have ways of showing the sequence of interactions and events over time. Each of the records described above has an important role and provides a better alternative than what the naïve user tends to use:
* Notes records are way better than comments fields for documenting conversations and discoveries
* Activity records are way better than notes for documenting meetings, calls, e-mails, and action items
* Campaign records are way better than activities (or the deadly lead source field) for documenting group outreach, calls to action, and customer responses to offers
Use the wrong one for your particular information, and you'll end up with almost no reporting or analytical perspective on the customer interaction. Sometimes, you won't even be able to find what you entered later. So it really pays to stop using the wrong type of record, and remarshal your data so you can use the right tool for the job.