Year: 2005

(n.b. this is a continuation of this discussion)

Armstrong Williams and Ketchum (well commented on here). BzzAgent.

Any difference?

Both situations have an individual being compensated (or having the potential to be compensated) for talking about something. Both situations have a behind-the-scenes intermediary (Ketchum in the former, BzzAgent in the latter) that is itself compensated to have individuals start a conversation. These conversations take place in situations where the other parties in the conversation would typically feel that the commentator is speaking from the heart, and not as part of a part of a program (or under contract). In both cases, the others in the conversation feel duped afterwards, upon learning that an interaction that seemed genuine was actually staged and part of a program of payola.

Despite all the metrics and process, I still feel the BzzAgent model is broken. How to fix?

1) Explicity lose the incentives (per here). If only a small portion of the BzzAgents are redeeming them anyway, what’s the harm? Even if half the current participants drop out, there still are (if the claims are true) many tens of thousands of people who are participating.

2) Require disclosure. When BzzAgents are buzzing, anything less than stating (either verbally or in writing, if blogging, etc.) “By the way, I’m a volunteer part of an organization that’s getting compensated to promote this product, and I will be writing a report on it at some time in the future,” is disingenuous. Just say it. The Marqui people do. (I’m not thrilled with the Marqui model, but I do respect their upfrontedness about it.)

3) Aggressively change the meaning of the word “agent.” For this to work, “agent” needs to mean “agent, as in catalyst,” not “agent, as in shady operative.”

Communication is good. An increase in interpersonal interaction is good. Making money is good. But doing the first two as a means to the third without disclosing it is a good way to rile up a lot of hornets. And that’s not-so-good.

Mike Pusateri, the customer who is at the heart of the so-called wiki war nails it.

“The point isn’t what software we are using, but can we get people to use wikis at work? I tell ya folks, it ain’t easy to wean people off of email…”

90% of the time, the real “competitor” isn’t the company that just put out the press release. 90% of the time, the real competitor is inertia.

Got an email yesterday from Brian Dear, of brianstorms.com:

“Hi Chris…Big fan of your Social Customer Manifesto blog here…Just went through a delightfully awful customer experience with Intuit. Blogged the whole thing, thought you might find it amusing.”

Indeed! Brian blogged his whole convoluted experience trying to get his QuickBooks Pro 2005 “Slowbooks Amateur 2005” up and running, including a hysterical* exchange with a customer service rep who sounds like a cross between Jeff Spicoli and Patient Zero. The comments indicate that Intuit may have lost a potential customer or three based on Brian’s experience.

Then, not 10 minutes after reading Brian’s account, I’m listening to Adam Curry’s Daily Source Code for 18JAN2005. He not only talks about his ongoing hassles with British Telecom (BT) and EasyNet in getting the last 15m of wire put in place so he can get broadband, but records and podcasts the entire conversation with EasyNet customer service. (Click on the MP3 link; the EasyNet conversation starts at about the 4:50 mark in the recording.)

What does this mean? It means that the barrier to entry of publishing…be it via blogs, web pages, podcasts, what have you…has gotten so low that customers, at any time, can share exactly what their experiences are with the vendors with whom they are working. Not only that, but these experiences become persistent and searchable, sometimes to the point of being more visible than the contrivances the companies themselves are putting out.

Warms my heart, this does.

* – well, hysterical if you’re into schadenfreude, that is…

Adam Curry and Doc Searls slag on the iPod shuffle and its appropriateness as a device for listening to podcasts. In an article today in InternetNews, Doc comments on the device:

“It’s neither a boon nor a bust. It’s just not useful for listening to podcasts. Navigating inside a long podcast — and many are very long — is difficult even with a regular iPod, as it is with all players. So, rather than fix the one feature that’s lame about the iPod, they eliminated it completely.”

Adam echoes the sentiment.

“Apple hasn’t picked up on podcasting because they are thinking about how things work from Apple to the rest of the world. They are not seeing what is happening.”

Adam, Doc…I respect the hell out of both of you. But blaming the device is only looking at half the problem.

The other half of the problem is in the structure of the podcasts themselves. When a broadcaster podcaster constructs a long, monolithic podcast of, say, forty minutes or so, it is a black box. It is monolithic. The only current way around this is to create detailed “show notes” to give the listener (who is your customer, btw) some visibility into the inside of this black box. This is the core of the problem, not the device. This currently needs to be done separately from the podcast.

Let’s take a step back, and look at another example of monolithic content that is delivered digitally…DVDs. The DVD makers figured out early on that they needed to break their creations into “scenes” to make them navigable. Podcasters need to do the same thing.

Three solutions:

• The pragmatic one: Podcasters…break a monolithic ‘cast into parts, and post them separately. More work on your part, but solves the problem. And its doable today.
• The midrange one: Create a way to easily bundle the monolithic content with a cue file or the equivalent that tells where things are. If a customer is interested in better navigation, the customer can split the podcast based on the cue file prior to loading it to a device.
• The long range one: After the podcasters do their part to indicate the cues, Apple, Creative and others build devices that take into account the bundled MP3 and cue files, and allow random access navigation.

To dismiss the device is only looking at a small part of the issue. The onus is just as much on the creators of the content to provide clearer navigation clues into the things that they are creating.

(hat tip: nevon)

Update: Come to think of it, the midrange option could be handled inside of iPodder, iPodderX, or Doppler as well, I s’pose. Have the podcatching client split up the podcast on its way in, based on the cue file, and then automatically write out the component parts for easier navigation.