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, and is used by either to express an interest in doing business, or the existence of a relationship that relies on independence and choice on both sides.

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.)

Naming and Lexicon

"Relbutton" is a placeholder. Other possibilities, with rationales:

• "LetsTalk" button. It aligns with "markets are conversations", is easy for ordinary folks to understand, is friendly, and recognizes that human communications is an encompassing value that needs to be served. Recommended by a successful businesswoman with a long history on both the buying and selling side of retailing.
• "PayChoice" button. Because it's already been in use as a placeholder itself. (Follow the link.)
• "YouYou" button. Because the symbol resembles a pair of U's.

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":

Downloading a Public Radio Podcast

• An "ideal" user in this scenario is not an existing radio listener, but rather enjoys public media primarily through the downloading and listening of audio podcasts. They likely discovered a program through iTunes or other online media aggregator. Their relationship first and foremost in this context is with the program itself, it's content, creators, and recorded participants. They are blissfully unaware of any affiliated station (or even what a station is) and only vaguely understand affiliation with the network (e.g. NPR, PRI, APM, etc.).
• The user interacts with the podcast in a variety of ways - for example, in a list on the program's website, on a 3rd-party "taste-maker" site, through an RSS subscription in their reader, on their mobile device or phone during playback, or perhaps as part of a user-created mashup of multiple program bits
• Each platform and mode has the ability to provide some mechanism to allow the listener to know that there is an opportunity to "relate" to the media, for example, there might be a relbutton next to a download link or on the screen of their iPhone. Alternatively, in the absence of a vendor-side mechanism, the listener can still gather, time-stamp and store data about the source of the podcast for future use -- including notifying the source of the listener's interest.
• (It is likely here that the vendor will initiate a CTA that compels the user to click on the relbutton)
• Listener clicks on relate button; they identify themselves using a standard, open mechanism
• By clicking on the relbutton, a variety of choices to relate are presented to the consumer. They might include
  • Learn more - particularly in regards to privacy and transparency around this relationship (how vendor will use your participation, data, money, etc.)
  • Show your support - give a thumbs up. Have that approval possibly disclosed in a variety of ways (e.g. a public signed petition of support)
  • Provide general feedback, suggestion or vendor request (text, media, etc.)
  • Provide a response to something in particular, such as a vendor request for help (e.g. who should be our guest next week?)
  • Provide generalizable information about yourself, such as email address, zip code, download history, other likes/dislikes, or demographic info (what mechanisms could the vendor and listener use to signal usage of this info, e.g. "I am giving you my email so that you can alert me when and where to find your next podcast")
    • Personal listener information will generally be already stored and controlled by the listener; they can choose what to release
    • Vendor might make a request for additional new info (e.g. format and delivery preferences), if elected to provide, the data will become associated with your PDS for future relationships
  • Donate money (what mechanisms could the vendor and listener use to signal usage of this info, what should they be permitted to do, and how are these conditions monitored and regulated e.g. "I am giving you $10 only if you are able to raise $1000 from other donors," "I am giving you $10 towards future production only," etc.)