There is no doubt that Social CRM is the future for traditional CRM. CRM tools are swarming to build functionality to monitor your brand across the various social networks. There are lots of great blog articles out there discussing this topic, including posts by Jeremiah Owyang (”The Future of Twitter: Social CRM”), Brent Leary (”Social CRM in Pictures….and Words” and “Social CRM: Not Your Father’s Customer Relationship Management“) and many others. I really like Brent’s definition of Social CRM which is as follows:
“Social CRM adds a whole new dimension to the traditional view of customer relationship management. The focus is undoubtedly on people and not technology. It’s about joining the ongoing conversations our customers and prospects are already engaged in — not trying to control them.”
The key statement to me from Brent’s post is about joining ongoing conversations and the value in building relationships. However, what is missing here is the fact that this is still CRM, social or not. The ultimate goal is to manage your customers, partners, etc. to obtain the most value you can out of that relationship and to build that 360 degree view of the customer. Don’t get me wrong. CRM has value. Social media needs a different approach, though. Companies should come to these conversations as participants and not overseers using tools to monitor the social networks to help fix a customer’s problem or clean-up after a PR debacle. The real answer is to give users the tools to manage these relationships and not just the organizations themselves. Users should have the capability to share information with their vendors on their terms and not the vendor’s terms. These tools should still give vendors the ability to easily participate in those conversations and extract the value needed from them, but I do not see the same value for Twitter providing the Social CRM capabilities that Jeremiah outlines. Twitter’s value comes from the users and not the brands. Twitter should instead focus on providing improved capabilities for users to be able to express their preferences and issues. Admittedly, I’m still not sure how you monetize this any more that what they have now, though.
So, is this Vendor Relationship Management (VRM)? Doc Searls leads ProjectVRM at Harvard University to support the development of VRM tools and methodologies. Wikipedia defines VRM as:
“VRM, or Vendor Relationship Management, is the reciprocal of CRM or Customer Relationship Management. VRM describes a set of tools, technologies and services that help individuals go to market and manage relationships with vendors. In turn, vendors who align themselves to these tools, technologies and services will have the opportunity to build better relationships with their customers.”
Sounds like it. Or does it? VRM advocates putting tools in the user’s hands. VRM also describes transactions, relationships, conversations, user-based control, etc. Paul Greenberg presents a good case for VRM and Social CRM being the same thing in his “Vendor Relationship Management: Jumpin’ On The Three Wheeled Bandwagon” post. VRM, however, has its own set of challenges. In Graham Hill’s post on “Four Fallacies of Vendor Relationship Management” he outlines a strong set of reason why VRM is overly extreme. Ultimately it comes down to the management of information and whether or not the VRM economic model works. So, perhaps VRM is not the answer for social media either. This makes sense if Social CRM is the same as VRM as Paul describes.
So what capabilities really are needed for social media tools so that both users and organizations can get the most value. Here is my high-level feature list for this new type of tool:
- Designed for users and not organizations
- Organizations should be equal participants in the conversations and not observers
- Inherently free so that everyone can gain value with value-added services provided on top of the core system
- Exposes interfaces so that organizations can extract data approved by the users
- Social network independent
Perhaps this is what Graham calls “Customer Managed Relationships?” I’m not sure. I do know that this type of tool needs to focus on collaboration more than just relationship management. Perhaps the best name for this is Social Collaboration Management instead.
Todd
Posted by: Todd Clayton | April 28, 2009 | | categories: Social Media | tags: Collaboration, reputation, social CRM, Social Media
While Twitter provides a great platform for global information, how do you get to just the subset of information relevant to your local area. The answer is a system of Twitter distribution hubs (a.k.a. spoke-hub distribution paradigm). The idea is not a new one. Distribution hubs are used across the board for a multitude of purposes, including airline flight patterns, shipping, networking and many other reasons. According to Wikipedia, this distribution model is defined as:
“The hub-and-spoke distribution paradigm (or model or network) is a system of connections arranged like a chariot wheel, in which all traffic moves along spokes connected to the hub at the center. The model is commonly used in industry, in particular in transport, telecommunications and freight, as well as in distributed computing.”
Wikipedia uses this picture as the way to show how this works for airlines. So, in this example Denver serves as the hub for getting to and from place that do not have direct connections.
Twitter does not have a direct model for creating these types of relationships, but it does have a virtual way of setting up distribution points- search and hash tags. While Twitter’s search operators page at http://search.twitter.com/operators lists two operators that could apply (near and within), those work in the opposite direction. “Near” finds all Tweets sent from a specific area and “within” constrains the search to a specific distance away. This would be interesting for an aggregation approach, but since we are trying to distribute messages to the spokes and not consolidate messages from the spokes, we need a different approach.
Fortunately, a standard has emerged around using hash tags (#some_topic) which allow people to find things around a common topic without having to follow a specific handle to be notified of the information. You can then use Twitter search to find all messages related to that topic. While not as convenient as near and within, a hash tag model could be applied to describe messages destined for specific areas. You could also tack on other tags to further refine the distribution path. Since these tags are currently freeform, a standard would be needed to ensure that everyone leveraged common formats for the tags. The critical piece here is that Twitter searches can be made into RSS feeds. So, I can easily set up a search for a specific hash tag and am notified when a new item matches that search.
So, how would this work. The first step would be to establish a set of hub information providers. Next, you would establish a set of Twitter searches based upon a hash tag specific to each spoke. Using a tool like RSS to Twitter (no affiliation) you could feed the results of those search to Twitter handles specifically set up for the spoke location. Users could follow the spoke to then be notified of the specific items of interest.
There are a multitude of sample uses for this type of a model (e.g. local advertising), but a more interesting use could be to create a localized emergency broadcast system for things like Amber alerts, weather emergencies, or other types of local notifications. The system would look something like this:
An organization like the Homeland Security Department would operate as the hub sending a stream of messages tagged appropriately for distribution. The messages could embed links and pictures for longer text or photos of missing children, persons of interest, etc. Local agencies would then follow the spoke accounts to get the subset of information relevant for that specific area.
The benefits of this approach include the following:
- Notification logic can be centralized to a single point of access which simplifies distribution
- Instant global reach
- Little development is required to integrate with Twitter
- Twitter is easily accessible by mobile devices
- Content can easily by filtered down to a specific interest areas
There are a few drawbacks to this approach. The main drawback is the stability of Twitter itself. Without a reliable mechanism for distributing these messages the usefulness of leveraging Twitter in this fashion is extremely limited. The second drawback is that spoke-to-spoke (or point-to-point) messages can not easily be sent directly since all communication flows through the hub. Fortunately, Twitter provides an easy mechanism to forward messages. A spoke could send a message back to the hub with a hash tag for another location. The hub would then re-tweet the message and it would be picked up by the other spoke. Another thing to keep in mind is that traffic would be bottlenecked by the hub account. So, if things like API limits were not lifted, message distribution could be delayed. Additionally, without a standard for hash tags, coordination across the network would incur a high level of overhead.
Overall, this is another idea to keep in mind when looking at notification systems. Email and automated phone calling have already greatly improved response times and awareness of incidents. Leveraging Twitter in this model is yet another improvement.
Todd
Posted by: Todd Clayton | April 21, 2009 | | categories: Social Media | tags: Distribution, Social Media, Twitter
As the web moved more towards mash-ups and other forms of heterogenous applications, there is a need to reliably send messages between these applications leveraging a common interface. While there are services out there that provide Internet-based message queuing, like OnlineMQ, cloudMQ, Amazon Simple Queue Service and others, I think another mechanism is staring us in the face. In looking at Twitter and how tweets are distributed and queued, in essence this really could be a Collaboration Message Queue. Twitter is mainly focused on human interactions. Could it be used as a platform for non-human collaboration?
Wikipedia defines a message queue as follows:
“… a message queue is a software-engineering component used for interprocess communication or inter-thread communication within the same process. It uses a queue for messaging – the passing of control or of content. Message queues provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them.”
Twitter definitely provided the component necessary to use it as a message queue:
- RESTful API
- Ability to send short messages
- Messages can be broadcast to all listeners
- Messages can be replied to or directed to specific listeners
- Messages are queued until picked-up by the listener
- (Very) limited security in that updates can be kept private to only specifically approved listeners
- Ability to search messages (may or may not matter)
“Listeners” above would normally be referred to as “followers” for human collaboration.
So, what would a Twitter-based Collaboration Message Queue look like:
Each application leverages the Twitter API to speak with Twitter. The sending application authenticates to Twitter and initiates a conversation. The conversation can be broadcast to all of the listeners, sent specifically to one listener using an @reply/mention or sent privately to one listener using a direct message. The receiving application also authenticates to Twitter and checks for messages in its queue. Those message can then be read off the queue. Since the order of the messages in maintained, asynchronous communication is possible. Since there are multiple services that integrate with Twitter for sending binary information (think TwitPic) those API’s could also be leveraged to send non-text based messages.
A use case for this might include using Twitter as a way to federate site communication. If, for example, you have an application that sits out at your customer site and want an easy way for your application to send and receive inter-application messages, the Twitter API provides an extremely easy mechanism of accomplishing this. In the example of a workflow-based application, perhaps you want to assign a task outside of your company to a partner also using the same software. The application could send the task into the receiving application’s Twitter queue. The receiving application could then acknowledge the receipt of the task with a response and easily communicate back when the task is completed. Since the application would use the same language, each site is able to establish a dialog with the other sites.
To implement this type of model, each participant application would do the following:
- Register a Twitter handle
- Mark their updates as private
- Each new participant follows the initial participant
- The initial participant accepts the follow and follows the requesting participant back
The participants can now send messages into each other using the mechanisms called out above. Additionally, all participants will see broadcasts across the system. Using re-tweets, conversations happening between specific participants could be forwarded on to other participants allowing certain participants to act as distribution hubs.
I am unsure as to the usefulness of this approach. While this allows non-humans to collaborate with little new code, message limits of 140 characters and the fact that conversation security is limited lessen the overall value. Messages longer than 140 characters could be broken down and chunked across multiple messages. Since order is maintained, the listener could put the message pieces back together relatively simply.
I’m fairly sure that Twitter will mainly be a human collaboration platform, but if they’re looking to find some other ways to leverage their infrastructure, you never know. Maybe non-human social networks are the future.
As always, I would love to hear your feedback.
Todd
Posted by: Todd Clayton | April 18, 2009 | | categories: Social Media | tags: Development, Social Media, Twitter
Hi Everyone,
Today, Jeremiah Owyang created a post issuing a challenge to developers to create a crowd managed feed reader:
http://www.web-strategist.com/blog/2009/04/11/developer-challenge-create-a-crowd-created-feed-reader
I’m glad he did. We’re definitely thinking the same thing. Jeremiah outlines the following pain point:
“Finding people on Twitter, then following them is already a challenge. Sharing your hard earned list takes time. I deal with a lot of executives at companies, that want to quickly scan the topics in their industry, or see what their employees, customers, and competitors are doing. Searching by keyword isn’t sufficient. Carter Lusher has this large Twitter list of analysts, but in order to see their streams, adding each one is a manual process.”
A ChatterBox allows just this capability. When configuring a ChatterBox, you can define a list of interesting topics and can filter those topics to a set of Twitter handles. You can then invite other users to participate with you in the ChatterBox. Not only can those participants respond back right to Twitter right though the ChatterBox, but the threaded conversations can also be assigned, categorized, tagged and put into workflow.
Once the ChatterBox is created, users can create their own custom views and RSS feeds into the information. Individual users can create an unlimited number of ChatterBoxes. So, you can create one ChatterBox to follow a set of concepts/handles and another to interact with your business partners to respond to tweets through a common process.
Jeremiah Outlines the following use cases (in quotes):
“I want to track all analysts in my industry, then I could [give] my executives a single URL so they can observe”
Yes, we do this out of the box. Additionally, you could create a view/RSS feed for that executive and assign them the ones they should read so that they do not need to filter through the full list.
“give a sales rep a single webpage to see all the tweets coming out of their client”
We also do this out of the box.
“professional to quickly track all their industry counterparts tweets”
Again, we do this out of the box. We also let the professional tag, categorize and archive the tweets so that they can be viewed and searched at a later point in time.
We think there are some other interesting use cases, including:
- PR agency that wants to set up a shared workspace with their client as part of their social media program.
- Team that wants to easily share the responsibility of responding to tweets.
ChatterBox capabilities like assignment and prioritization can also be used to better streamline management of responses. The are many more use cases, many of which we can’t wait to learn when our users come up with them.
Jeremiah also lists some required features (in quotes):
“Allow anyone to create a public stream of Twitter users, later it could evolve to include blogs and articles.”
We will allow users to create a stream of tweets that can be shared amongst ChatterBox users. The stream itself will not be public, but it could potentially be in future releases. Adding other content sources for elements that can be pulled into a ChatterBox is high on our list of priorities.
“It should allow members to submit themselves to these lists, or allow anyone to volunteer others.”
The ChatterBox creator (moderator) can invite others into the collaboration space in the initial release. We don’t have an option for other people to submit or volunteer other members. That could be added if it becomes highly requested.
“Have administrative controls.”
Yes, we have administrative controls although they are limited in the first release. This is an area we will focus on enhancing.
“It should be public.”
We won’t have fully public facing information available in the initial release. We are thinking about pages for public facing information, like latest updates, status and background information.
“Be easy to use.”
We hope so, but we’ll really know when users start providing feedback.
“Have further features that allow very large feeds to segment by a variety of filters perhaps by location, popularity, and other metadata.”
ChatterBox will have meta-data capabilities for assignment, categorization, prioritization, status and tagging. All of those values are configurable. Other data elements could be tracked as tags or through future potential enhancements.
“Aggregate then prioritize. Feeds on their own are a bit messy, if you’re not in front of in real-time you may miss something. This feature should bubble up the most important tweets based on popularity or weight.”
Yes, we agree. We won’t be there from day 1. It’s definitely something on our radar, though.
Please check out Jeremiah’s post. We’re very excited by the vision he outlines for this type of solution. ChatterBox will be here soon and we can’t wait for you to start using it and providing feedback. I’ll definitely keep you updated on our progress. We would love to hear your ideas as well!
Thanks for the time!
- Charlie
–
Charlie Chatterbox
Celebrity Mascot
Posted by: charlie | April 11, 2009 | | categories: ChatterBox Info | tags: ChatterBox, crowdsource, Social Media
Here is the third and final post on my proposed model for using a virtual directory to create social graphs. It only took a couple bunches of bananas to get Charlie to let me finish my post. It seemed like a good bargain.
In Part 1, I presented the case for using a virtual directory to integrate social networks for the identification and representation of relationships. In Part 2, I presented the value of virtualizing social networks.
In this final installment, I wanted to present a theoretical use case for a fictional company called, MyNewsBox which allows users to find interesting news tidbits from across the internet and store them in a suitcase for reading at a later point in time. They have been reading a lot about social media and decided that they would like to extend the capabilities of their existing application to make it more “Web 2.0“. They also have a new application in the works that will allow user to set up projects and track the dependencies between the projects so they are able to get a quick view how project changes impact the overall delivery of their broader program.
MyNewsBox identified the following requirements:
- Allow users to find interesting stories across Twitter and Facebook and add them to their news box
- Create the ability to share news items with other users
- Recommend other news items that the user might find interesting
- Suggest other users with similar interests and allow them to subscribe to their news box
- Easily add new networks without have to make major application changes
- Create a framework that can be leveraged for new application development efforts
After spending several weeks investigating similar applications, they settled on the following interface design:
The new interface highlights the connections between the the user and their stories, suggests new stories and also recommends new friend connections. MyNewsBox decided to approach the new application changes by creating a base framework that managed the connections and relationships between users. They based the framework on top of a virtual directory. Since they already had user information in the system, they saw additional value in that the virtual directory allowed them to access existing local information and new information from the social networks all through a single point. MyNewsBox then used the Java API’s to build basic connectors for Twitter and for Facebook. They then updated the application to provide the option for their users to enter the Twitter and Facebook identities into MyNewsBox. Through explaining the value of the new features, MyNewsBox hopes to be able to get a significant number of users to add the additional account details.
Once the user information for Twitter and Facebook is collected, MyNewsBox created views into the information which allow the application to make three queries:
1. Find users on the system who have friends in common on Twitter and Facebook, but are not yet connected on MyNewsBox.
2. Find people who have similar interests defined on Facebook so that the news stories that they have saved can be recommended to other users with common interests.
3. Return Facebook interests for a user so that when a user searches for new stories on Twitter, those Facebook interests can be used as keywords.
These views were both created in the virtual directory and made available so that any application could easily obtain this information by making a SQL call to the virtual directory. Since the business logic is based upon configuration in the virtual directory, nothing needs to change in MyNewsBox once Twitter starts letting users tag their interests and types of relationships. After creating their social network virtualization framework, the application changes required were very minor and mostly consisted of user interface updates to show the new information being queried from the virtual directory.
After gauging the success of the changes to MyNewsBox, they started work on the new project dependency application. One of the key requirements for the new application was to create communities for people working on common projects. They felt that LinkedIn provided an easy way to identify users of the same company and show them a view of all of the projects going on at that company. The users would then be able to send a notification requesting access to the project. Instead of building a standalone connector for the new application, MyNewsBox added this connection through the virtual directory. After adding LinkedIn, they created a new view which the project dependency application used to determine common connections within the same company. After adding this connection, MyNewsBox was also able to take advantage of this new information in their existing application simply by adding the ability for users to define their LinkedIn account information and by updating the views in the virtual directory to include the new business logic. No other application changes were required. MyNewsBox was able to also activate the persistent cache in the virtual directory to deliver this information across all of the social networks with a high level of performance. Since the cache was a configuration on the virtual directory, no coding was needed to take advantage of this improved performance.
Hopefully this helps to explain why adding an social network abstraction layer through a tool like a virtual directory is an interesting approach. Thanks for taking the time to read through this information. I would love to hear your feedback.
Thanks,
Todd
Posted by: charlie | April 8, 2009 | | categories: Social Media | tags: identity, Social Media, virtual directory, virtualization
Hello again! I guess Charlie is in a generous mood. He decided to let me post Part 2 on using a virtual directory to create social graphs. Yesterday in Part 1, I presented the case for using a virtual directory to integrate social networks for the identification and representation of relationships.
Here was the model I presented:
Real-time searches of the networks for user information are possible by hooking the virtual directory connectors up to the various social networks. By allowing users to setup their own accounts, you can ensure that the data is accurate and that users have opted-in to having their information included. Attributes of the correlated user identities are used to represent the relationships and types of relationships that user has in the context of the configured social networks. User information can then be pulled together across the social networks creating a unified profile in the virtual directory. These profiles allow applications to derive the links between the defined accounts and others with accounts defined in the virtual directory by crawling the relationships to contextually understand the users’ relationships.
So the next question and the focus of this post is what value a system like this would bring. Jeremiah Owyang has a nice post outlining how to explain the social graph:
http://www.web-strategist.com/blog/2007/11/10/what-is-social-graph-executives/
In the post he outlines the following benefits:
“Users: For users this means efficiency and control over one’s personal data, their relationships, and how they are deployed on different social networks, it makes navigating the web better.
Social Networks: For companies that are social networks, they can benefit by increasing the amount of users as the social graph will populate all of a users network they permit.
All other websites: For companies that are not currently social networks, (like a corporate website) expect these social features to be part of your site. People will co-surf and share information about your content whether you like it or not.”
Creating this model in the virtual directory provides a significant advantage for companies building applications for both internal and external consumption. All applications can leverage the virtual directory as a hub both for the creation and retrieval of account information and to easily understand the relationships between the registered users. New applications can instantly take advantage of this information to make recommendations for interest-based connections to other users and display targeted information. The virtualization platform creates an extensible model for building viral applications without each application having to understand the underlying social networks. This model also lends itself to being able to layer on additional services like single sign-on and federation (e.g. Facebook Connect). As I browse across the various sites, identity information relevant to the network can be presented allowing me immediate access into the system without being re-challenged.
As we move more towards an interconnected world, the value of virtualization becomes more significant. Companies will need the capabilities to quickly leverage new social networks and to easily allow users to collaborate across networks and to participate in those conversations.
Any additional ideas or feedback would be appreciated. In Part 3 I plan on covering a possible real-world use case for this type of a solution.
Thanks,
Todd
Posted by: charlie | April 7, 2009 | | categories: Social Media | tags: identity, Social Media, virtual directory, virtualization
Hello again. Well, I’d like to introduce one of my assistants, Todd. He stopped by to talk about how the same principals that can be applied to identity virtualization can also be applied to social network virtualization. I don’t like to let him out much, but I figured that one post here every so often can’t be that bad. I’m curious to hear what you think… In any case everyone say hi to Todd!
- Charlie
Thanks Charlie for the introduction. As I thought about identity virtualization and how CoreBlox used virtual directory technology for our Identity and Access Management (IAM) projects, it seemed this same logic could be applied to social network virtualization. There are several virtual directories out there, but for the purpose of the post I am going to use RadiantOne from Radiant Logic as the way to describe virtual directory technology.
Identity virtualization means the following to me:
- Layer of abstraction between identity consumers and identity providers
- Allows for mapping and correlation of identity information (e.g. one user identity across many systems)
- Application oriented views of identity information (e.g. what systems can be accessed by the user, and what permissions does the user have in each system)
When virtualization is applied to social networks, this is often referred to as a Social Graph. A good description of social graphs can be found on the ReadWriteWeb (RWW) site:
http://www.readwriteweb.com/archives/social_graph_concepts_and_issues.php
This is related to a post by Brad Fitzpatrick here:
http://bradfitz.com/social-graph-problem/
While these articles are a little on the older side, I think they are still fairly relevant. RWW defines a social graph as:
“Our society spawns one gigantic social graph. In this graph, each one of us is a node. There is an explicit connection, if we know each other. For example, two people can be connected because they work together or because they went to school together or because they are married.”
While there are API’s for constructing social graphs (Google’s: http://code.google.com/apis/socialgraph/), the virtual directory already has all the pieces necessary to identify and understand these relationships. To steal from an image I used in a recent presentation I did at TEC 2009, you can visualize identity virtualization as follows:
So, the virtual directory allows you to apply the following functions to populations of users:
Aggregation: Bring the user populations together so that they appear as the superset of all of the user populations. This creates one view of the users and surfaces this information through one access point (or protocol).
Correlation: Determine the union of the various user populations. So, by taking common attributes you can create the unique identity that represents a user across all of the populations.
Integration: Understand the context of identity information. This gives you that “Single version of the truth” that allows virtual directories to link back to the identity providers in the right context and the right process by fully understanding the relationships between the identities.
So, if we applied this same logic to social networks, the virtual directory can bring those relationships between users to light simply by leveraging capabilities that are already embedded in these products. The diagram for this might look something like this (the virtual networks listed there are just to show a sample of what could be included):
In this model, aggregation is accomplished through defined connectors into the various social networks to show the overall population across the networks. Since the enormous user populations would make viewing all identities across these networks impractical, you could instead provide a means of searching for a given user’s information in real-time.
Similarly, correlation is delivered through account mapping where each user defines their accounts across all of the social networks in which they participate. Allowing users to setup their own accounts ensures that the data is accurate and also allows users to opt-in by creating only the accounts that they would like to have included.
Finally, integration represents the relationships that a user has to other users on the subscribed social networks and, if possible, an indicator as to the type of relationship. So, for Facebook this would be my friends, for Twitter my followers and those that I am following, and on Flickr my friends and family.
Once I have this information and the mappings are defined in the virtual directory, I can easily use it to pull together information about people across those networks. Basically my account mapping gives me a unified profile in the virtual directory, which can be used to pull in information about me from each of my subscribed networks. I can also derive the links between the defined accounts and others with accounts defined in the virtual directory by crawling the relationships. For example: if I select three people from the virtual directory with Facebook accounts, I can view the friend lists for each of those people. If I see that person A has a relationship with person B and person C has a relationship with person B, I can then start to understand the links between all of the users. Finally, my defined interests on each of the social networks allow me to understand the context that I have both to the networks and to other users of the system. So, if on Facebook person A has interests in Apple and Skiing and on LinkedIn person A has interests in Social Media and IAM, I can relate the unified identities to other unified identities based upon their defined interests and their specific social network link. All of this information can be represented as my attributes in the virtual directory.
Data in the virtual directory is exposed through various protocols. So, applications could access this information through LDAP, SQL, or by making web service calls to pull the information needed to display the social graph. Leveraging the abstraction of the virtual directory allows the viewer to structure the data relationships by different attributes without modifying the underlying structure of the data itself. Additional social networks can be added in (or removed) on the fly without changing the consumers of this information. Since the virtual directory also provides LDAP’s model of security, its information could be secured at a fine-grained level of access which could help to alleviate privacy concerns with access to this information.
Due to the sheer volume of the information available across social networks, it would need to be shown that virtual directory technology can scale to this amount of data and to the complexity of the joins required to create views into the various relationships. Leveraging the caching capabilities of the virtual directory should help, but a proof-of-concept would highlight where there are limitations.
Hopefully this provides a solid overview of the approach. I am definitely interested in hearing feedback and ideas. I will post additional information as we gain more clarity into this approach.
In Part Two I will follow-up with some additional details on ways of putting this type of a system to use (assuming Charlie will have me back!).
Thanks,
Todd
Posted by: charlie | April 6, 2009 | | categories: Social Media | tags: identity, Social Media, virtual directory, virtualization
Well, one of my assistants tipped me off to an interesting debate going on between 37signals and Get Satisfaction. You can find the details here:
http://www.37signals.com/svn/posts/1650-get-satisfaction-or-else
To summarize and over simplify, 37signals is mad because Get Satisfaction had a page out there where people were asking questions about their products. It was not obvious (enough) to some that this was not an official channel for support from 37signals and as such 37signals reputation was damaged because of this. They’re probably right.
However, should we be surprised? You could easily substitute Twitter, Facebook, MySpace, etc. and the post would have looked exactly the same. The reality is that people will talk about you, your company, your products, etc. whether you like it or not. The answer is not to try and control these conversations, but to effectively participate in them. You need tools to better manage these conversations regardless of the platform. I am not at all ashamed to tell you is this is exactly what we are trying to help you do. With ChatterBox we want to let you find these conversations and participate even if it is not coming through an official channel.
There are a lot of comments on the 37signals post on both sides. It is worth a read. Just to set the record straight, I am a huge fan of both companies. That’s not easy for a monkey like me to say.
P.S.: I thought about adding some nice battling logos here, but with all the litigation talks on that thread, I figured it was best not to do that. So, I used the mic logo instead. If you don’t like it, sue me. Um wait. Don’t do that. Please send me a polite email offline requesting to take it down.
P.P.S.: 37signals please don’t be mad. We’re not even out the door yet and I would hate to end up on the wrong side of one of your posts… I’ll send over some ripe bananas if that will help.
- Charlie
Update: Get Satisfaction created a blog post on the topic as well: http://blog.getsatisfaction.com/2009/03/31/kissing-and-making-up-with-37signals/
Update 2: There is now also an open letter to Jason Fried: http://blog.getsatisfaction.com/2009/03/31/open-letter-to-jason-fried/
Update 3: 37signals posted a response on their earlier posting: http://www.37signals.com/svn/posts/1661-follow-up-on-get-satisfaction-or-else
–
Charlie Chatterbox
Celebrity Mascot
Posted by: charlie | April 1, 2009 | | categories: Social Media | tags: crowdsource, customer support, reputation
