Archive | November, 2008

Hello, from the new Web Analyst

21 Nov

I joined PBwiki last month as the first web analyst on the team.  One of my key roles here is to analyze how people interact with their wikis so that we can craft our products and services to best meet your needs.

We can monitor PBwiki to see what’s working and what’s not
One of the greatest facets of having a “software as a service” (SaaS) model is that we have an on-going relationship with our users and can observe how they interact with our product.  Compare that to the standard shrink-wrapped software model, where the vendor sells the product and then disappears from the customer’s sight until they want to sell an upgrade.  The benefit, of course, of us knowing how you are using our product, is that we can enhance the product to better suit your needs.

Case study: How many users use Document Management functionality?
Before the new features
As a concrete example of how PBWiki analyzes user behavior to improve the value of our product, let’s look at our new Document Management capabilities.  On any given day earlier in October, roughly 35% of active wikis were uploading files (see table 1).  This adoption rate indicates that you find document management useful and that we need to focus product development effort on it.  But at the end of the day, this number doesn’t give us much guidance in terms of what direction to take this feature.  To make any decisions regarding the product, we also had to look closely at qualitative data.  The quantitative data (i.e. the 35% adoption rate) lets our product team know what you’re doing, but the qualitative data lets us know why you’re doing what you’re doing.

Table 1 – Pre-feature enhancement adoption rate

Date Adoption
10/11 33.0%
10/12 34.3%
10/13 35.7%

After we released Document Management
After analyzing the qualitative data (e.g. user feedback), we realized the need for several new features (including access control), implemented them, and pushed them live near the end of October.  So, how do we know if these new features were useful?  We monitored the adoption rate and saw it jump over 10% (see table 2)!  The upshot of this example is that at PBwiki, we listen to our users so that we can build the best products to solve their needs.

Table 2 – Post-feature enhancement adoption rate

Date Adoption
10/29 41.3%
10/30 41.1%
10/31 40.0%

Web analytics and your privacy
We take your privacy seriously at PBWiki.  As a reminder, the non-binding English summary of our privacy policy is

  • If you mark your wiki private, we’ll keep it private.
  • We don’t share personally identifiable information with others.
  • We hate spammers, too. We’ll try not to bug you with email.

During any analysis, I will be sifting through the 1 billion events that our users have generated over the past few years.  Because of the immense size of our data set, I work with anonymous and aggregate data.  In the analysis of Document Management above, I included over 100,000 wikis and at no point did I need to drill into the specific details of any one wiki or user.

What kind of data would you like to see?

Tip of the Week – Cut down on notification noise with RSS

20 Nov

PBwiki notifications are a great way to stay up-to date on every page of your wiki. However as you wiki grows, it becomes increasingly difficult to see through all those edits and locate what’s important to you.

Cut down that noise with a per page RSS feed.

By subscribing to a page RSS feed, you are alerted to all the changes on just that page of your wiki. This allows you to focus on the pages that are important to you and better manage the notifications from PBwiki.

http://vimeo.com/moogaloop.swf?clip_id=2302026&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=00ADEF&fullscreen=1
RSS on PBWiki from PBwikiWebinars on Vimeo.

Ideas or additional tips? Let me know in the comments!

Tags:

Hiring the Right Support Team

20 Nov

In my last blog post (read it here),  I mentioned that the PBwiki Support Team has changed drastically in the way we handle our tickets and the way we measure ourselves. Another way we’ve changed is in the way we hire.

In the beginning, PBwiki was used by a lot of early adopters of technology – people who were tolerant of some bugs, who enjoyed hacking around in the product, and people who would rather discover and learn for themselves than contact support. To answer the questions that did come through, we hired out of that same pool of users – we pulled 4 support gurus right out of the forums and they became the first PBwiki Support Team.

As our business grew, we discovered two things:

Different users have different support expectations
Our first support team was a group of people who worked for PBwiki between classes, on weekends, and after their normal day jobs. And now, as we grow, we attract more people that require faster response times. Our goal to respond in a set frame of time meant hiring support gurus that can work exclusively for PBwiki. Here, for example, is one of the questions we use to screen the hundreds of applicants we get each month:

Continuing training is important
The second thing we learned is that technical expertise can be taught. The talent and depth of knowledge of our first set of support gurus is invaluable and irreplaceable. As we looked at hiring more support agents, we found that PBwiki experience was not a necessity, what we needed to focus on was hiring for some core values: professionalism, accuracy, speed, and personality. The technical experience can always be taught and learned (in fact, each support guru is encouraged to spend time each day exploring their own wikis).

When we launched our new Pages and Files release, each member of our Support and Sales team was given an opportunity to learn about the feature- and earn some extra cash. We posted a test on oDesk and gave a $25 bonus to any team member that passed with 90%. Here’s an example of a test question – it doesn’t need to be anything hard, just give your teams a chance to be familiar with the new releases:

Case Study: Support Guru Angie
One of our support gurus, Angie, is a great example of our hiring story. Angie applied to work with PBwiki having never used PBwiki. However, Angie possessed other skills that made her a great hire – her communication and responses to hiring emails were instantaneous and her personality shined right through. Angie also possessed another key quality- patience. As a stay-at-home mom to five children, Angie has lots of experience balancing multiple tasks and answering questions. Angie has been with PBwiki for just three months and has picked up all the technical ability to answer most PBwiki questions.

When Angie started with us, she was answering basic questions like how to log into a wiki or how to add an image – questions that could be easily answered by pointing to a section on the user manual, or sending step-by-step instructions. We saw that Angie was responding to people quickly and professionally, and we she asked for more hours at PBwiki, we were happy to give them to her! Before long, we saw Angie answering questions about custom CSS and advanced features. Angie had a personal wiki where replicated different scenarios to learn, fully understand questions, and build her skills.

The key takeaway is that PBwiki isn’t just offering its services to early adopters of technology. We’re offering our services to teachers, children, business people, and everyone in between. In order to connect with all these different users, our support gurus need to be able to understand their needs, their frustrations, and their situation before getting to the technical meat of the question. Our support team is a mix of these skills, and it’s been amazing to watch the support team members advance their skills and knowledge of our product.

Introducing PBwiki Public Editing

19 Nov

Our new feature for public wikis who want global participation and editing on their wiki. Public editing allows anyone to immediately gain access to your wiki — users only have to click “edit” and create a PBwiki account.

This is great if you want everyone to have access and you don’t want the added step of approving everyone. Added benefit — you can create permission levels for these users and even remove them from the wiki.

Administers can turn on public editing in the settings panel. Look for ‘wiki security’ and chose ‘ Anyone can edit this wiki’

Check out these hugely popular wikis already using Public Editing:

And they already LOVE it!

“The success of the BarCamp and Twitter wiki derives largely from the exceptional editing experience of PBWiki. So productive!” – Chris Messina

“We are using it on http://usercontribution.intuit.com and love it! Yay public editing :)” – Jenny Spadafora

This feature is only available for 2.0 wikis. To gain access to this feature upgrade your 1.0 wiki by clicking the “Convert now” flag at the top of your wiki screen. Converting is easy, free and takes one minute!

How do you like your publicly editable wiki?

PBwiki API debut at SF New Tech

17 Nov

This month the PBwiki team debuted our freshly redesigned API at the San Francisco New Tech Meetup.

The PBwiki API is a way for developers to hook into wikis and work with their contents. Using our API, you can do just about anything you can do from your web browser: view pages and files, move stuff around, and edit pages — the works.

We even built our latest set of features – the Document Management release – using our API.

The show Nerdstalker caught up with Mark to hear more about how you can use the PBwiki API on your own wiki. Check out this short video:

The API is enabled by default on all 2.0 wikis, so you can get started right away. Go to your wiki’s settings and click Developer Interface. You’ll see the API keys you need to work with the API and a link to the documentation.

We’re excited to see what folks will build with the API – so be sure to send us your feedback and ideas.

Moving PBwiki Support from Gmail to Salesforce

12 Nov

One of the things we’re focusing in on at PBwiki is how we can become a better support team. When PBwiki launched back in 2005, we had no formalized support, just a forum that our users chatted on. We found a few amazing people on the forums and invited them to join our PBwiki team as Support Gurus. I started working for PBwiki in mid-January 2008. At that time, we handled all support requests through a Gmail email account. As different support agents came to work, we would answer emails from our users. If a ticket needed attention by someone else, it would get starred. We had labels, tags, and a bolding/unbolding system to indicate different status levels. As PBwiki grew, we knew that we couldn’t continue using this system any longer. It was too easy to forget about someone’s case, we weren’t measuring anything, and we had no real accountability to our users.

Welcome Mr. Metrics
Then Paul Singh joined PBwiki as Director of Support. Paul likes to call himself “Mr. Metrics” because of his love of measuring, analyzing, and breaking down data for consumption.  One of his first moves was to take the support team away from Gmail and introduce us to Salesforce. As a newer PBwiki employee, I loved Salesforce. However, it was a difficult transition for some of our support team, who had been used to the easy, but limited in functionality, Gmail support account. Moving to Salesforce was hard, especially as we figured out its limitations and adjusted our workflows.

The Problem with Gmail as Support
While using a Gmail account for support was simple and easy, it lacked in accountability and measurables for the support team. Now that we use Salesforce, Support has a more complex system, but we’re better able to measure and gauge the work we do. We can now pull data on every aspect of the support experience, from what the ticket is about, response times, and satisfaction rates.

What Our Support Team Measures

When we looked at what to measure, we had to focus on what we valued as an organization. We decided to focus on two areas:

1) Response Times: PBwiki aims to respond to all users in a set amount of time. Each of our support team members is measured on how quickly the respond to tickets. Our average initial response time has dropped from nearly seventy hours (January 2008) to two hours (October 2008). That’s twenty-four hours a day, seven days a week.

2) Satisfaction Rate: Answering emails isn’t the whole of what we do in PBwiki Support. We get to know you, get involved in your projects, and help you each step of the way. That’s why we enforce the idea of quality over quantity. A great response time means nothing if users are unhappy. It is up to our support team to make your day and make sure you walk away saying that your experience with PBwiki Support was the best customer support experience you’ve ever had.

We now have a tables, charts, graphs, numbers, and statistics that help support communicate the voice of the user to the rest of the company. Now the support team is taking these metrics to help us respond quickly, efficiently, and effectively to your support inquiries. We’ve come a long way from the user forums.

It doesn't have to be so hard

10 Nov

Before joining the team at PBwiki, I co-founded a small internet startup in the entertainment industry. After a time of blood, sweat and tears, we were finally getting acquired by a larger start-up company. Needless to say, we were ecstatic and eager to get the process started.

Being a very small organization when we started, we didn’t have a lot of processes in place. Communication is less of an issue with fewer players. Unfortunately, the company acquiring us didn’t have much of a structure for us to adopt either, and things got very messy, very quickly. We tried to set up a weekly call, but poor attendance really limited the efficiency of those. We’d send a multitude of emails, but decisions, deadlines, and vital data would get lost or passed over. In short, it was a nightmare.

If I were writing this as a sales pitch, I would tell you now about how PBwiki solved all of our problems; I’m not, and it didn’t. What it did do was provide a great first step to getting things on track. We still send emails that get lost and wiki’s can’t make people attend conference calls, but they do provide a place to document all the decisions and progress that get made. There is no dispute about where the project is going or what both parties agreed upon. We have a clear source of truth to refer to.

PBwiki created a solution to get the project moving. It helped us to simplify a process that was getting much more complicated than it needed to be.  If only PBwiki could be used in all areas of life…

← Older Entries