Eat your own dogfood
by Volker Weber
Referring to this entry and Ed's comment Rainer Volz is asking a good question: Why doesn't Groove Networks demonstrate the usage of Groove- and IM-functionality by using it publicly, for example in customer interaction? Currently this is only done by GN partners like Andy Swarbrick.
I might want to add to this: If Notes is dead and Groove is so great then why is IBM using Notes/Domino for their LDD site while Groove needs Fuzetalk for their customer support forums? Any customer should have Groove installed and would be able to benefit very much if he were able to use it for support issues. It is an excellent example of an issue that needs to be solved at the edge, in this case Groove's edge. If you have any serious issue then you will be asked to send mail to support@groove.net - while the Groove Networks site tells me that Groove Workspace is 10 times better than email.
IBM lets you access LDD with Notes (as I do) or a web browser. Wouldn't it be neat if you could do the same with Groove? From my experience, it is impossible for a simple reason: Groove does not scale well enough to support a population of more than a hundred people in one space.
Comments
I don't think Groove is designed for customer service at all. While, Lotus Notes is a very valid, not not a very scalable and good one, platform for customer service application.
Customer service is a very structured process for 80% of the issues. 20% of issues can benefit from collaboration but that collaboration is far from ad-hoc. Collaboration in customer service needs to fulfill these requirements.
Groove can't meet this requirements nor is it designed for this, IMHO.
Thanks for the link, Jack !
From my understanding Groove was not designed to facilitate many to many communication (as in groups larger then 100 people). Therefore it does not really make sense to use Groove as bulletin board for public use (as LDD).
I am an SME (subject matter expert) and involved in severe support issue myself on a regular basis. Usually these incidents require communication between development, support, customer rep and - last but not least- the customer (often represented by several people). The communication often includes meetings, exchange of log files and configuration information, code swaps and sometime even exchange of operational application segments. Groove seems to be great for doing that type of customer support as it allows to bring everybody together for a temporary time and works across firewalls in a very safe manner (which is important as soon as confidental data is being exchanged). Yes, there are alternatives for using Groove such as setting up a Quickplace. But no matter what the tool of choice - leaving the email space provides a major value add.
I don't mind, that such a fire drill happens in a different environment then the public discussion. Yes, information from such an incident has to be fed back into the Knowledge Base. However, this always requires manual editing: summarize problem, stripp out information that neither the customer nor the company wants to be published and generalize the findings. A workflow is nice to make sure that this gets done, but the real work required cannot be automated anyway (and may as well include copy & paste).
Why Groove Inc is not using Groove in your particular case remains an open question. But comparing it to LDD does not make sense - not for me anyway.
The comparison to LDD is indeed a bit far fetched. I think I was misguided somewhat by Steve's rant declaring Notes dead. He was oversimplifying from Ray's remarks on his weblog. Ray certainly has an unhidden agenda but he is not declaring Notes dead, nor does Groove Networks.
There is an interesting inflection point going from Mail into a CRM application into a contextual collaboration. Lotus is talking a lot about this type of interaction lately and I am really looking forward to somebody actually doing this sort of thing.
Groove has a nice feature that was initially called Outlook Onramp, that lets you pull documents from Outlook and beginning with 2.1 also from Notes into a Groove space.
I really wonder how they want to put these kinds of things back into the original application once the space is retired. The same problem exists in Quickplace btw.
As you pointed out there is some manual work to be done to take the information to the next level, but one might still want to migrate the Groove space back into something else.
"I really wonder how they want to put these kinds of things back into the original application once the space is retired..."
I am still new to Groove, but I assume that the answer is to create a Bot and to invite it into your space. The Bot resides on a server and shuffles data back an forth between the space and a public website or a corporate application(Ray would use Sharepoint Team server as an example here, but Quickplace or any other webserver should work as well in case you do not have MS funding).
Well, a few sematic problems need to be solved:
a) when I invite a bot into my space I provide access to everything in it. Is this really what I want? Do I trust the bot to only publish information that I am interested in?
A variation:
I could add an additional tool to my space to link or copy all information that shall be published. The bot may be programmed to only look at that tool - which may give me more confidence into her. However, in theory she still has access to all data in the space as tools provide no security (see earlier discussion on vowe.net and Ray's comments).
However, this approach may give me a little more confidence that the bot is not misbehaving.
b) rather then inviting the bot, I could also send everything I want to publish as a message to her. But is a message the appropriate format to let the bot know how I want my information to be published?
c) I could also create a publishing space to which I copy all material that shall be transfered. It may optionally feature a workflow to ensure that the material that I add is being reworked and checked for legal or corporate ID concerns. Once it is ready for publishing the "Support Knowledge Base Bot" could pick it up and get it out to the world. This creates the same trust problem as in a) but I have at least defined which material I want to publish and restricted access to everything else.
c) Once published, I would like to see links from my space to the Website and from the Website to my place (or its archive).
We will get some clue of how Groove Inc would handle this problem once the Groove/ Sharepoint Team Service integration becomes available. It essentially has to solve these problems somehow.
a number of points
1. andy (and i) have adequately demonstrated during tests that spaces with 200 members are certainly viable.
2. groove is perfect for customer support, both the structured and unstructured type, but it is even better for team interaction during support issues.
3. data in and out of groove is getting easier and easier. i personally will be publiching some simple tools for connecting to real data. others will follow.
4. re compartmentizing within a space (private tools and records) i feel that this is a relevant part of the sharing mechanism - i have just put out a tool that does just this, provides multiple private work sheets in a single tool and it is proving to be very natural for the users.
5. while i do not think that groove is suitable for large forums, this is not exactly true. a little change in arcgitecture (aka groovelog) and thousand can and did interact in a common forum, using groove IM.
so, the real point remains, when will groove use it's own product as the primary in-house tool - because then the little things that are annoying people and causing so much controversy would get ironed out - groove the user would fix groove the platform.
Yes, Groove can be made to dance like a horse but then that would require writing application with all the right features to provide more structure and measurement for SMEs-CSRs interactions.
The question then is why Groove platform? Why not .NET or J2EE? What advantages does Groove offer for this application over more ubiquitous platforms. I don't see any advantages. In fact, the need to deploy a client on all machines is a huge disadvantage.
