Archive for June, 2012

VRM/CX + CRM/CX

June 28, 2012

I’ve been in conversations lately about VRM+CRM. Will they help each other out or crash into each other? It’s an open question. But I think we can find an answer in a current CRM vector: toward what the CRM folks have been calling CX, for Customer eXperience. I first read about it in this column by Mitch Lieberman in October 2010. That was when he met with RightNow, which was later acquired by Oracle. You can see and read the results in this list, which is roughly in chronological order:

Experience is a personal thing. When two parties are engaging with each other, it’s something both create. That’s the challenge here.

How can we make the most of both serial and parallel activities and virtues in customer-vendor relationships? I invite our friends from the CRM/CX world to weigh in here.

And come to this:

It’s on 7-8 August in Minneapolis. I’ll be there. So will a bunch of VRM companies and projects, plus other parties interested in that subtitle there: new directions for personal data.

[This was the second half of Scaling business in parallel, but I decided to break it in two and move the second part here.]

Scaling business in parallel

June 28, 2012

Companies and customers need to be able to deal with each other in two ways: as individuals and as groups.

As of today companies can deal with customers both ways. They can get personal with customers, and they can deal with customers en masse. Without the latter capability, mass marketing would not be possible.

Customers, on the other hand, can only deal with companies as individuals, one at a time. Dealing with companies as groups is still a challenge. Consider the way you engage companies in the marketplace, both online and off. Your dealings with companies, on the whole, are separate and sequential. Nothing wrong with that, but it lacks scale. Hence: opportunity.

We can arrive at that opportunity space by looking at company and personal dealings, each with two kinds of engagement circuits: serial and parallel.

Start with a small company, say a store with customers who line up at the counter. That store  deals with customers in a serial way:

business, serial

The customers come to the counter, one after another, in a series. Energy in the form of goods goes out, and money comes back.

As companies scale up in size, however, they’d rather deal with many customers in parallel rather than in series. A parallel circuit looks like this:

business, parallel

Here customers are dealt with as a group: many at once, and in the same way. This, in an extremely simplified form, is a diagram of mass marketing. While it is still possible for a company to deal with customers individually, the idea is to deal with as many customers as possible at once and in the same ways.

I use electronic symbols in those circuits because resistance (the zig-zag symbol) adds up in series, while it goes down in parallel. This too is a virtue of mass marketing. Thus one-to-many works very well, and has proven so ever since Industry won the Industrial Revolution.

Over on the customers’ side, the marketplace on the whole looks like this:

customer, serial

The customer goes from one company to the next. This is not a problem on the vendors’ side, except to the degree that vendors would rather customers not shop elsewhere. This is why vendors come up with loyalty programs and other schemes to increase “switching costs” and to otherwise extract as much money and commitment as possible out of the customer.

But, from the customer’s side, it would also be cool if they could enjoy scale in parallel across many companies, like this:

In the physical world this is all but unthinkable. But the Internet makes it very thinkable, because the Net reduces nearly to zero the functional distance between any two entities, and presents an open space across which many connections can be made, at once if necessary, with few limits on the number or scope of possibilities. There is also no limit to the new forms of interaction that can happen here.

For example, a customer could scale in parallel by expressing demand to multiple vendors at the same time, or could change her contact information at once with many companies. In fact this is basically what VRM projects are about: scaling in parallel across many other entites. (Not just vendors, but also elected officials, government agencies, churches, clubs, and so on.)

It is easy to see how companies can feel threatened by this. For a century and a half we in business have made a virtue of “targeting,” “acquiring,” “capturing,” “managing,” “locking in” and “owning” customers. But think about the free market for a minute. Shouldn’t free customers be more valuable than captive ones? Wouldn’t it be better if customers and prospects could send many more, and better, signals to the marketplace, and to vendors as well, if they were capable of having their own native ways of dealing, consistently, across multiple vendors?

We have that now with email and other forms of messaging. But why stop there?

Naturally, it’s easy to ask, Could social media such as Facebook, Google+ and Twitter provide some of what we need here? Maybe, but the problem is that they are not ours, and they don’t work for us — in the sense that they are accountable to us. They work for advertisers. Email, IM and browsing aren’t owned by anybody. They are also substitutable. For example, you can move your mail from Gmail to your own server or elsewhere if you like. Google doesn’t own email’s protocols. No browser company owns HTTP, HTML or any of the Web’s protocols.

The other problem with social solutions is that they’re not personal. And that’s the scale we’re talking about here: adding parallel capabilities to individuals. Sure, aggregation is possible, and a good thing. (And a number of VRM projects are of the aggregating-demand sort.) But the fallow ground is under our own feet. That’s where the biggest market opportunity is located. Also where, still, it is most ignored. Except, of course, here.

[Continued in VRM/CX + CRM/CX.]

Coming to terms

June 4, 2012

We lie every time we “accept” terms that we haven’t read — a pro forma  behavior that is all but required by the calf-cow model of the Web that’s prevailed since 1995. We need to change that. And so we are.

StandardLabel.org is working on “A clear, consistent way for websites to say what they do with the data they share, before we share it.” While its recent Kickstarter campaign came up a bit short, the work continues. Here is one (prototypical) way that label might look:

(The actual image I wanted there was this one, but heard it wasn’t showing up in all browsers, so I went with the one above.)

The StandardLabel folks also have a survey, which I recommend taking.

CommonTerms intends “to solve the problem of non-accessible online legal texts in a way similar to how Creative Commons made different copyright licenses accessible,” adding, “We thought that by analyzing existing agreements, we could identify the most common terms, and then create icons to symbolize them.” Background:

The CommonTerms project is coordinated by Metamatrix AB andsponsored by Internetfonden.se

The project is a result of a session on “sustainable web development” by Pär Lannerö and Thomas Bjelkeman at the Sweden Social Web Camp, in August 2010.

Their prototype, focused on icons, stars Pär and looks like this:

Par and  Lars-Erik Jakobsson (icon), Gregg BernsteinCarl TörnquistHanna ArkestålMax WalterMattias AspelundAnders Carlman have since added BiggestLie.com, source of the image at the top of this post, plus this one here, which I just earned:

The idea is to start getting real about what we’re all doing and not doing.

What we’re doing is lying: i.e. agreeing not only to what we don’t read, but to the rotted status quo of which one-sided non-agreements are a part. What we’ve not been doing for most of the last 17 years is solving the problem.

But, thanks to the work above (plus whatever I’ve missed), we are doing some things. So are PDEC.cc and companies like Personal. Other work is happening with personal clouds. (PDEC is on that case too.) Aza Raskin‘s Privacy Icons are an effort in this same direction. (CommonTerms has a longer list.)

Still, looks to me like most of the work being done so far is on the cow side of the calf-cow relationship. On our side, we need to stop being calves, for real. That is, we need to have full agency in the original sense of the word: power to cause intended effects on our own.

For that we will need machine- and user-readable ways to express own terms, preferences and policies, so they can be read by sites (the cows) and matched up. That’s the idea behind EmanciTerm, described in How about using the ‘No Track’ button we already have? and in The Intention Economy. There I explain,

With full agency, however, an individual can say, in the first person voice, “I own my data, I control who gets access to it, and I specify what I wish to happen under what conditions.” In the latter category, those wishes might include:

  • Don’t track my activities outside of this site.
  • Don’t put cookies in my browser for anything other than helping us remember each other and where we were.
  • Make data collected about me available in a standard, open format.
  • Please meet my fourth-party agent, Personal.com (or whomever).

These are EmanciTerms, and there will be corresponding ones on the vendor’s side. Once they are made simple and straightforward enough, they should become normative to the point where they serve as de facto stan- dards, in practice.

Since the terms should be agreeable and can be expressed in text that code can parse, the process of arriving at agreements can be automated.

For example, when using a public wi-fi access point, a person’s EmanciTerms might say, “I will not knowingly hog this shared resource, for example, by watching high-def video on it,” or “I will not engage in illegal activities here.” If the provider of the access point has a VRM-ready service that is willing to deal with the user on his or her own EmanciTerms as well as those of the provider, it should be possible to automate the formalities and let the user bypass the usual “read and accept our agreement” ritual.

Not everything we express in the proposed ceremony here has to be one side of a binding agreement. If we express these terms as preferences or policies they can still be heard, even if they’re not agreed to. Being heard is one idea behind BiggestLie. But the cows can’t fix this on their own. We need to work both sides.

The only problem with all this is that our work is scattered. Let’s get it together.