Things to know when transitioning your wiki:
• Users must have a PBwiki account – currently 2.0 wikis do not use the invite key
• Custom CSS wikis will need to use the new color picker tool to customize your wiki.
• Your wiki may display differently in 2.0

Most importantly, when you switch to PBwiki 2.0 you won’t be able to revert back to 1.0.

UPDATE:Thanks to everyone that signed up for the migration trial. We’ll be reaching out to you over the next few days to make this happen.

I was having lunch yesterday with some friends, when the subject turned to questions and answers. My friend had attended a conference panel, and complained that the panelists all failed to adequately answer her question.

(In defense of those panelists, the question was a difficult one without a clear right answer.)

I proceeded to answer the question, much to her satisfaction, and she asked me afterwards, “How do you give good answers to tough questions?” I thought you marketers out there might be interested in my response.

1) Make sure you understand the question. When someone asks me a question, I listen carefully, both to the words, and to the unspoken assumptions. Two people might ask the exact same question in exactly the same words, but my answers to them would differ depending on tone, body language, and my history with that person.

2) Start your thinking broad, and narrow it down. As I listen to questions, my brain is constantly jumping ahead, thinking about the various possible paths the question (and my answer) might take. It’s a bit like watching a search box autocomplete, gradually narrowing down potential answers as I type. That way, rather than searching for a single right answer and not knowing where to start, I simply winnow my down to the truth.

3) Always directly answer the question, even if the answer is “I don’t know” or “I can’t tell you that.” I always give a direct response. Unless you’re really slick, it’s unlikely the questioner will forget what they actually asked, and your attempts at evasion will simply madden them and reduce their estimation of you.

4) Make your answer interactive. Just as I’m constantly making mental adjustments as I listen to the question, it’s wise to follow the same approach when answering. Give one part of your answer, and check for agreement. There’s no sense in erecting a massive rhetorical edifice if the listener disagrees with your basic assumptions.

5) Check afterwards to see if the questioner feels satisfied. You’re answering the question, so you don’t have to stop until you feel like it. Don’t let the desire to finish override the real goal, which is to convey understanding. If it takes a little more time, better a longer response than an unconvincing one.

An industry rule of thumb is that a bug which costs $1 to fix on the programmer’s desktop costs $100 to fix once it is incorporated into a build, and thousands of dollars if it is identified only after the software has been deployed in the field.

How true – sometimes just a little extra effort on the customer service end can alleviate a ton of pain down the road (both for you and your customers). With the rise of sites like Consumerist, the world’s becoming a smaller place – just today, a certain BMW dealer in the Mid-West got slammed for some poor handling of an Ebay transaction. What could have been a relatively easy sale turned into a 3 day long online bashing with over 200,000 page views.

Over the past couple weeks our users have been hard at work testing all the great new features in PBwiki 2.0. We’ve received a ton of positive feedback –

“I find the UI to be something that both engineers and graphic designers would love.”

“Well done folks, even more straight forward than your ‘Point and Click’ editor.”

“It’s a beautiful site, really easy to use. Awesome that you’ve made it freely available.”

More than that our beta testers have helped us identify and squash a bucketful of bugs and made dozens of excellent suggestions for ways we can make PBwiki 2.0 even better.

I’m the guy who gets to read all your Beta Feedback and I wanted to say thanks to all our users for exploring PBwiki 2.0 so thoroughly. Also I wanted to give you just an idea of the long list of bugs that have been fixed thanks to you:

There are now templates for new pages

Linking to email addresses is fixed

Page history is retrievable for all pages

It’s easy to delete comments

Email addresses are not visible to anonymous users

Readers and Writers can not delete pages

This is a small sample from a mountain of help you’ve given us. All thanks to our fabulous beta testers!

When I was putting together PBwiki’s Terms of Service a few years ago, I spent extra time with our lawyers to make sure that it was as pro-user as possible. The first few versions I got back weren’t good enough and I pressed them to make it shorter, simpler, and to put more rights in the hands of users. I eventually ended up with something I felt good about. Something that made it clear that we weren’t going try and take ownership of user’s content and that we took their privacy seriously.

That hard work has been paying off, with many enterprise customers praising our confidentiality clause for private wikis and our lack of authoritarian clauses. Today, Joshua Greenbaum at ZDNet published an article called Making Web 2.0 Safe for the Enterprise: TOS à la PBwiki that did a great job showing how important terms are for an enterprise service. So hurrah! We’ve got your back. :)

The decision making has become highly fragmented – from marketing, to sales, to engineering, to services and so on.

This makes sense from an internal perspective because we need to measure individual efficiency and productivity – we’ve been running this way since the first assembly line was produced. Of course, there are some benefits to this approach:

Payrolls are down

Efficiency is high

Profits are good

The problem is that the improvements are inwards focused and don’t lend themselves to creating metrics around the customer experience. Customer service managers have a hard time getting customer service improvements prioritized properly – database upgrades, infrastructure, security, etc – these things eat up 99% of the customer service budget.

So how do we solve this?

Find ways to enhance customer service capabilities without scrambling for capital expenditure approvals and without bugging IT. This benefits the customer and the IT manager – SaaS is perfect for this. More appropriately, PBwiki is perfect for this.

We know most customer service related deployments take time. Integration and system change take time – with complex customer service systems, it can take months and even years to get things running properly. Instead, use PBwiki to centralize your product information, best practices or other proprietary knowledge so that your workforce is empowered.