Category: APIs

Turning the customer journey into a virtuous cycle

Traditional CRM typically looks at customers this way:CRM cycleIt’s a cycle. One of the reasons we started ProjectVRM is that actual customers are hard to find in the CRM business. We are “leads” for Sales, “cases” in Support, “leads” again in Marketing. At the Orders stage we are destinations to which products and invoices are delivered. That’s it.

Oracle CRM, however, has a nice twist on this (and thanks to @nitinbadjatia of Oracle for sharing it*):

Oracle Twist

Here we see the “customer journey” as a path that loops between buying and owning. The blue part — OWN, on the right — is literally the customer’s own-space. As the text on the OWN loop shows, the company’s job in that space is to support and serve. As we see here…

… the place where that happens is typically the call center.

Now let’s pause to consider the curb weight of “solutions” in the world of interactivity between company and customer today. In the BUY loop of the customer journey, we have:

  1. All of advertising, which Magna Global expects to pass $.5 trillion this year
  2. All of CRM, which Gartner pegs at $18b)
  3. All the rest of marketing, which has too many segments for me to bother looking up

In the OWN loop we have a $0trillion greenfield. This is where VRM started, with personal data lockers, stores, vaults, services and (just in the last few months) clouds.

Now look around your home. What you see is mostly stuff you own. Meaning you’ve bought it already. How about basing your relationships with companies on those things, rather than over on the BUY side of the loop, where you are forced to stand under a Niagara of advertising and sales-pitching, by companies and agencies trying to “target” and “acquire” you. From marketing’s traditional point of view (the headwaters of that Niagara), the OWN loop is where they can “manage” you, “control” you, “own” you and “lock” you in. To see one way this works, check your wallets, purses, glove compartments and kitchen junk drawers for “loyalty” cards that have little if anything to do with genuine loyalty.

But what if the OWN loop actually belonged to the customer, and not to the CRM system? What if you had VRM going there, working together with CRM, at any number of touch points, including the call center?

This is more than a simple dream. One of the coolest things to happen in the VRM development world is this insight, based on actual technology: everything you own can have its own cloud, and each can live inside your personal cloud. Your stuff doesn’t need to have embedded smarts. You can put your things’ smarts inside clouds of their own. Manufacturers can also include clouds along with everything they sell. Inside that cloud can go all the touchpoint contact data required for a genuine relationship, plus useful extras such as service manuals and shortcuts to product updates.

This means the product itself becomes the platform for relationship between the customer and everybody on the sell side, from manufacturer to distributor to retailer to service company. As I explained in this HBR post, that platform — the product’s cloud — is the level table where all those parties sit, at the grace of the customer. Because it’s the customer’s space.

One tablecloth for that platform is the TalkTag. It’s a simple QR code, like the one on the right. The pioneering company here is Kynetx, through its SquareTag service. It’s a simple way to give anything you have a cloud of its own. Scanning a TalkTag is one way to visit a thing’s cloud, which is also a programmable space. If your thing is lost, you can program it to provide contact information through somebody’s smartphone when they scan it. (Which I have done, and it works.)

You can also program it to, say, notify the call center when you scan it. For example, I want the TalkTag I just put on my cable modem to notify Time Warner Cable when I scan it. If Time Warner Cable’s CRM system is listening (which should be easy enough to make happen), it can send back a message to my phone, telling me there is an outage in my neighborhood. Or, in the event that there isn’t an outage, the “I’ve been scanned” message from me to Time Warner Cable can jump past stages in the company’s IVR (Interactive Voice Response) system and get me straight to the right person or automated response. That might be, “You need to download new firmware,” or “We have three new service tiers you might want to know about,” or “We see you haven’t paid your bill.”

I have shared this kind of scenario with two call center companies recently, and they liked it a lot. In fact they like the whole idea of VRM systems on the customers’ side that can lighten the burdens of relationship (and open opportunities) for both sides.

The customer journey — his or her experiences of owning and buying — will include more than just interacting with call centers. We use the things we own in countless ways that might be useful to share with others, including the companies that make and sell stuff — and not just through “social” systems like Facebook and Twitter, over which we have little or no control.

We should also be able to integrate data from products that don’t relate but should. In the Quantified Self world, for example, there is a standing need to synthesize data from many devices and databases. This need  cannot be solved by asking Nike, Fitbit, Withings, RunKeeper and the rest of them to all make their data un-silo’d and combine-able. And doing it in “social media,” whose only business is advertising at us, won’t work either. We need means of our own.

In the VRM world we’ve been saying the user needs to be the point of integration for his or her own data since Joe Andrieu first expressed that insight in 2007. Now, with personal clouds, in 2013, it’s starting to look possible. In fact the personal cloud, and the whole OWN loop, can also be a platform for intentcasting toward the BUY side.

The OWN side is also where all the privacy technology also sits, chiefly because it is distributed. It is here also that we hold the terms, preferences and policies we express when dealing with companies sitting across the tables set between us.

An interesting case that lies between buying and owning is relationships with service organizations, such as utilities. What we own here is own side of an ongoing relationship. Equipment of our own may be in there, or may not be. Either way, the use of a service — in our homes, cars and pockets — is what we at least control, even if we don’t own it.

So clearly we need a common platform for personal clouds, and for the things we put in them. That platform needs to be small, lightweight, distributed and open source. Right now I see one candidate for that: CloudOS, which is the brainbaby of Phil Windley. (Here’s a search for CloudOS and Windley. Lots of stuff there.) If you’ve got some other hacks, point them out in the comments below.

If we look at the customer experience from the company’s side again, this graphic from Joe Pine and Jim Gilmore does a nice job of framing the possibilities:

Across the table set in a personal cloud, customers can feed back good intelligence to every one of the loops in that graphic. And, because that data arrives directly and voluntarily, it has far higher quality than inferential data gathered by marketing’s many surveillance methods.

It also re-frames relationship and loyalty, as real things rather than as words marketing recites inside its own echo chambers. It will reduce marketing’s urge to manipulate, and advertising’s urge to personalize in the absence of conscious and voluntary signals welcoming it. The customer journey will thus turn into a virtuous cycle rather than the arduous one it is today.

It can also create a demand chain that can work in tandem with the supply chain, providing far better feedback at every stage. I could go on, but I want to get this up before the latest in the series of Important Calls that punctuate my life. (And they are all Good Things, trust me.)

Bonus link.

* In the comments below the post that follows this one, Ray Wang points to Esteban Kolsky as the original author of this graphic. As I say in my comment below Ray’s, I did hear that from Nitin Badjatia (of Oracle and formerly of Right Now), but I didn’t remember it when I wrote both posts in a hurry. Again, it is the verbs — BUY and OWN — that make the image especially useful for VRM, because they are the customer’s. I don’t yet know if those verbs are Esteban’s or Right Now/Oracle’s. Let me know and I’ll give credit where due.

When consumers become media for themselves

I was talking recently with Edi Immonen of Glome about the idea behind it: turning users into publishers. He used the word “media,” but I’m going with “publishers” for now, because that’s the word used in this graphic (one of many like it — all amazing and excellent) from LUMA partners:

That’s the marketer’s view. But how about yours, as the consumer over there on the right. In fact it’s actually more like this:

Because all you do is consume. You have no direct influence on all that intermediary stuff; so it just presses down on you.

But what if you become the publisher — a form of producer, and not just of consumer? Then the system, simplified, would look like this:

This is in alignment with what Tim Berners-Lee designed the Web to look like in the first place, but in in a commercial setting. (Remember that Sir Tim was then working in high energy physics at CERN, looking for ways to share and edit documents across the Internet as it existed at the turn of the ’90s.) It is also what blogging, as originally conceived, also did. If this blog were commercial (which it is not, on purpose), that would be me (or us) on the right.

Now, if we, as publishers, look at our data, or of our personal space — our state as a medium — as a platform for selling and buying stuff, including services, a whole new horizon opens up.

What Edi and his colleagues at Glome envision is a way for you, as a medium, to sell your space (however you chose to define that word) to:

  1. brands with which you already have a relationship;
  2. brands in which you have an interest; or
  3. brands in which you might have an interest.

From the traditional marketing perspective, #3 makes you “qualified lead,” for which the brand should be willing to pay. But that’s a far too reduced view of what you really are, or might be, to that brand.

Think of this marketplace frame from a CRM+VRM perspective. Between those two rectangles, inside the black two-pointed arrow, are cycles of buying and owning, of use and re-use, of live interactions and of long periods of idle time where neither is paying much attention to the other. Lots of stuff can go on within the boundaries of that two-way arrow.

What Glome proposes here is not zero-basing the marketplace, but instead to re-start our thinking, and our work, atop three well-understood existing roles: brand, publisher (or medium) and marketplace. The main re-characterization is of the individual, who is now a publisher or a medium, and not just a consumer.

Obviously much can get disintermediated here, including all the stuff between the marketer and the publisher in the graphic up top.

But much new intermediation is now possible, especially if the individual has a personal cloud through which one (or one’s fourth party) can program interactions, for the individual, among API-based services (in the manner of IFTTT, or using KRL) and the “Internet of things”. (For developers, I believe Singly fits in here too.)

So we are looking here at a whole new market for information and relationships, within the larger marketplace of everything else. This isn’t complicated, really. It’s actually what markets looked like in the first place:

This is the context we meant by “Markets are conversations” in The Cluetrain Manifesto.

LUMAscapes (such as the top one above) brilliantly depict the ecosystems of marketing as they have evolved so far, down different branches of discipline. The tree from which they branch, however, is the old advertising and direct marketing one, now operating inside the Internet . (“Big data” and analytics in marketing are hardly new. They were what direct mail was all about long before it evolved into direct marketing and then spread into online advertising.)

So this is a shout-to —

— as well as all the VRM developers in the world (and it seems there are more every day).

The last graphic above is our new frame. It helps that it’s also the oldest frame.

I also look forward to the day when Terence Kawaja and his colleagues at LUMA partners draw up VRM+CRM and other new ecosystems that are bound to evolve, once enough of us get our heads out of the old marketing frame and into the oldest marketplace one. So this is a shout-out to them too. :-)

Toward a matrix of APIs

At  the 2006 O’Reilly Emerging Technology conference, Cal Henderson, then of Flickr, gave a long session called “Launching and scaling new Web services.” As I recall, among the many things he explained well were some principles behind the Flickr API. One of those principles was user access to data. The API should be one that allowed the user to haul all of her data out of the system, even if it was to federate that data into a competing system. That’s because Flickr believed that user data is the user’s first, and not just the company’s. Another principle was keeping the API stable, so as not to disrupt users and other services that depended on the API.

Cal left Flickr a couple years after that, but Flickr’s API remains a model of stability and utility — so much so that Dave Winer this morning suggested it be declared a national treasure.

Many of us depend in large ways to the APIs of companies great and small — and more get added to that collection every day. For a good picture of what’s going on with APIs, check out ProgrammableWeb.com. Between Dave’s respect for durable APIs like Flickr’s, and ProgrammableWeb’s roster of current and future dependencies, we start to see a matrix of APIs that Craig Burton compares to a city filled with buildings and relationships. Each API provider, like each building, exposes the provider’s core competencies in ways that can be engaged.

But what happens when we each have our own APIs — when our own core competencies become exposed in ways that can be engaged? And when we start managing our lives through relationships between our APIs and those in the rest of the world — especially in ways that are live and full-duplex (two ways at the same time, like a phone call)? And where each of us, or a trusted agent, can do the required IF, THEN, OR and other programming logic, between our own personal clouds and the clouds of others? What will we have then?

There is lots of blogging out loud about this, about both the downsides of dependency (as both Phil Windley and I have, toward Flickr in particular). But I think the upside deserves more than equal consideration, especially as companies begin to realize the importance of direct and engaged relationships with customers and users, which is what we’ll have when VRM and CRM (along with allied functions on both sides) fully engage. The result, I believe, will be a matrix of useful dependencies, based on APIs everywhere, thick with accountability and responsibility. The result will be far more opportunity, and boundless positive economic and social externalities based on the Net’s and the Web’s founding virtues. What will end, or at least be obsoleted, are Matrix-like worlds where users and customers are held captive.

Thus our goal for VRM: to prove that free customers are more valuable than captive ones — both to themselves and to everyone and everything else with which they engage.

 

 

Driving VRM with car data and APIs

Go read OnStar gives Volt owners what they want: their data, in the cloud, by Sean Gallagher, in Ars Technica. It’s a VRM story. The vendor is Chevrolet, the vended product is the Volt, and the relationship management is a DIY hack by one customer. The story begins,

You probably don’t think of your car as a developer platform, but Mike Rosack did. A few days after buying his Chevy Volt, Rosack started slowly mining his driving data. But he eventually revved up his efforts and created a community platform for drivers to track their own efficiency. Today more than 1,800 Volt owners compare stats with each other, jockeying for position on Rosack’s Volt Stats leader board.

volt dash with r-buttonThe Volt uses OnStar, a GM subsidiary known through its advertising for providing a way for drivers to call for roadside assistance; but which is actually a sophisticated cell-based data system through which cars communicate constantly with the mother ship’s cloud. While OnStar generously shares data back to customers through an app called RemoteLink, much more can be done with it, since it’s data and comes out through an API. Now here is where the story gets VRooMy:

Rosack initially wanted to do more with his own driving data than just view it on his phone. So he built what eventually became Volt Stats to capture this data, then started sharing it with other Volt owners. There was just one small problem: Volt Stats relied on Rosack’s reverse engineering of an interface for OnStar’s RemoteLink mobile application (iOS and Android). When OnStar moved to shut down the Web services interface Rosack had plugged into in mid-October, Volt Stats arrived at a screeching halt.

Rather than leaving Volt Stats stalled on the roadside, GM and OnStar accelerated efforts to give developers a new public Web API to create services on top of OnStar data. The companies even worked with Rosack to get him onboard and get Volt Stats re-launched. Now, Volt Stats is back online and other would-be car data hackers will soon be able to connect their Web applications to GM owners’ vehicle data (provided, of course, that they have privacy policies that meet with the approval of GM and OnStar lawyers).

OnStar had already developed an API for GM partners such as the car-sharing service RelayRides, who need to get access to some of the remote control and telematics elements of the service. But this new interface takes advantage of technologies such as OAuth and JAX-RS and it’s a step toward turning OnStar into a broader platform for the “Internet of things.” It’s also a way to give car enthusiasts a new kind of access to something they’ve always thought of as their own—their cars’ data.

Now come the VRM questions:

  • Where and how might customers store that data? Are current PDS (personal data stores) compatible and ready for it?
  • How might customers use that data — especially outside and between multiple vendors’ apps, APIs and relationship silos?
  • Might we see an  ⊂ (r-button) on the dashboards of car? How might that work? And if it does, how do we make it standard?
  • What usage and new market-driving scenarios might we start to imagine here?
  • How might customers assert their own privacy policies and terms as demand begins to drive supply?
  • What other interfaces do cars have that might be brought into the picture?
  • How can what happens here model what we do with the rest of the “Internet of things?”
  • What are the meshy wireless things we can do among ourselves and our cars, outside any vendor’s box? (Would love Robin Chase‘s thinking here.)

These are questions especially for VRM developers. Look for answers (and more questions) here and on various blogs.

© 2014 ProjectVRM

Theme by Anders NorenUp ↑