Capturing and collecting customer and competitor intelligence
Customer knowledge exists throughout your organisation, but much it is either ad hoc or informal, or else it is hard to get hold of or hard to use.
To enable customer knowledge to be collected in a useful way you need some means of systematically collecting the information. Customer knowledge is more than a list of order codes and customer knowledge databases face different problems to conventional database systems. Notanant is our Market Knowledge System which tackles the difficulties of managing customer knowledge.
Customer knowledge sits in many places in your organisation. Market research will have some information, your accounts some more, your sales team and customer service team yet more.
Ideally, you would like to have an organised view of what individual customers are doing, what their issues are and other useful information in one place so that it can be shared and cross-analysed to spot trends.
To take this step means capturing information to a database, but the form of the database needs to be sufficiently flexible to allow for a wide range of ad hoc and qualitative information to be captured along with indexes and references to a other documents and materials.
In collecting market knowledge for use and analysis you face a number of issues which go beyond traditional databases and data storage.
1. The tight-loose problem
Standard transactional databases require that information come in standardised discreet chunks - what we call tight data where information is strongly constrained. So a typical transactional database will capture an order with a date, quantities, product codes and prices. However, this tight-data can't represent that the customer felt that prices were high, or that an item would have been bought if another part had been in stock, or that the customer has £100k to spend before year end. This is loose data (some people might refer to this as qualitative data, but in fact qualitative data can also be stored in a tight format - a quote, a feeling, an association). You could capture this loose data in documents and reports, but then it's not usable for broader market analysis or comparison with other customers.
An example of the tight-loose problem is measurements of business earnings (profit). There are many ways to define earnings - before tax, after tax, before dividends, like-for-like, global, US only, including or excluding exceptation costs for restructuring. A tight data approach says that only one of these can go into the database. But competitors and customers may not provide the precise measure the database needs. The database needs to be looser in its definition to allow a wider variety of data to be captured, but probably with comments and notes useful to the analyst and reader.
In our experience where companies have defined their customer or competitor database information too tightly, the data isn't available or isn't usable as they expect. However, define it too loosely and no comparisons can be drawn it becomes too specific to one customer to too unspecific to be helpful. In capturing market knowledge you need a system which is both tight and loose.
2. The organisational complexity problem
Conventionally, databases will normally view an organisation as a company name and an address, or two if you're lucky. In reality, companies and even individuals are more complicated than this, and consequently the way each customers relates to your business is complex. To give you an example, Pizza Hut UK is a subsidiary of Yum Restaurants and Whitbread. Yum owns KFC among others. Whitbread owns Costa Coffee. The restaurants run by Pizza Hut might be sit-down, delivery-only or sit-down and delivery. They might be owned by Pizza Hut, or Whitbread, or by a franchisee. And the franchisee might own more than one franchise, potentially in different regions of the country.
Anywhere you have distribution as part of your offer you have similar levels of complexity, but this time involving distributors, channel, service agents, area managers. And of course it can all change tomorrow with a buy-out or take-over. So complexity changes over time and there is a high need for a flexible system
Most traditional databases simplify this complexity by ignoring it. But in understanding markets understanding and using the complexity can identify entry-points and opportunities.
3. Structured vs unstructured data
Related to the tight-loose problem is that of structured data. If a database is too tightly defined you can't get what needs to be captured, but it it is too loose you have no analytical power.
What you are really looking for is to build structured data out of the unstructured information collected. To add structure we need to be able to classify and determine what information we want in a structured format.
But there is a problem. The more deeply you analyse the data, the more classification you want to include. Yesterday the CEO said that our delivery performance needed monitoring so we've started collecting delivery times. Today, having looked at the delivery times we realise that it's actually about delivery completeness - on-time in-full. A different piece of data is needed today to that captured yesterday.
In conventional database designs this means adding another field and increasing redundancy in the data, not to mention the complexity of rebuilding the database (again) and the problem of maintaining historic data in this new setting.. Any system for marketing knowledge needs to be able to capture data, classify it into a structured framework, but be able to do this on-demand, flexibly and easily.
4. Incomplete data
By it's nature customer knowledge is incomplete and incompleteness frightens database managers. It means that either the database is full of empty cells, or it adds to complexity with another table for less frequently used data. But customers knowledge almost by definition is incomplete. Sometimes even the customers don't know what they want. And every customer is different. in medium sized companies, some will have specialist buyers for some functions and not for others. Some will have formal contracts and tender processes, some will be ad hoc. Not only that, we may be able to get some information for some customers, but not for others - the quality of the relationship may get in the way. It doesn't mean that the data we do have has no value. For customer knowledge systems, data is as-and-when and rarely 90% complete.
5. Ambiguity
Prices, product codes, order numbers, invoices are all designed to a fixed format to avoid ambiguity. For customer knowledge, ambiguity is almost unavoidable. Take a simple example: Annual turnover. If you're comparing companies annual turnover you want to be able to compare like-with-like. But HP has a sales channel, Dell sells direct. IBM services form a large part of its services and Siemens bills in Euros. Seemingly simple terms can lead to ambiguous results. In capturing and classifying information care is need to define precisely what the data is that you are trying to capture, and to a certain extent, the quality of that data. This means that within the structure and complexity you need ways to control to reduce ambiguity without making the database too tight again.
6. Who captures, who sees, who uses?
The final challenge to be mentioned here is the problem of data collection and data sharing. Customer data is often best collected close to the customer (see our paper on One2One research) since there is greater familiarity with the customer directly. But it may be that someone centrally is also monitoring and collecting data. In some circumstances those in the field won't have time to collect customer data. So within the system there needs to be spoke and mechanisms to allow different people to capture information to the database, whilst still ensuring that the quality of the data is maintained.
Then having captured the information, those who would find it most useful are, again those people closest to the customer. But they want a micro-picture specific to their customers. Centrally, the company wants to draw all the information together: a macro-picture. And it may be that the central macro picture is only available to a small team of planners and managers. The system in use needs to be able to control who captures, who sees and who uses the data.
Our Notanant Marketing Knowledge System solves these problems (and more).
For help and advice on building customer, competitor or marketing knowledge systems contact info@dobney.com or take a look at Notanant our on-line solution.