Segmentation of customers and prospects covers the discipline of dividing the bulk into various groups with similar characteristics and hence assumingly similar needs. This can be based on areas such as:
Businesses needs to do segmentation of their customers and prospects. The most common and most obvious need is seen within marketing, where segmentation is a key discipline to help select candidates for a specific outreach to be executed via best media e.g. via a marketing campaign. However, also sales and service may directly utilize segmentation for prioritization and process differentiation e.g. for “VIP customers” or “customer likely to churn”; and of course to help drive successful up-selling and cross-selling.
Data for segmentation can originate from many internal and external sources; just consider the above examples. Businesses may purchase segmented lists form providers like Bing/MSN, Google or Dun&Bradstreet. Businesses may analyze data available on internet or social networks. Businesses may analyze own data from data warehouses, ERP systems or web sites. Businesses not least may gather and maintain data in their CRM system.
Challenges are many. Are data reliable? Can data be aggregated and integrated? How to model “segments” across various domains? How to identify a customer across sources? Can and should segmentation be dynamic?
In this blog I focus only on the practical parts of gathering data in a CRM system…
There are two ways to directly do segmentation in Dynamics CRM:
Data for both needs to reside inside Dynamics CRM, i.e. there is no way to dynamically gather data from external sources. So both Dynamics CRM itself and 3rd party extensions for marketing such as ClickDimensions and ExactTarget must rely on records stored in Dynamics CRM for all stages of campaign planning, execution and not least tracking and handling of responses (convert to Lead, core CRM processes, report on ROMI, etc.).
Using Excel and using any visualization for data stored in Dynamics CRM and/or external stores may be great to analyze data for a segmentation process, but will not allow Dynamics CRM to execute a campaign on it. Processing in Excel or like, must “end” as a subset of data records to be imported into Dynamics CRM for execution as profile data and ultimately as Marketing Lists. You may argue that firing off emails could be done based on a more light base than full-fledged CRM records, while the it would be hard to utilize Dynamics CRM for a true closed-loop process with conversion, reporting, etc.
With many segmentation data sources being external to Dynamics CRM, we are often asked how to utilize external data with Dynamics CRM for segmentation.
I’ve seen three patterns in play, below outlined with most important pros/cons:
Works with dynamic Marketing Lists
1. Load all data into CRM:
Integrate to create new custom or system records based on ERP and other data, e.g. customer orders bulk loaded into Dynamics CRM
Single tool, by super-user
Simple for IT
Often huge and dynamic data set not fit for CRM
Tooling is limited by CRM queries
Fundamentally a bad pattern to load ERP data into a CRM system!
Partly, if direct relation exists
2. Aggregate segmentation into CRM Lead / Contact / Account:
An ETL-category (Extract Transform Load) solution to set flags or aggregated values in customer records e.g. flag if spending in a category is above a threshold, or update revenue and profit for last 6 months
Allows full use of CRM charts, reports etc. also beyond marketing
Segmentation limited to “some” dimensions that needs to be pre-determined
Changes requires IT config. of CRM and rework of “ETL” with deep business alignment
3. Load ready-made lists into CRM:
Use Excel, BI, or other tool to generate lists per segment based on data from ERP, CRM and other systems. Import these lists into Dynamics CRM
Any data, any logic, well almost anything is possible, just select right tool!
Different tooling for segmentation campaign execution
May be hard to loop back responses
Need to cater for redundant leads/contacts
In many situations the best option is a combination of two or all three patterns.
Also consider a hybrid of 1. and 2. with some attractive characteristics: Aggregate data and update into CRM as records of a related custom entity e.g. "Account KPIs". With this normalization the Account/Contact/Lead entities are kept more clean and smaller, also maintaining a more meaningful timestamp of last update; there no value for users seeing that a system account updated all accounts this morning at 2 am... (Yes, a direct update in CRM's SQL database may overcome this, but is neither supported, recommended, nor cloud-ready). With clever design of 1:N relation and data model selected Account/Contact/Lead forms may display these data directly as a SubGrid (as opposed to an iFrame with a tricky URL). As everything the design is a tradeoff between many factors.