By Jason Wilson
Several years ago, I was at a meeting with some high level marketing executives at a very, very large publishing company. We were discussing something or another that prompted the question: why do I get direct mail pieces that don’t really correspond to the databases I’m searching? (This was pre-federated searching.) After all, the company had everyone of my employees’ names, knew the databases we searched, the specific search queries we ran, and the frequency of those searches. So really, how hard could it be to coordinate email and direct-mail campaigns to each employee at my company? This question really could be posed for any law firm as well.
To my dismay, the executives said: “We don’t have that capability.” I’m pretty sure they winked at each other after they said it, slapped hands under the table, and giggled. Needless to say, about a month later I started getting very targeted direct-mail pieces. I’m not sure if the two went hand-in-hand or not, but it more or less confirmed what I thought, which is “Shit yes, we can do that.”
So here is my question to you: do you have any clue how much your preferred CALR vendor knows about you? (That includes Thomson Reuters Professional (yes, get used to saying it because Westlaw and WestlawNext will be going away soon), Lexis Advance (yes, not just Lexis any longer), Loislaw, Fastcase, or Casemaker.) Even better, do you have any clue how much they know about your clients? After all, you associate every transaction with a client-matter (C/M) don’t you? I sometimes wonder how much these CALR vendors could know about you (lawyer/law firm) and your clients at any given moment. Sure, they might not know names, but they would know if related C/M are facing pharma litigation and, say, Federal Corrupt Practices Act violations. For large law, how hard would it be to match C/M data, account data, and public data to determine who your clients are and the specific problems they are facing? And if they, the CALR vendors, were interested in selling services directly to your clients’ corporate counsel, imagine how much those businesses might already know about your clients’ exposure and vulnerabilities. If you think CALR vendors are on your side, you might want to stop and consider just how much they actually know about what you do, and how they plan to compete with your own data. In other words, do you just read the contracts to determine what databases you’re subscribing to and how much you pay each year for three years, or do you actually read them to determine what those companies are doing with your data? Clearly, Thomson Reuters is already using your data to inform search, so what else might they be doing, particularly in light of their Pangea3 acquisition? These are just questions, and ones that I haven’t seen on the Tubes oddly.
The funny thing is that I’m just waiting for some enterprising lawyer to test the limits of the work-product doctrine with CALR vendors by asking for search histories associated with opposing counsel’s clients. The only reason I can think it hasn’t happened yet is the fact that the enterprising young lawyer would have to reveal his or hers as well. Either way, it’s only a matter of time before it happens.
UPDATE: This morning I was rethinking this post, and I wanted to mention Thomson Reuter’s WestlawNext search algorithm WestSearch again. Remember, when WestlawNext was released the new search algorithm was built using customer data, among other things. These were referred to as “meaningful interactions.” Regardless of whether this data is anonymized (to the extent any data can be), it’s yours and your clients’ and I doubt you were asked or told if it would be used. Also, if you considered yourself to be a power researcher (something that gives you a competitive advantage), that same data is helping your competitors be better and more efficient researchers as well. Maybe it bothers you, maybe it doesn’t, but at a time when the discussion about privacy rights and data use/security is at an all time high, it seems like something worth considering.
[Image (CC) by Zh3uS]