Library clips

Here’s a summary or clarification of my last couple of posts on Above-the-Flow and In-the-Flow.

A blog can be used for all types of posts like news, announcements, status, etc…this post focuses on using a blog for support know-how.

Blogging a unique solution I have on a support call is In-the-Flow, because it is directed, it’s part of my job duty. If an error is resolved all support staff should know about it.
I’ve started blogging this stuff (seeding), and once I introduce the rest of the team to the blog, hopefully they will do the same.

Support staff are directed to use the support database (where users log calls and we manage our calls) so why not the support or solution blog.

I may use the Support database to record this call and solution, but this database isn’t as free-form as a blog or wiki.

So what I have begun to do is complement this by writing a blog post which is more: human like, it’s personal, it contains the nuances, it may compare to other situations, include extra explanation and workings out of how I got to the solution.

The more context the better, and in some occurrences this extra explanation, rather than the solution, may help you on a similar call.

Whereas the support database asks to fill in some fields, and give the solution, it doesn’t want to know anything else, it’s very formal and to the point, no colour or personality about it…see more.

Another reason to complement support solutions with a blog post is there is no way to subscribe to closed calls, and why would you…if the calls are not unique, I don’t want to be informed of every menial closed call.

Yet another reason is browsing and searching the support database is yuch…at the least.

So why do we use it?

Well it’s good at reporting, we can generate great statistics, people can log calls, we can change the status on a call, pass a call to someone else, etc…you can see that a support database is neccessary.

But I don’t think it’s a good solution database that just contains the gems.

Perhaps a unique solution that is entered into the database can also have the option of being sent as a new blog post.
But then they are not interoparable, and the database doesn’t have rich text and manual categories, etc…

Plus as mentioned earlier the solution entry is not as expansive or intimate as a blog post, it’s more direct to the point…I guess a blog post is more contextual.

What about experiences?

If I have a unique experience about our software or a user or another department, this doesn’t qualify as an entry in the Support database.

This is another reason to use a blog, but this is more an Above-the-Flow scenario, this is a harder thing to get people to do, as it’s not definite like a solution, it’s more soft. It’s a pity because when you read about experiences it sticks with you, you absorb it, when you encounter a similar situation you can be familiar with what to do, or not to do.

Sharing these experiences are vaulable, and a blog can enable this.

At the moment

If I have an experience that everyone should know about or have just closed a support call with a unique solution…no one really knows this has happened.

Why do I want to document and disseminate this information?

…perhaps for my own benefit, so I don’t forget what I know.

Some of us like to share, especially if it’s a solution, we want everyone to know, not really an ego thing, rather a friendly thing to do.
So we usually shoot off an email, we certainly don’t put our solution in a word document and upload it into the DMS.

As I mentioned a group blog is hopefully going to become the new substitute.

I see people will use the blog for solutions to common errors, etc…(In-the-Flow/Directed) but may perhaps use it less for experiences, workarounds, or “did you know if…” (Above-the-Flow/Volunteered).

As mentioned in earlier posts if a volunteered blog post helps someone with their job, then hopefully they will return the benefit and volunteer their own experiences. In addition to this, comments get conversations going that could spur people to want to express themselves more and write an actual blog post.

Blog as database

The blog is going to be the solution database and more…you can browse by date, category, search, use the sidebars for useful stuff, and even subscribe.

Why subscription is powerful?

If I get an an alert update from a new blog post that describes a solution, I now know that this solution exists…I’ve been educated/informed, just like reading daily news.

If I were to later on come across a situation that requires this solution, I can search the blog database knowing that an answer exists. I’m not blind searching hoping there is something documented, as it has come across my eyes before.

This really taps into Dave Snowden’s principle: “People don’t share knowledge in the anticipation that you need it”
- if you ask people to put tacit knowledge in a common data store for a possible need in the future, on the basis you might need it…it just doesn’t happen.

Somehow blogs overcome this has they are dead simple to contribute and they are conversational, they are a place to hang out…it’s more about participating.
This type of framework or ecosystem is all about flow, just check out Ray Sim’s latest slidedeck:

“Slide 20 Stocks
- codifying, capturing, harvesting, storing (STATIC)

Slide 20 Flows
- conversations, fragments, connections (FLUID AND DYNAMIC)

Slide 22 - Why Flows?
- Speed of change versus speed of codifying
- Continuous versus something that happens at the end of the project
- Small pieces loosely joined, context preserving
- Broader participation, with more connections
- Weak signals perception
- Results: innovation and better decision-making”

Another good thing about subscription is if I want to add an entry to the Support blog, I’m not going to publish something that’s already there, I’m not going to create a duplicate entry as I already know that entry has been made as I subscribe to updates.

Our Support database reporting captures all calls, even if the nature of the call has been logged a 100 times, this way we can make decisions on more training for staff or users, or fix bugs and features, etc…
The tag cloud of the support blog can also display patterns that emerge, but of a different nature.

How do wikis fit in?

I’ve decided the group support blog will be for solutions, experiences, tips and tricks, workarounds, did you knows, etc…

The forums will be to ask questions and discuss matters.

Now I am piloting wikis, so how will this fit into the equation?

Maybe the wiki can be a contents page for the gems in the blog support database, kind of like a gateway page.

Or perhaps the wiki can be the solution database itself, just like the blog, each wikipage being a solution.

I kind of like this solution as pages can be re-edited (I suppose a blog post can as well), and you can also have comments (well not in our wiki, but generally).

Hmmm…I do like that you can subscribe to a blog…and a blog is about currency.

Subscribing to a wiki may be painful, especially if lots of changes are made…I have limited experience in subscribing to a wiki.

Perhaps we can use both:

- the wiki can be for solutions
- the blog can be for experiences, insights, announcements…

This means that solutions will not be published as a blog post, but rather in a wikipage.
Instead the blog can be used to publish quick news to notify support staff of a new solution in the wiki.

Maybe this is the way to go.

I also want to make an error image gallery wiki, clicking on an image will take you to the solution which lives on another wikipage.

Another question is how open are both the wiki and the blog?

I’d have them both open with modify access for the whole support team…gardening can be done later, rather than getting through a gatekeeper upfront. They both need to be open to capture things as they happen, and for everyone to feel they equally own the knowledge base.

What do you think, can anyone shed any light on this scenario?