<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"
	>
<channel>
	<title>Comments on: VRM linkage and thinkage</title>
	<atom:link href="http://blogs.law.harvard.edu/vrm/2008/05/31/making-sense-of-vrm/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.law.harvard.edu/vrm/2008/05/31/making-sense-of-vrm/</link>
	<description>Developing tools for customer independence and engagement with vendors</description>
	<lastBuildDate>Sun, 29 Nov 2009 13:12:02 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Simon Edhouse</title>
		<link>http://blogs.law.harvard.edu/vrm/2008/05/31/making-sense-of-vrm/comment-page-1/#comment-3555</link>
		<dc:creator>Simon Edhouse</dc:creator>
		<pubDate>Mon, 02 Jun 2008 06:25:32 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/vrm/2008/05/31/making-sense-of-vrm/#comment-3555</guid>
		<description>Doc, yes it can be done, and do I have suggestions? You bet! That mission among other objectives is &lt;i&gt;exactly&lt;/i&gt; my focus. However, I am instinctively wary of opening up this kind of process to broad public scrutiny. (for many many reasons) I just see that as an inherently non-strategic approach. ~ As Geoffry Moore says: &lt;i&gt;&quot;Becoming the de facto standard, can never be reached directly.&quot;&lt;/i&gt;</description>
		<content:encoded><![CDATA[<p>Doc, yes it can be done, and do I have suggestions? You bet! That mission among other objectives is <i>exactly</i> my focus. However, I am instinctively wary of opening up this kind of process to broad public scrutiny. (for many many reasons) I just see that as an inherently non-strategic approach. ~ As Geoffry Moore says: <i>&#8220;Becoming the de facto standard, can never be reached directly.&#8221;</i></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Doc Searls</title>
		<link>http://blogs.law.harvard.edu/vrm/2008/05/31/making-sense-of-vrm/comment-page-1/#comment-3553</link>
		<dc:creator>Doc Searls</dc:creator>
		<pubDate>Mon, 02 Jun 2008 03:56:43 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/vrm/2008/05/31/making-sense-of-vrm/#comment-3553</guid>
		<description>Simon, my own idea of a personal RFP has never either a &quot;personal preference&quot;, &quot;a virtual surrogate&quot;, or &quot;a shopping-cart traveling between sites&quot;. Instead I&#039;ve thought of it as a simple notification to the market of an intention to buy X. For example, yesterday I wanted a 220/110 voltage converter here in Amsterdam. I would like to have issued a personal RFP for that, without going to anybody&#039;s silo, and without having to go -- or have a surrogate system go -- from site to site looking for that kind of device. I want one or more vendors to to respond to my demand for that device.

How would we do that? I have ideas. Alec Muffett has &lt;a href=&quot;http://docs.google.com/View?docid=df9dfsgj_1ghhqgjfq&quot; rel=&quot;nofollow&quot;&gt;ideas&lt;/a&gt;. Other ideas are out there, but I can&#039;t find them right now because my €22/day hotel connection here in Amsterdam is too slow and flaky, and I have too much else to do.

But I would like us to take up the challenge of NOT doing the personal RFP within the client-server model of the Web. Can that be done? Got some suggestions?</description>
		<content:encoded><![CDATA[<p>Simon, my own idea of a personal RFP has never either a &#8220;personal preference&#8221;, &#8220;a virtual surrogate&#8221;, or &#8220;a shopping-cart traveling between sites&#8221;. Instead I&#8217;ve thought of it as a simple notification to the market of an intention to buy X. For example, yesterday I wanted a 220/110 voltage converter here in Amsterdam. I would like to have issued a personal RFP for that, without going to anybody&#8217;s silo, and without having to go &#8212; or have a surrogate system go &#8212; from site to site looking for that kind of device. I want one or more vendors to to respond to my demand for that device.</p>
<p>How would we do that? I have ideas. Alec Muffett has <a href="http://docs.google.com/View?docid=df9dfsgj_1ghhqgjfq" rel="nofollow">ideas</a>. Other ideas are out there, but I can&#8217;t find them right now because my €22/day hotel connection here in Amsterdam is too slow and flaky, and I have too much else to do.</p>
<p>But I would like us to take up the challenge of NOT doing the personal RFP within the client-server model of the Web. Can that be done? Got some suggestions?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon Edhouse</title>
		<link>http://blogs.law.harvard.edu/vrm/2008/05/31/making-sense-of-vrm/comment-page-1/#comment-3552</link>
		<dc:creator>Simon Edhouse</dc:creator>
		<pubDate>Mon, 02 Jun 2008 01:23:20 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/vrm/2008/05/31/making-sense-of-vrm/#comment-3552</guid>
		<description>If VRM does not fundamentally operate within the legacy client-server model of the Web, then on what medium does a &quot;personal RFP&quot; flow? A personal preference encoded RFP is a virtual surrogate of that user, and a shopping-cart traveling between sites is a vehicle on that web. (BTW, I am a supporter, but I like to focus on real potential problems rather than get swept up in hype and hubris) Problems as I see them: 

1. GAMING: That RFP is a mighty attractive package to game. 

2. COMPLEXITY: If a user has to send an RFP for every type of commercial mission they want to accomplish, which requests a &#039;quote&#039; which then has many provisos like &#039;price, freight, tax, to negotiate and or innumerable other prerequisites, and &lt;i&gt; &quot;Should this transaction not complete successfully, the requesting partner executes PIP0A1, &#039;Notification of Failure.&#039;&quot; &lt;/i&gt; ...well then you have a recipe for considerable congestion and malfunction, as Colin Henderson from &#039;Bankwatch&#039; states: 
&lt;i&gt;&quot;The complexities with VRM related to the various possibilities make the size of VRM almost impossible to imagine.&quot;&lt;/i&gt;

3. JINXING:  the publicity around VRM forewarns and attracts the attention of CRM advocates before the mass audience is remotely aware of the idea, i.e. &#039;mycustomer.com&#039; writing editorials with titles like: &quot;Vendor Relationship Management: CRM threat or opportunity?&quot;

4. ADOPTION: As Christopher Carfi points out: &lt;i&gt;&quot;Remember that little &quot;R&quot; thing in the middle of both CRM and VRM? The one that says &quot;relationship?&quot; Finding a better way to have vendors compete solely on price does not a relationship (or even a conversation) make. &lt;/i&gt;</description>
		<content:encoded><![CDATA[<p>If VRM does not fundamentally operate within the legacy client-server model of the Web, then on what medium does a &#8220;personal RFP&#8221; flow? A personal preference encoded RFP is a virtual surrogate of that user, and a shopping-cart traveling between sites is a vehicle on that web. (BTW, I am a supporter, but I like to focus on real potential problems rather than get swept up in hype and hubris) Problems as I see them: </p>
<p>1. GAMING: That RFP is a mighty attractive package to game. </p>
<p>2. COMPLEXITY: If a user has to send an RFP for every type of commercial mission they want to accomplish, which requests a &#8216;quote&#8217; which then has many provisos like &#8216;price, freight, tax, to negotiate and or innumerable other prerequisites, and <i> &#8220;Should this transaction not complete successfully, the requesting partner executes PIP0A1, &#8216;Notification of Failure.&#8217;&#8221; </i> &#8230;well then you have a recipe for considerable congestion and malfunction, as Colin Henderson from &#8216;Bankwatch&#8217; states:<br />
<i>&#8220;The complexities with VRM related to the various possibilities make the size of VRM almost impossible to imagine.&#8221;</i></p>
<p>3. JINXING:  the publicity around VRM forewarns and attracts the attention of CRM advocates before the mass audience is remotely aware of the idea, i.e. &#8216;mycustomer.com&#8217; writing editorials with titles like: &#8220;Vendor Relationship Management: CRM threat or opportunity?&#8221;</p>
<p>4. ADOPTION: As Christopher Carfi points out: <i>&#8220;Remember that little &#8220;R&#8221; thing in the middle of both CRM and VRM? The one that says &#8220;relationship?&#8221; Finding a better way to have vendors compete solely on price does not a relationship (or even a conversation) make. </i></p>
]]></content:encoded>
	</item>
</channel>
</rss>
