A client I hadn’t worked with for several years recently emailed me, asking me to review his organization’s CRM strategy. The client (let’s call him Bill), the chief architect at a large California utility, said that, while the company would not replace its existing customer databases (very expensive customer information systems), it would be evaluating new user-facing applications. Bill mentioned two popular customer service applications and asked which one I’d recommend.
After convincing myself that this must be a trick question—anyone who’s ever worked with me knows I don’t buy into the “because they’re household names, one must be right for you” game—I called Bill and asked (nicely, I swear) if he’d forgotten everything I’d ever taught him. Turns out that, no, he hadn’t forgotten completely. He just needed a little “reminder” about the right way to provision CRM technology. Where “reminder” equals a stern but loving lecture.
As I reminded Bill, I recommend a process which, when consistently applied, forces CRM teams to think beyond project-based requirements to patterns and best practices that run through several individual technology decisions. Because it is still not possible to purchase all CRM technology ecosystem components (operational, collaborative and analytical CRM, for instance) from a single vendor in all industries, organizations will frequently repeat the provisioning process. It is, therefore, critical that organizations evolve to a process-oriented technology acquisition strategy, whereby the organization’s customer strategy drives CRM technology decisions.
This is in direct contrast to the more common approaches of issuing project-specific RFPs, product evaluations and market segmentations that are snapshots of a point in time.
The provisioning process consists of the following four discrete steps, with the deliverables satisfying one of the four key enterprise architecture components:
- Needs analysis. In this first stage of this process, you identify CRM business needs, based on process and customer patterns.
Customer patterns (CRM treatments applied to individual customer segments), which are, themselves, based on unique segment characteristics (channel and touch-point preferences through the engage-transact-fulfill-service customer lifecycle), are used when your company knows the common and repeatable attributes of the customer base.
‘Your organization will need to go through this process a number of times.
Generic process patterns (based on the ETFS—engage, transact, fulfill, service—path and identification of process breakdowns in sales, marketing or service) are used when you don’t know customer patterns.
The output of needs analysis is a list of prioritized current and future business needs to support the organization’s strategic CRM objectives.
Bill’s company focused on the service process, the source of most of its customer information. He discovered three overarching business needs: providing a single view of the customer for service representatives and others in contact with customers; improving the customer experience; and improving marketing capabilities.
Business services include higher-level discrete business functions across the operational, analytical and collaborative CRM domains.
Infrastructure services encompass both application services (such as development, foundation, administration and integration) and specific services to support the higher-level business services.
The output of requirements definition is a prioritized list of services necessary to satisfy the needs identified in the first stage. In selecting technology, most organizations like Bill’s confuse requirements and needs and essentially skip directly to this stage. I’m sure you do this, too, when you talk about gathering “the requirements” for the solution. But when you do this before identifying the business needs, you introduce a huge amount of risk.
Bill’s needs turned into a requirement definition that included customer segmentation and real-time marketing.
This stage also reveals which technology components currently in inventory need to be updated to support the CRM future state. You can find tactical fixes to the current state (“low-hanging fruit”) in this stage.
Bill discovered fairly significant gaps around operational services for marketing and analytical services, enabling customer behavior modeling and scoring. These types of services had not even been on the radar screen.
Product evaluation reveals technology patterns you need to support discrete customer or process patterns identified in the first stage. In turn, these technology patterns consist of vendor products and/or in-house development requirements.
Bill found that, while his company certainly needed to refresh the customer service agent’s desktop with a more usable interface, it also needed to source a marketing application and other data aggregation technologies.
While the details of this process (but not the process, itself) will differ significantly from organization to organization based on factors such as CRM readiness, infrastructure maturity and the existing CRM application portfolio, you must understand that the process, itself, is highly iterative.
In other words, your organization will need to go through this process a number of times, each time refining and achieving increased granularity with respect to customer patterns and, therefore, technology patterns. Ultimately, this process will help your company evolve to a lifecycle approach to CRM, while providing highly specialized treatments to specific customer patterns.
After applying this process a few times, Bill ultimately settled on a combination of packaged customer service software that did not include either of the two he had emailed me about, along with a combination of purchased and custom-developed add-on services for the marketing. Not a bad outcome.