That’s certainly progress but it’s a much harder question to answer than the one about DMPs. Like any good consultant, I can only answer that question with “it depends” and by then asking more questions. Here are some of the factors that go into a final answer.
- What resources do you have available? The goal for your initial use case is to get something done quickly that returns substantial value. Getting something done quickly means you want a project that uses existing resources to the greatest degree possible. Ideally, the only new element would be the CDP itself, and even the CDP deployment would use a small number of data sources. So, an ideal first project would use data in existing systems that is well understood, known to be of high quality, and can easily be extracted to feed the CDP. Alternately, the first project might involve new data collected by the CDP itself, such as Web site behaviors captured by the CDP's own page tag. If the first project is purely analytical, such as customer profiling or journey analysis, then you don’t need to worry about connecting to execution systems, although you do need staff resources to properly interpret the data and possibly some analytical or reporting systems. But if you happen to have good execution systems in place, it may make sense for the first project to connect with them. Or, you may pick a CDP that provides its own execution capabilities or can feed lists or offer recommendations to external delivery systems.
- What use case will provide value? This is where good delivery resources can be helpful: it’s much easier to deliver value with a use case that involves direct customer interaction and, thus, the opportunity to increase revenue or reduce costs. Often this can still be quite simple, such as a change in Web site personalization (involving just one channel for both source and delivery), an event-triggered email, or a prioritized contact list for sales teams. If execution isn’t an option, an analytical project can still be valuable if it presents information that wasn’t previously available. This may mean combining data that was previously kept separate, reformatting data couldn’t be analyzed in its original form, or simply pulling data from an inaccessible system into an accessible database. The trick here is for the analysis to generate insights that themselves can be the basis for action, even if the CDP isn’t part of the execution process.
- How much organizational change will be needed? Technical obstacles are often less significant barriers than organizational resistance. In particular, it can be difficult to start with projects that cross lines of authority either within marketing (say, separate Web and email teams) or between marketing and other departments (such as operations or customer support). When considering such changes, take into account the needs to revise business processes, to provide adequate training, to align compensation systems with the new goals, to provide reporting systems that track execution, and to measure the value of results. As a practical matter, the fewer parts of the organization affected by the initial project, the easier it will be to deploy and the higher the likelihood of success.
- Where’s the pain? It’s tempting to search for an initial project that is primarily easy to deploy. But even an easy project is competing with other demands on company resources in general and on staff and managers’ time in particular. So it’s important to pick a first project that solves a problem that’s recognized as important. If the problem is big enough – and it’s clear the CDP can solve it – then you have a good chance of convincing the company to make a substantial investment from the start. Ultimately, this is the right approach: after all, the CDP isn’t an end in itself, it’s a tool for improving your business. You may see a broad range of applications for your CDP but for those who don’t share that vision, you’ll need to show its value at every step of the way.
No comments:
Post a Comment