Blogging was where we began, and how we built our company so we have preserved this archive to show how our thinking developed over a decade of developing the use of social technology inside organisations

We need Business Verbs in Social Software

by Amit Kothari

This post aims to think about the commonalities of mundane, day-to-day work, or verbs that are universal in corporate life. We treat these as our universal constants, and my idea is that social software has a major role to play in being the vehicle of common business activities. We have only seen a glimpse of what is possible in activity feeds that are central to most social software suites. It’s time to ramp up to a language that fosters adoption and cuts obscurity.

Let’s set the scene for some esoteric goals of what I will call awareness platforms. Note first, that Social Business is a far larger subset of our conversation here about tools and suites – and covers much larger issues such as cultural fitness for purpose, organisational and managerial challenges, and so on. The tangible tools of Social Business play host to delicate and contextual surfaces – all aimed at getting work done. People call these tools social software. The important thing here is “things” to get “work done”. This means that we must think hard about what a forum or twitter-clone in the enterprise actually is, and why it’s needed. Otherwise, we risk owning an expensive garage with all the wrong tools. That subject is a diversion to this post. One way to solve our problem is to address common business verbs.

For the purposes of business verbs, social software exists as suites or point solutions. An example of a point solution is a wiki. A wiki services one simple use case of being able to work on a document with someone else – a common and beautifully executed application of a point solution for something we already do. You can do that job on Google Docs, etc. in semi real-time. It’s a clear use case. Suites, the subject of this post, face a far bigger responsibility – to holistically combine all that is possible, in all situations where it’s possible, while respecting business norms like content protection. It’s like building the best planned city you can possibly design; under one roof.

To solve problems using tools, in general; we must guide our thinking by two principles:

  • The tools must service what we already do
  • They must have scope to work with other tools in a way that makes the whole more perfect.

verb.png

Now we can dive into what I believe about business verbs in social software. Business verbs in activity streams are likely to fit both the above principles. These verbs don’t have to use social software at touch points, they can be “executed” as verbs in other surfaces that are beyond the realm of being seen, like in verbal conversation.

What if we can provide activity updates which use the natural language of everyday business? Forget liking, disliking, bookmarking and all these foreign sounding words. Imagine an activity feed which uses business verbs, gathered implicitly or explicitly from pointing, clicking and typing.

For each of these verbs – picture the use case for an employee in their day-to-day work. They can trigger these, or string verbs into a workflow. For example – a blog post/wiki page can leads to someone “facilitating it” around a meeting, and then subsequent “commenting” and possible “reviewing” leading to a “conclusion”. All from just a wiki page, or any URL – which had no states or wasn’t geared up for being the subject of a business-like discussion. We treat any social object as the focus for a verb, even a URL. Perhaps, verbs like these:

  • responded

Responding needs a target i.e. someone was the target for a response. Hence a way to create this situation is to elicit a response from someone by “sending them content X for response”. Done through a toolbar gizmo – “send to colleague and ask for response”.

  • acknowledged

This is achieved as a formal delivery receipt. The sharing process could additionally specify a click needed for acknowledgment.

  • supported

This is interesting. Essentially, it is a “thumbs up” in a business sense, nicely done for content which requires consensus. A button on the toolbar, like a thumbs up would create an activity item “John supported X” to your network or to everyone.

  • facilitated

A nice way for an individual to host a discussion. We could take a piece of content, such as a wiki page or blog post (the discussion surface) – and allow someone to say “I’m facilitating this”. The next step in this workflow is to invite comments and discussion using another verb – sharing that piece of content with colleagues. Through all cases, that piece of content would have a marker that notes that an individual is facilitating that specific discussion. A quasi-authoritative discussion format online is therefore created – the basics of business use.

  • concluded

A verb available if you are facilitating a piece of content. You may post a conclusion to participants that you originally invited and mark any content (wherever it is) as concluded with a result. The toolbar gives you the button if you can do this and injects into your feed and the feeds of discussion members – individual scope since your network doesn’t need to know.

  • reviewed

A button similar to acknowledgement, with the added benefit of a text box or more that supplies review details to your network feed. Reviews can be made public, in which case any person arriving at that piece of content sees a marker stating that “a review exists for this page”

  • mark for approval

A directed verb which is triggered from the toolbar – you direct this action at someone else. Only your individual feeds are involved.

  • approved

Follows “mark for approval” above.

  • mark for action

Mark a piece of content for action by someone else or by yourself. A private, directed verb. A text box states what the action is on that piece of content.

  • delegated

Usually the result of an action. If a piece of content results in a “mark of action” – you may press another button which appears in that context to delegate the action.

The next part is putting the exposure of done verbs into a scope, where that will be most useful. Scopes are:

  • user-only – personal
  • group – possibly for a team
  • network – for my connections
  • global – everyone
  • executive – possibly some verb aggregates e.g. 600 people approved things today.

For each verb, we must decide the scope of activity injection.

The result of such an approach is a complete transformation of understanding through common language, increasing business efficiency and reducing email overload.

2 Responses to We need Business Verbs in Social Software

  1. By Stowe Boyd on October 21, 2010 at 6:52 pm

    Actually, all the examples are past participles, not the root verb. For example, delegated is the past participle of the verb delegate.
    Another way to think of this might be to consider the lifecycle of the objects in question. For instance, a survey in marketing campaign is created, then reviewed, deployed, analyzed, and archived. You could imagine tools where the specification of an object could include these lifecycle states, and so each instance when created explicitly is moved from one state to another in some defined way.

  2. By Amit Kothari on October 21, 2010 at 9:27 pm

    That’s very interesting Stowe, thanks.
    It strikes me that certain objects are temporally bound, and some are eternal, while some don’t interest us.
    In terms of the lifecycle of the object, let’s assume that all objects are temporally bound with a beginning, some states and an end. I really like the idea of defining all possible states at the point of creation, or the specification of the object as you say.
    We can do this for the lifecycle of the well known, most pounded processes out there. I expect for certain loose processes we could improvise states and let loose movement happen between yet-to-be-defined states, possibly with no conclusion to the lifecycle. Depending on what actual lifecycle and “thing” we talk about, that non-conclusion either doesn’t matter or being in limbo – matters a lot.
    This is excellent in its’ basic form. We spec the objects, spec the verb, spec all the inside states of its lifetime (if we can) – and build a catalogue organised by object and verb.
    This catalogue gives us the structures and forms. We then fill these empty containers with actual instances. Like trickles of water into a stream, the filling of these containers could be automatic – from data already being generated.
    Note – this was cross-posted at Dachis Group with another comment there.