Transition your 1.0 wiki to a PBwiki 2.0

We’ve received tons of emails from beta users requesting to transfer their 1.0 wikis to the new PBwiki 2.0.

We’ve already invited a limited number people to transition their wiki, and we’re excited to allow a few more users the opportunity to transfer to a PBwiki 2.0.

When you transition you will be able to access our new features:
Improved Editor
Folders
Page Level Access

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.

The Foolproof 5-Step Way To Answer Tough Questions

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.

Want to see my answering techniques in action?  Attend our upcoming webinars:

  • Use PBwiki Templates to run your business more efficientlyApril 1st, 1:00pm EST
  • Using PBwiki for Project ManagementApril 15th, 1:00pm EST
  • Is your customer service team doing enough?

     I was reading an interesting article today that got me thinking about customer service:

    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.

    The lesson: make sure you’re consistently trying to “WOW” your customers – they’ll thank you in return.

    Thank you — PBwiki 2.0 Beta Users

    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!

    If you haven’t yet seen a PBwiki 2.0 Beta wiki, create one now!

    Terms of Service: We Got Your Back

    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. 🙂

    David E. Weekly
    Founder & CEO

    Key Challenge facing Customer Service Executives

    Organizations of all sizes share one common problem: cohesiveness

    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.

    Collaborate with PBwiki and create our official documents

    Here at PBwiki we have a few great ideas on how to set up a wiki and get your users on board. We have PDFs, PowerPoints and a whole bunch of material that helps you create a wiki. But there is one problem – this material is created by US for YOU – and we could be dead wrong.

    I have started an experiment. I’ve put some of our materials on a wiki and I’m asking you to edit it. At the end of one month, I’m going to save that wiki page as a PDF and brand it as an official PBwiki document. (Of course – all of the contributors will be credited.)

    So edit away – delete, upload, and add your thoughts on How to set up your wiki for the first time.

    Don’t add a comment on this post – EDIT THE WIKI!

    The Company-Customer Pact

    A few weeks ago, we attended a summit put together by our friends over at Get Satisfaction and they launched something they call the Company-Customer Pact. As they put it:

    This pact is a call for shared responsibility between companies & customers — one that promises that both sides will hold up their end of the bargain to change the game. The document provides a way to opt into a set of shared values. It’s a balanced statement of responsibilities for companies and customers.

    You might wonder why we need this, as it seems like common sense. But if common sense were enough more people would be employing these principles now. We’ve been trained by the bad habits of corporate culture to turn away from the anger of alienated customers reacting to an environment where it’s common place for companies to hide behind phone trees, avoid fault, and employ anonymous and in-human call centers that makes them hard if not impossible to reach. Or by engaging in practices like price-gauging and issuing confusing bills and policies.

    We’ve signed the pact and we’d love to encourage you to do the same – head over to ccpact.com today and get involved! You can also read Get Satisfaction’s full post here.

    Company-Customer Pact

    How to use one wiki with many students — at one time

    We’ve heard from a lot of teachers that it can be frustrating to work with on one PBwiki with many students at one time. PBwiki doesn’t allow more than one editor on the page at one time – and the page that is being edited is ‘locked’ to other users.

    (This is because if a wiki allowed two people to edit the same page simultaneously, the edits might conflict.)

    You don’t want to waste valuable time in the computer lab but what should your other students do while the page is being edited?

    Create lots of Pages
    Our suggestion is to create lots of pages: Create a page for each lesson, for each project, even for each student. When your students have more pages to choose from, there is less of a chance that they will have to ‘Steal the Lock’. Here are two ideas on how engage many students on one wiki.

    Book Review:
    Assign a book review project to your class. Have each student create their own page, write a short review on a chapter and populate it with links to articles about the author, the book and other articles. Then ask each student to visit the wiki page to the person on their right. Ask them to review their partners links, edit the review or comment on the page.

    Collaborative Research Papers:
    Group the students into teams of three or four and have each group divide the project between themselves. During computer lab ask your students to begin researching the topic, have them paste links and jot ideas down on individual pages. When ready to write the paper, have each student work on their own page and allow the group to edit each others pages. Paste the completed project into one wiki page.

    How do you use one wiki with many students? Join the discussion here