Relbutton Scenarios

This page will be where we work out some of the scenarios -- choice, decision and action trees -- 
on both the customer and vendor sides of the interactions that relbutton placement and clickings 
will involve. -Doc

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

Code comes next. We have faith that much of the necessary code is already laying around. But the scenarios 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 consumers, 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.
• It 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.

Visuals

Here's one possible way it might look:

The two shapes symbolize two magnets facing each other, open to each other but not necessarily connected. They also symbolize choice. The customer doesn't need to click on it. If they do, it might close, and look like this --

-- which would indicate that the customer has already paid for the item, or that a relationship is already present. Double-clicking again would lead to a page with choices of actions (in the case of an open button) or records of past payments or existing relationship (in the case of a closed button).

(Doc chose red for no particular reason other than visibility. It could be another color. It could also be a color that changes depending on conditions outlined below.)

Requirements

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

• It should be under the customer's control. This does not mean it should not also be under the vendor'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.
• For identity-based interactions, it should obey the [Seven Laws of Identity]

Scenarios

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.

Note: An earlier effort in this same direction is PayChoice.