May 16 2007 Meeting notes: Difference between revisions
Joe.andrieu (talk | contribs) (→Notes) |
Joe.andrieu (talk | contribs) (→Notes) |
||
| Line 81: | Line 81: | ||
At one level, we need to standardize license terms for accessing the personal data silo. (Identity rights agreements.) | At one level, we need to standardize license terms for accessing the personal data silo. (Identity rights agreements.) | ||
The old architecture, the vendor defined architecture, didn't work because the telco wanted to be at the center. Why is it so hard for me as an outsider? But it wasn't so hard before. That's because vendors have IT departments, and individuals don't. So, perhaps we need an open source IT department to build the big red dot. | |||
XDI has all this in there. But nobody is building it. We need to allow people to use that. | |||
Jiffy Lube, for example, actually has much more information about the car's service needs than I do. So, the smart companies are going to jump on board and support the user. Because the user's IT department is going to build this "bazooka". | |||
In addition to "where's the code". The issue is where are the standards? | |||
Where is the leverage? We need a protocol, we need some software. There are standards that could or could not support aspects of VRM. But where is the leverage point where VRM really has an impact. What seems to be critical is giving users control over their own data, but being able to delegate management of that data by select partners. And you may want to change those relationships over time, without losing the data related to that delegation. The leverage may be in this point of user control over data. | |||
If Netscape had not delivered both a server and browser at the same time, we would have floundered around for quite a bit. We still need somebody to base-line this code. | |||
==Status== | ==Status== | ||
Revision as of 13:30, 16 May 2007
Conference Call Notes
Drafted by Joe Andrieu, May 16, 2007
IRC
- vrm at chat.freenode.net
Prior Conference Calls
Rather than do a standard subscribable podcast the calls are available for the list to download or stream. They are posted as mp3 files and can be accessed as follows:
May 2, 2007
March 21, 2007
March 8, 2007
- meeting notes 2007 03 08
- no audio
February 21, 2007
- no meeting notes
- audio 2007 02 21
February 8, 2007
Attendees
- Joe Andrieu
- Iain Henderson
- Dean Landsman
- Doc Searls
- Keith Hopper
Notes
Skype Simulcast
smarthart
Opening Comments
Lot of action and energy picked up.
Iain Henderson and Alan Mitchell have made good progress with the "flow chart". Many thanks to them.
First IIW Session
Andre Duran, mover behind IDWorld, Jabber, now at Ping Identity. He suggested that we look for particular use cases or applications and connect the dots from the user through to the CRM system or vendor.
Steve Gillmor said largely the same thing. Steve is the father of the AttentionTrust. (Not to be confused with Intention). "Set up strawmen and knock them down."
Paul Trevithick laid out a diagram showing a number of arrows from the user, indicating data stores on one side and on the other side of the line indicating the relatively impoverished data stores living in CRM at the vendors.
This led to the concept of "my red dot" or the personal data silo, which is the user-side store of things such as personal RFPs, digital receipts, transaction histories, affiliations, preferences.
My Red dot
Looking at it from the CRM perspective, we can identify three different pillars: sales, marketing, and customer support. So what does that look like for VRM from the customer perspective.
The Red Dot represents an identity-secure data store controlled by the user. Potential components stored therein: my past purchases, my support history.
Looking at the three pillars, what might a VRM interface look like from a user point of view. What if we pulled all three pillars together into a single interface. Where you can browse (shop), see purchase history, and see support history. What happens today is that we get put into a vendor data store, and when we call in, they get a screen full of relationship data (history). So, for the user, this is a place where this data can be managed/viewed/tracked across all vendors. Whenever I have had a support issue... right now we take notes, scraps of papers, post-its, etc. What if we have a central point to track all of those items digitally, just as CRM systems do for vendors.
My dish network is down. I've been calling them. (Other current topics I'm currently dealing with). Not only could the vendor's get this data, but we could publish this for other customers to view.
For buying, we fill out the query information, in this case for travel. That query goes out to the cloud, modulo identity access privileges, and airfare options come back to the user.
At the lightest level, a personal RFP is basically what we are submitting as queries at Google. (Information RFP). So, how is this data propagating/broadcast/discovered out in the cloud? Is it an RSS/Ping architecture or some other mechanism?
This outline is very conceptual and perhaps too specific.
The top piece (search) just doesn't exist. What that means is that you need a way for aggregating all this information to go back into the red-dot. Vendors could be sending data back, but how does that happen?
So what do we need as vendors? What do customers need?
One caution is building a central anything.
Joe introduced SwitchBook's Search Document concept which is intentionally structured to let users manage multiple search providers in the user context.
So, what technologies are out there that can make this happen?
If this were the web... we are asking for shopping carts at the stage when we are just putting together a website.
What protocols do we need?
At one level, we need to standardize license terms for accessing the personal data silo. (Identity rights agreements.)
The old architecture, the vendor defined architecture, didn't work because the telco wanted to be at the center. Why is it so hard for me as an outsider? But it wasn't so hard before. That's because vendors have IT departments, and individuals don't. So, perhaps we need an open source IT department to build the big red dot.
XDI has all this in there. But nobody is building it. We need to allow people to use that.
Jiffy Lube, for example, actually has much more information about the car's service needs than I do. So, the smart companies are going to jump on board and support the user. Because the user's IT department is going to build this "bazooka".
In addition to "where's the code". The issue is where are the standards?
Where is the leverage? We need a protocol, we need some software. There are standards that could or could not support aspects of VRM. But where is the leverage point where VRM really has an impact. What seems to be critical is giving users control over their own data, but being able to delegate management of that data by select partners. And you may want to change those relationships over time, without losing the data related to that delegation. The leverage may be in this point of user control over data.
If Netscape had not delivered both a server and browser at the same time, we would have floundered around for quite a bit. We still need somebody to base-line this code.
Status
| what | who | when | status |
| ---------- | ---------- | ---------- | ---------- |
| open id on wiki | david | no date | |
| static website development | doc, dean, joe, chris | no date | |
| group blog/RSS to wiki (venus) | doc | no date | up, but only one author |
| project VRM definition | doc | 1 week | still working on it |
| brainstorm Initiatives | all | ongoing | |
| Set up Jabber Host for conference calls | doc | no date | new |
Notes
Agenda
Lot of action and energy picked up.
Iain Henderson and Alan Mitchell have made good progress with the "flow chart". Many thanks to them.
Action Items
| what | who | when | status |