2014 was a good year for Basecamp support. Noah Lorang recaps what last year looked like for the Basecamp support time. Their median response time astounds me. Pretty impressive work from a relatively small team.
there’s a lot of future perfect people. People who have the potential to become the perfect person in the perfect role if just given the right opportunity.
A natural, caring organization designed to create passionate customers stretches and bends. A rigid business bureaucracy looks to nail every T on policies, procedures, and practices—customers be damned.
I’m at Write the Docs today in Portland and will be posting notes from sessions throughout the day. These are all posted right after a talk finishes so they’re rough around the edges.
Ann works at 37signals on their support team. She talked about the launch of their new customer-facing support documentation.
The help pages were designed to be self-service. The old layout organized things as a list of questions. There wasn’t any sense of hierarchy or importance to things. The first question listed was, “What are the ‘Your global feeds’ on the Dashboard?” So why was that the first question? Well, because it’d been clicked on the most times. It’s the most popular question because it’s the most popular question. Ultimately these question lists just didn’t make sense.
Mig Reyes and Ann worked on a new help site that, in short, would be browsable, intuitive, and reflect the actions and activity of users. It also needed to serve as a starting point for people to get up to speed with Basecamp. From the support team perspective they needed a landing page for resources, a flexible tool that provided for multiple ways of using a feature, and they needed a software platform that allowed for all of this to work well.
The new site combined a new CMS along with new help guides targeted toward specific use cases. It’s a cool combination of standalone guides with answers to common questions.
In writing the new docs the support team sought to be more concise in their writing. They also aimed for each doc to tell you specifically what you could do with the feature. Each answer in their FAQ section answers the question briefly while also providing a deep link in to documentation.
To edit content on the support site the team had to create a local development environment. They installed Xcode, Homebrew, git, generate an SSH key for Github, install Ruby, rebenv, bundler, pow, Jekyll, pull the repo from Github, and then bundle install and rake setup. It was that “simple.” They use this setup to stage changes to docs as well. By using git’s branches ability they can prep content before a release. Those same branches also allow for experimentation with the documentation.
In the first 2 months their support site saw 2,000 hits a day and support tickets were down 5% from with the previous system.
Product roast. Cool idea from 37signals about critiquing your product. Given the right environment it would also be interesting to let customers roast your product.
37signals has a really cool footer design. Great way of visually indicating the end of a page.
Bootstrapped, Profitable, & Proud: Coudal. 37signals talks with Jim Coudal about the founding, growing pains, and success of Coudal Partners. A wonderfully honest interview by Jim Coudal.
37signals on hiring. 37signals takes time to discuss their experience in hiring people recently. They make the point that getting a job is not a numbers game. If you’re taking the shotgun approach you’re doing it wrong.
On the Front Lines, In the Trenches. How selling glassware for $9.99 actually makes you a better designer as well. The easier it is for everyone to jump in and interact with users the better your product will be.
Smiley goes public: Now everyone can see how our customers feel about our customer support. 37signals now lets everyone see the 100 most recent ratings of support interactions. Really like the way it’s labeled the “Happiness Report.”