How clean is your customer data?
Actually, before you think about that, let me ask a better question;
How do you define what a customer is?
Once again, like so many things in the PSA space, a simple question can only be answered with a complex reply.
A customer is obviously someone who pays you money, until you consider the following edge cases:
- A company that uses your services on an occasional basis, but with whom you don’t have an ongoing contractual relationship
- A company that had a service contract that they cancelled with the intention of asking for help now and then
- A company that signed an agreement but never requested service and so has never been billed
- A company that purchased your product but never asked for (or paid for) support though they might
- A company that purchased your product via a channel partner
- A company that paid for a trial of your product, but didn’t buy in the end
- A subsidiary of a company that signed a service agreement that applies at a group level (so including subsidiaries) where the billing rule is to bill the parent
We could go on…
Now, wer're sure you all have perfectly reasonable answers to that challenge (and I’m also sure they won’t be the same). But that is not the point of the blog post. We can all agree to put adjectives in front of the word customer to deal with these situations (well most of them), but (and this is the point of the blog) how do you model all that consistently in the “so called” best of breed distributed architecture used by many organisations in such a way that when the boss asks “how many customers do we have?” you know the right answer.
Each functional platform in the architecture will have differing needs and so different ways of answering my simple question. But, probably none of them will have the right answer - interesting eh.
Let’s drill this down a bit:
- The CRM system is often quoted as the place the customer journey begins, so that database must be right. Well, no. The CRM system is probably way out. It will have records that never became customers and ones that ceased to be customers. Also, the needs of a CRM system are such that its data model is the simplest (even pivoted around contact, customer being a secondary element from a CRM perspective, so frequently duplicated).
- So, the general ledger then must have the truth. Well, sorry, no again. If you use customer sub-ledgers it will know all the companies you have ever billed, but that is not the current customer list, far from it.
- What about your service desk system, surely that must know? Depending on how it’s maintained (and that is a big condition statement) it should have the list of all the customers paying for support, though most model channel partners, not end customers, so will miss those. And the customers paying for support, may well not be all your customers.
- OK, how about the timesheet system? Sorry, only a subset ever get into the timesheet system, again depending on how good your distributed data architecture is at keeping the score for parent companies, subsidiaries, end customers etc. Actually, I expect it will only have the list of customers you have done project work for, and that will contain ex-customers and duplicates.
- What about your contract system (or spreadsheet)? Probably it will have the list of your active contracts and that’s probably close to your customer list but not the same.
- And I haven’t talked about mergers, acquisitions or bankruptcies
So think about how you would answer the question(s) and where your single version of the truth lies. Then start to think about how the replicated views of that truth are maintained and how other definitions find their way in and out of those systems.
Does this matter? Well no, not really. 1000s of companies work this way. But when you want to analyse your business by customer suddenly the noise matters a lot and may create more confusion than insight. Distributing your customer data is not a good idea - it never was and it never will be.
That is the main drawback of best of breed. Perhaps it should be called worst of data.