Archive | Support: Behind the Scenes RSS feed for this section

PBwiki – A typical day at the office

7 Feb

We’re big fans of spicy food here at PBwiki and so today we set up a contest at the office to see who can take down the spiciest hot sauce within a set period of time.

The rules:

The participants:

Ramit: <I’m super impressed that Kristine actually competed>

Kristine: <This is what happens when you work with a bunch of men – you end up chugging hot sauce. This time Ramit is going down – way down >

The first taste:


Second thoughts after the second round – Paul has the defibrillator handy:


David acted as the judge and jury:


This is why you should come work with us at PBwiki.

Putting Customers First

28 Jan

I’m nearing my first two months here at PBwiki and as they say, time flies when you’re having fun! We’ve come a long way since I started:

  • We’ve setup support metrics and begun measuring the team (and the company) wherever possible
  • We’ve added 2 more great people to round out our support team
  • We’ve improved the PBwiki community and our entire team here at PBwiki is actively involved 

And the best part – we’ve got a lot more on the way in the coming weeks!  We’ve made some conscious decisions to ensure that our customer’s needs come first – our support team is actively working to ensure that the answers you receive are high quality and relevant to your situation. Although we sacrificed some speed for this, we feel this is the right decision - I’ve received some great feedback from many of you (keep it coming!) with regards to our new support processes – here’s one that I got just today: 

I gotta tell you, I am MUCH happier with your help on my recent help ticket (and for hearing me out with my complaints about past help tickets) then I would have expected. You guys are doing good things on the customer relations front, and I appreciate it 🙂     

So, for those of you that are already using PBwiki – thanks for sticking with us, we’ll make sure we continue getting better at everything we do. And for those of you not using PBwiki – what are you waiting for?!  Hear what our users are talking about and get involved in the discussions here! 

Support Happenings: Satisfaction

22 Jan

As most of you know, we recently locked up our forums and started a new community discussion space here. A number of you emailed me directly asking for more insight into how we made our decision here at PBwiki. So, rather than send out a mass email, here’s the answer:

The problems with classic forums are well known, particularly in the context of mainstream customer service. The best answers get buried in long conversations, they breed endless duplicate topics, they’re hard to search, they tend to be either under-populated or clubby. They generally aren’t friendly or inviting to casual use. We’re using Satisfaction to harness open conversation without falling into these traps. One example of how we’re doing this so far is the “talk box” at the top of the page-by merging the process of actually asking a question and searching. The result is very few duplicate topics, and more focused engagement around the issues. The pages are designed to be more like blog posts, with each topic creating a focused conversation piece that makes sense even when entered from a Google search. The conversation threads themselves are more personal.

From the standpoint of customer service, traditional forums are too general purpose to be that useful. We’re building tools that support the distinct activities that dominate conversations between our customers and the PBwiki team – questions, problems and ideas. There are outcomes and interactions in these activities that forums just are not suited to support. Satisfaction provides us the ability to mark certain answers as “official responses,” and our community to vote best answers to the top. This has the surprising effect of auto-generating FAQs based on the real interactions with and between our customers.The result is a more trusting, valuable conversation space. The value of this approach for providing a higher level of support will become apparent over time -or so we’re betting.

Feel free to join me (and the rest of the PBwiki Team) here as we talk more about why we made the switch – we’d love to hear any feedback you’ve got for us.

How to spot your next (support) hire

14 Jan

We just added two more folks to our support team (Welcome, Casey and Rachel!) and I wanted to talk about the choices we made along the way. We could hire support folks to do one of two things: 

  • Do their job and go home.
  • Do their job exceptionally well, make customers love PBwiki even more and then go home.

PBwiki’s support team chose the latter – here’s what I look for:

  • Do we get excited thinking about bringing this person on board?

If there’s any doubt – move on. We need superstars to rub off positively on the rest of our superstars.

  • Are they capable of doing exceptionally well at their job?

How passionate are they about what they do? How good do you think they can become? If both of these questions look good, you’ve got a great hire on your hands.

  • How much hand holding will they need?

We need people with initiative – otherwise, constantly making sure they’ve done the right thing is going to eat up all of my time.

  • Do they share PBwiki’s core values?

If they don’t, we risk losing PBwiki’s identity and becoming Boring Company, Inc. Test this by letting them support a handful of customers and watching the customer response – you’ll have your answer in short order. 

Will this get you the right candidates 100% of the time? Perhaps not – but it will significantly boost your chances of finding the right people along the away. 

Are you our next support guru?

3 Jan

Do you like helping people figure things out? PBwiki is looking for a few part-time customer service superstars to join our support team. You’ll be on the ‘front lines’ via email, phones and the forums – our customers will rely on you to handle their questions, concerns and feedback. You’ll be working with us from our San Mateo, CA office.

Read more about the position (and apply) here.


Introducing Paul Singh, PBwiki's new Director of Support

7 Dec

We want to welcome Paul Singh, our newest member of the PBwiki family. As the Director of Support, he’ll be responsible for getting you the help and training you need from PBwiki.

Paul has an extraordinary background in Saas (software as a service) support. In the past, he’s built up a support organization for a $48 million dollar SaaS product.

What this means for you
Look for rapid improvements in PBwiki support coming up, including better training materials and answers to common questions.

Welcome, Paul!

Best practices for getting others to contribute to your wiki

12 Sep

When it comes to building a collaborative wiki, there are certain elements that significantly increase your chances for getting others to contribute to your wiki. Here are the PBwiki best practices for getting participants to be fully engaged in your wiki.

Avoid Blank-Page Syndrome: Pre-fill your wiki with content.
Most people get scared by blank pages. We call this “blank-page syndrome,” which causes users to flee and never return. There’s a way around this: Just add some content to your wiki before inviting users. Consider adding an “About Me” page, a “What’s this wiki about?” page, and a few more welcoming pages. Not only will this help new users get situated, it will help you get experience editing your new wiki. We find the learning curve of successful wiki editors to be about 12-15 minutes.

Make the front page a landing page for navigation.
Your front page should have a short explanation of the purpose of the wiki and links to appropriate pages, not one long scrolling page. This helps in two ways: First, users tend to get overwhelmed when they first come to a wiki, so this approach lightens up the content on the page and directs them to the next step. Second, if you get large amounts of users on one page, they won’t be able to edit it at once. With multiple pages, the chances of two people trying to edit a page at the same time is lower. So keep a short front page with links to other pages.

Give users something concrete to do.
One user, “Michelle,” had trouble getting co-workers to participate in her wiki for over a year. Then she changed her approach: She asked users to change one line of the Frontpage. Participation skyrocketed and continues to be strong a year later. Consider creating a soft request, like asking users to add their name or to fix a single spelling error on the wiki page. They’ll be much more likely to try editing if they have a small nugget to accomplish first.

Making logging in as easy as possible.
The problem is not access controls — it’s creating something compelling enough to get people to contribute to your community in the first place. Make your wiki easy to access and worry about access controls after getting a few regular participants. (If you absolutely need ironclad business security, we do offer the PBwiki Small Business Edition.)

Get everyone to participate.
When you start a new wiki, you’ll find that some people will cling to old methods of communication. For example, some of our users report that their co-workers continued emailing them or asking others to “please put this on the wiki.” When people email you, point them to the wiki. The beauty of PBwiki is that the most current information is always on the wiki, so direct them to your PBwiki URL and encourage them to add it themselves. After 2-3 reminders — and seeing their co-workers actively using it — they’ll be much more likely to contribute to your wiki.

Remind your users that it’s ok to play.
Your wiki users will be nervous the first time they come to PBwiki, wondering if they’re going to mess something up or cause an irreversible change. Assure them that it’s ok to edit pages — PBwiki automatically tracks changes and allows you to reverse changes, so they should feel free to edit an existing page or create a new page. In fact, one of your goals might be for each user to create their own page!

Make PBwiki part of your day.
One of our most successful wiki editors added “It’s on the wiki!; to his email signature, instant-message window, and on his website. When users messaged him, it was the first thing they saw. Consider putting your daily schedule or important notices on your wiki. When others see it used regularly, they’ll buy in, too.

Whither pagers?

17 Mar

Earlier this week we had a service outage. The proper chain of events would be:

  • 00:00:00 Server problem
  • 00:00:03 Monitor processes notice problem, send page to admin’s phone
  • 00:00:10 Phone rings with new message
  • 00:00:30 Admin logs in to server, fixes problem
  • 00:01:00 Problem resolved

But what happened was:

  • 00:00:00 Server problem
  • 00:00:03 Monitor processes notices problem, send page to admin’s phone
  • 00:00:10 T-Mobile doesn’t deliver the message

This started around 3am California time, which is why none of the PBwiki team noticed it independent of the sms alert mechanism. What should have been an isolated transient, simple to resolve and not user-visible turned into a cascade of unpleasant timeouts which caused the service to slow and eventually halt. We’ve done an extensive internal examination of what happened, and we’re changing some technology, adding some additional automated checks, and doing a few procedural things more intelligently.

The main process change is something that is probably old hat for old-school ops people — the absence of a page alert is not an indication of systemwide health. We’ve deployed a lot of new infrastructure in the last few weeks, and I’d been getting occasional pages for a while, but none for the prior day or two. I’ve set up the daily equivalent of the Tuesday-at-noon air raid siren test — in which the absence of a message every morning will be a problem itself. We’ve also got independent Nextel phones for on-call ops folks so there are now several routes for the alarm pages to take, plus that funny push-to-talk thing so we can annoy one another at all times.