We often make the point that the successful implementation of CRM requires both good strategy, and attention to operational detail, and so we want these editorials to cover both the large strategic issues and some detailed nitty-gritty operational issues.
We've been focusing heavily on strategy recently, so this week I want to cover an operational issue: getting customer involvement in the design of CRM processes.
This issue makes me particularly nervous, because I'm very aware that we're not experts in this ourselves (though we're probably all still learning). So I hope you'll take this editorial in the spirit in which it's offered - as part of our learning curve, and not as the voice of the expert. However, I've no doubt I can expect a few brickbats. Anyway, on with the show!!
First, where do we need to get customer input into the design of our customer systems? Of course, there are large areas where we don't need it: data warehouse design (though in many countries there are legal implications of holding customer data - e.g. the UK Data Protection Acts); the strategic analytic functions; the data mining and campaign management functions; and the evaluation processes which measure the effectiveness of your CRM system can all, in the main, be designed without input from the customers. The users of these functions are internal to the organisation.
However, this leaves the whole area of customer contact, be it through marketing communications, during phone conversations (both inbound and outbound) with customer service representatives, or perhaps most importantly, in electronic interactions directly with the company's systems through IVRs, websites, emails, and kiosks to mention just a few potential channels.
The key point to note about all these interactions, compared with the interactions that an employee makes whilst using the company's systems, is that the customer has a choice as to whether to complete the transaction or not, whilst the employee usually doesn't, at least if they want to keep their job.
The customer's freedom means that these transactions, often designed by a company's internal IT department, need to have the flexibility and user-friendliness of well-designed, end-user PC software packages, compared with the less flexible, more efficient transactions used internally.
What are some of the common dos and don'ts? The following eclectic list presents a few of my favourites (and no doubt I cite them quite often), and I'd love to add your ones to it - there would be value in a fairly exhaustive list of dos and don'ts in designing customer-facing transactions:
- Asking for the same data twice. A real horror, which happens all the time. Three times today I've given an IVR device 4 or 5 bits of data, and then had to give them again when speaking to an operator later in the process. There are still organisations that ask you to repeat all your demographic data every time you complete an application form (see this week's nominations for CRM Banana-skin of the month in the newsletter).
- Asking for the 'Primary Key' to a transaction. Primary keys to entities should be MUD - meaningless, useless (but unique), and dataless. As such it's not reasonable to expect a customer to look them up or remember them. Remember the IKEA example from last week's editorial: use Catalogue page number and price as the key to a stock-level query, rather than the SKU. If that, or a similar approach doesn't work in your context, then provide search screens which allow the customer to find what they're looking for by browsing.
- Provide at least three ways for a customer to do anything. Human beings are different, and what is elegant, obvious and easy-to-use for me, is the opposite for you. We've made this mistake with our new document library - only implementing one main way to get at the documents. This week, we're implementing a further 3 or 4 ways for you to find the documents you're interested in. We hope one will be the right way for you. At least you've got some choice.
- Minimise the data required for a transaction: Perhaps the hardest of all to get the balance right. There can be little doubt that the number of completed transactions is inversely correlated with the number of bits of data that have to be given as part of the transaction, even though the additional data may allow additional services to be offered.
- The precisely targeted (33%+ response rate) mail communication which starts 'Three reasons you should read this letter'. If a communication is relevant, you don't have to persuade the reader to read it. In fact, that very attempt will probably persuade the reader that it's an irrelevant marketing offer.
So there's a few of my particular hobby-horses when it comes to designing electronic transactions for customers (and for internal users). I hope all those users who have to put up with transactions I've designed that don't come up to scratch will forgive me, but still write in to point out the error of my ways, politely!!
Of course, this eclectic list is not of much real help in making sure that your CRM system is customer-friendly where it needs to be. However, perhaps we can get closer to that goal by defining where the customer should be involved in the development process. If we follow a fairly conventional development process what input should we expect from customers and when?
At User Requirements stage, it would seem key to try and involve the customers in defining needs for appropriate elements of the system. Of course, the customers may not be able to define their needs in the context of the new proposed environment, but an appropriate customer
panel should be able to offer better insights into their needs than sales, marketing, or IT personnel.
An obvious use of customers (but how many actually do it?) is to provide feedback to prototype transaction designs, both from a usability and comprehensibility perspective. The existence of the prototype design as screens, or scripts, makes the transaction much easier to envisage so the feedback is likely to be better.
Depending on the volume of transactions likely, it may also be advisable to involve customers in usability testing (a la Microsoft?) of almost complete transactions, so obvious confusions and misunderstandings can be corrected prior to implementation.
Finally, don't forget the user feedback post-implementation. Usually, transactions that don't change and develop aren't being used, so make sure you regularly ask for, and get, feedback from your customers, on new and revised versions of the transactions they use.
As ever, we're always interested to hear others' views, so if you feel moved, please add your experiences to this list, either by posting on the Bulletin Board, adding a comment to this editorial, or by mailing me directly at [email protected]