Relbutton Scenarios

"Relbutton" is a placeholder name for what we've 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 pay for 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, it provides a visual front for 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.

We need code. We also have faith that much of the necessary code is already laying around. Conversations are already taking place in the Identity community. The scenarios we develop here will help us decide what goes where and how it works together.

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 they might be willing to pay for -- or with which they might be interested in a 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.

As they say in the advertising business, it 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]

Scenarios

How might the relbutton be used and deployed? What are some typical examples of how vendors and users might use such a thing?

Best Fit?

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

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.

Hey-You / It's Me

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 comes into play. The databases on both sides might also be called "hey you" and "it's me".

Downloading a Public Radio Podcast (consumer)

• 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 consumer 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
• (It is likely here that the vendor will initiate a CTA that compels the user to click on the relbutton)
• Consumer 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 consumer 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 consumer information will generally be already stored and controlled by the consumer; 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 consumer 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.)