Relbutton Scenarios

"Relbutton" is a name for what we've also been calling a "buy button" or a "PayChoice" button. The "rel" stands for relationship.

The button combines reciprocal symbols for customer and vendor, each represented by red "magnets" facing each other.

It can be used either by a customer to express an interest in doing business with a vendor, or by either or both sides to reveal the existence of a relationship. When that is the case, the two "magnets" appear joined. (Other configurations are reviewed below.)

Customers can use it as a "pay button" to express a willingness to buy goods that are otherwise free (such as podcasts, blogs, pieces of music or public radio stations or programs). Vendors can use it to express an interest in doing business on terms that embrace actual relationship -- including terms that are provided by the customer as well as the vendor. With it, VRM meets CRM, and each can engage and improve relations with other.

As a simple symbolic representation of willingness and commitment by both sides, the relbutton provides a visual door to back ends of capabilities and record-keeping (as well as transaction ability) that can help improve markets by making customers independent and informative contributors, and not just sources of cash and data for marketing mills.

Basic Characteristics

• The Relbutton represents a free and open web service, available to both vendors and customers, providing capabilities to both
• The button can be placed by the customer on anything he or she might be willing to pay for -- or to indicate an interest in conversation or relationship.
• The button can also be displayed by the site as an signal that a displayed item (or service, or whatever) is open to either being paid for, or a relationship, or both.
• A web service API allows vendors (i.e. producers, owners, distributors, etc.) to attach Relbutton features to their site, project, products, or content
• A web service API allows consumers (i.e. users, customer, etc.) to attach Relbutton features to external vendors' site, project, products, or content
• The relbutton can also be the real as well as symbolic place where VRM and CRM meet.
• As with Creative Commons licences and symbols, the relbutton and its functions should be readable three ways: by humans, by machines and by lawyers.

Visuals

The relbutton is a set of two images resembling two facing magnets, open toward each other. The shapes symbolize openness, choice, independence, equality and intentionality. They can appear in four ways, each expressing a different message. These are:

1. Open to relating:

2. Relating already:

3. Looking to buy something:

4. Looking to sell something:

What makes these especially helpful and handy is that they give both sides all the virtues listed above. So, for example, when a vendor puts this symbol on a product or a site...

... they're saying "We're willing to do business with you on your terms as well as ours."

And, when the customer clicks on a closed button...

... data from both sides can be brought in and displayed.

That data can be anything pertaining to relationship, history, intentionality, preference... it's wide open.

In practical and simple terms, when the customer clicks on the button, it says "hey you" to the vendor. If the vendor responds, the customer's "it's me" data repository and choice matrix comes into play. The databases on both sides might also be called "hey you" and "it's me".

As they say in the advertising business, this has legs. Lots of them.

By the way, the symbols are red for no reason other than visibility. They could be another color, or other colors. They could also be a color that changes depending on conditions outlined below.)

Britt Blaser produced this graphical explanation of the relbutton:

Note that there are many possibilities here, and the ones shown on this page are the initial few.

Requirements

Before we proceed, here is what the relbutton should and should not do:

• All but symbol 4 (vendor side only) should be under the customer's control.
• It should support true two-way relationships between customers and vendors in all three market domains: transaction, conversation and relationship.
• Unlike advertising and promotion, it will be a way that the customer makes the first move. It must support the intentions of the customer first, and the vendor second.
• It should support the ability of the customer to pay whatever they please. Also for the vendor not to accept the payment. For this reason, it should allow the buyer to escrow (or record) the intention to pay, so the vendor can see that if they wish, or accept payment once the vendor puts the acceptance mechanisms in place. This should be visible exclusively to those vendors, even if they do not yet have the mechanisms in place for perceiving them, or for accepting payment. This system will allow vendors payment-acceptance and CRM systems to adapt to standard means by which customers, at their discretion, can transact, converse with and relate with vendors.
• It should not provide means by which vendors coerce or entrap customers. Once relationships are established, they can be whatever customers and vendors agree upon. But as a means for "hooking up", or accepting payment, relbuttons cannot be under exclusive vendor control. For example, if a relbutton on a music site brings up a list of fixed prices for selections and albums, the customer should still have the choice of offering amounts they please, rather than just the prices offered by the vendor. This doesn't mean the vendor has to accept what the customer offers. It does mean that the customer has the means for offering what they like, including amounts higher than the vendor is asking.
• It should support the expression of preferences. This includes conditions for relationship, such as selective disclosure of personal data, conditions for the use of personal data, interest in specific (and defined) future products, and interaction requirements. Among the latter might be, for example, the preference not to receive promotional messages when calling for tech support.
• It should support customers and vendors both retaining records of interactions in the course of relationship, including transaction histories, contact histories and other variables. Among many other thints, these should be able to back each other up at times when the other party loses data.
• Both parties should be able to cease relationships, on mutually agreeable terms.
• For identity-based interactions, it should obey the [Seven Laws of Identity]

Best Fits

The relbutton model will likely be ideal for certain products, vendors, and verticals - perhaps with traditional companies that are seeking mechanisms to better relate to their customers, or in a market where customers are lacking the trust and control they demand. What are the characteristics for these best fits?

Alternatively, some new online environments and markets that were created specifically to disrupt artificial boundaries between vendor and consumer, such as ebay, threadless.com or even wikipedia may avoid such distinctions entirely.

"Relate" will also mean something quite different in different markets or areas. These differences need to be respected.

Scenarios

Media in general

The first use case for the relbutton is media. These include

• public media, including stations and programs
• citizen and participatory media, including otherwise free online publications
• podcasts
• online publications, including blogs
• pieces of music, or artists

Since the VRM community already includes participants from public media, and since we have been in conversation with public media folks about VRM for more than a year, that would be the best place to start prototyping and scenario-planning relbutton usage.

The MID Radio

An MID is a Mobile Internet Device. These include all handheld units that are capable of using the Internet via wi-fi or the cellular telephone networks. Examples range from the Nokia N810 to the iPhone to open phones designed via Trolltech/Nokia/ Google/Android, OpenMoko or any of the other emerging (and mostly Linux-based) devices and their development platforms.

(Intel especially is driving development in this category.

In the long run, radio will overcome its current fixed-transmitter and limited spectrum limits (which have been with us since AM/MW/SW radio was established in the 1920s, and FM was established in the 1940s) -- by moving to streaming via wi-fi and mobile phone systems.

We can make that run much shorter by building stream tuners for MIDs.

Their directories can be populated informally by users cutting and pasting from stream URLs on websites, or more formally by interactive web services.

They can be designed to receive streams only at bandwidths permitted by existing connection limitations, moving from one data rate stream to another as conditions permit.

They can have UIs that are either directory schema based or that allow users to fan through choices in the manner of Apple's "coverflow".

The relbutton should be a standard feature of these radio tuners to begin with. If you design a stream tuner (or, for that matter, a podcast player that allows users to interact by producing as well as consuming data), it needs to support relbuttons and relbutton-based interactions.

Where relbutton interactions are not supported, the user should still be able to accumulate data about the source of the stream or the podcast, and escrow that data for future use. (Perhaps, among other things, by advertising the fact that the user is interested in relating to the source, even though the source does not yet support the relbutton. This will allow demand to be heard, even if supply is not yet ready.)

Here are some graphical mock-ups of how the relbutton might be used with an iPhone stream or podcast "tuner":