Our latest webinar, “How Interactive Documentation Builds Corporate Value (and Esteem from your Colleagues)” was a discussion between Scott Abel, The Content Wrangler and Amanda Cross, Documentation Manager at Exact Target. Scott and Amanda discussed the common myths about the dangers of making documentation social and how joining the online conversation provides you with opportunities for market innovation, building your brand, improving customer experience, and driving revenue. The two also talked about strategies that can be employed to convince others in your organization that using social tools are essential for building customer engagement.
The webinar was an action-packed 60 minutes! The recording and Q&A are now available below.
Live Q&A:
What is the URL for the exact target wiki page?
http://wiki.memberlandingpages.com
Was there a reason that the documentation wiki is not linked from the http://www.exacttarget.com/?
We didn’t make a conscious decision not to include a link to the wiki from the company’s brochure site, but I guess the reason would be that, at the time we introduced it, we wouldn’t have thought of people who are looking for the kind of information that’s in the documentation to wind up on the website.
We now realize, though, that there’s a greater overlap between the audiences of the brochure site and the documentation site, thanks to prospects using the documentation as part of their due diligence efforts before buying. So, it’s probably a good idea to add a link. Thanks for the suggestion.
What is your localization story for content? Traditional localization? MT? No translation? Doesn’t your write-and-revise approach greatly complicate the localization story?
We’re just beginning the process of localizing our content right now, and it is definitely a complicated process. However, I’m not sure whether the write-and-revise approach makes it any more complicated than it would be in any event, given the nature of software-as-a-service delivery.
We’re more in question-asking mode than question-answering mode right now, but our current plan is to update our localized output with every release, which means that non-English documentation could get as much as a month behind the English version. Time will tell whether that approach is acceptable to our customers. We’ll also be discovering ways to optimize our processes for time- and cost-savings in localization as we work through this process, but I don’t know what those are yet.
It looks like you are sliding into a tech support role. Is that a good thing? Can you avoid that somehow?
More and more, consumers are demanding a high level of engagement with the companies they patronize. Combined with the engagement opportunities available through social media, I see all roles in a company now being customer facing. In a manner of speaking, everyone in the company, no matter what their title, is now in customer support, just like everyone in the company is now in marketing, because every interaction customers have with your company influences their opinion of your brand.
So, for our part, we help customers as much as we can. When questions come in and the answer is in the wiki, we direct the reader to that location and then go through the exercise ourselves of thinking about how we could make it easier for that customer to find the answer without having to ask. In our case, our readers really do want to solve their own problems before asking us. It might be a different situation if our users weren’t interested in figuring it out for themselves.
But whenever the issue is something specific to an account (rather than applicable to the software in general), there isn’t much we can do. The support organization has tools to dig into individual accounts and figure out problems, though, so we give the user instructions on how to log a case with support.
Do you do any automatic sentiment analysis on user comments to documentation?
Only very rudimentary: people can choose thumbs up or thumbs down when they fill out the form. At the end of the month, I count up how many of each we got. This is, of course, highly subjective. One person will say a page is helpful even if it didn’t answer their question, while another person will say a page is unhelpful anytime they’re reporting a problem, even if that problem didn’t interfere with that usage of the page. Even so, our percentage of thumbs-up comments has steadily increased since we introduced the feedback form.
We have a similar problem with getting execs to even allow public access to our docs. What got through to yours to allow this, and then a wiki?
In my case, the question didn’t used to be top-of-mind for most people in the organization, so I could get away with just taking safe opportunities to publish in an open way. When people internally would ask, “are we sure we want this information to be public?” I would send them an article I had written on the topic.
The article is available, in modified form, on The Content Wrangler at this location:
http://thecontentwrangler.com/2011/08/05/join-the-technical-conversation-an-argument-for-open-software-documentation/
With new product development centering around contextual user assistance, the openness of the technical information is more top-of-mind, and we have a couple VPs who really do a great job of advocating for openness when it’s appropriate. If you don’t have anyone who will advocate for openness, you might be able to convert someone to your way of thinking with the arguments in the article.
Interactive socially enabled doc formula. Do you have a direct line w/dev to get the answers? What if you don’t know the answer. “What if it damages our company?” How do you get past that fear when promoting this to execs?
Regarding getting answers – First and foremost, the documentation writers on my team are expected to be experts in the product and take responsibility for the technical accuracy of their documentation, so we are, ourselves, the first line of defense.
We are able to become experts in the product because we are involved in the development process right from the design phase. Not only does that participation allow us to see the evolution of the product from the beginning, but also allows us to form relationships with the developers, testers, product managers, and everyone else on the team so we do have resources when questions come in that we don’t know the answers to. Like all business, we get things done by relying on our personal relationships.
Regarding “what if it damages our company” – I think that selling executives on this idea requires you to understand what’s important to executives and explain it to them in their language.
- If you have an executive that’s proud that your company is the innovator in your space, then explaining how open communication is a market signal of that fact can go a long way.
- If you have an executive that’s espoused transparency in business practices, then talking about how open communication demonstrates your commitment to transparency might work.
- If you have an executive that only cares about money, then talking about how open communication is excellent for SEO and drives qualified leads is the way to go.
And if none of those positive techniques work, there’s always the scare tactic: conversations are already happening about your product—online and in real life—and the only chance you have to influence those conversations is to participate in them. If you don’t, people have no choice but to accept part-and-parcel what your critics, detractors, and competitors say about you.
All of these techniques are discussed in a little more detail in this article on The Content Wrangler.
How is security around proprietary information governed?
Information that is truly proprietary is not included in the documentation at all. To me, there’s no problem with keeping your secrets. The challenge I see is when organizations are too quick to classify ALL their information types as “proprietary” without doing the analysis and end up making it unnecessarily hard for their customers to get to the information they need. These content types are no-brainers to keep secret:
- Content that must be protected by law, such as classified material or information that regards national security
- Personally identifying or private information about customers, employees, suppliers, etc.
- Anything that could identify opportunities to would-be attackers, such as security vulnerabilities in your software
- Content under trade secret protection
- Pricing information, especially if you routinely offer discounts and incentives
Outside of those categories, it’s a process of examining the information type to see whether having it openly available poses any genuine threat. Ultimately, it’s a question of costs and benefits—will having this information available to customers benefit them enough that it’s worth the effort and risks of making it public – and that’s a question that has to be answered by each organization for itself.
How do you handle publishing documentation for multiple versions of one product? That is, do different versions impact how you integrate the social aspects?
The software-as-a-service model makes it so we really only have one version of the product, so this isn’t a challenge we’ve faced ourselves. I know, though, that one of MindTouch’s case studies is on the Autodesk documentation solution, which does have versions and is also socially enabled. You can check out that case study here.
I am interested in proposing such a solution — it sounds perfect for our user base. Can you suggest resources to create such a proposal?
The Content Wrangler has a lot of good stuff that might be able to point you in the right direction (plus a community to fill in any blanks). My article, Join the [Technical] Conversation links to a lot of outside resources that I’ve used in making my case internally.
Can you please repeat her name and contact info?
Amanda Cross
Documentation Manager at ExactTarget
across [at] exacttarget [dot] com
AmandaCross17 on Twitter
http://www.linkedin.com/in/amandacross17
Does management ever view negative feedback as a reflection of the writer’s performance and the writer then feels his job is threatened? Did you have to change management’s mindset on this?
It is easy to see that thumbs down and mentally equate it to poor performance on the part of the writer. Of course, you and I know that there are all sorts of reasons other than bad writing that a reader might give negative feedback: maybe the answer to their question was there, but they were looking in the wrong place; maybe they don’t like how the software itself works; maybe they’ve encountered a bug.
I’d like to say that explaining this clears the whole problem up. I think it does help, but getting acceptance of poor customer feedback scores from management is a whole lot less fun than getting good customer feedback scores in the first place.
If possible, set expectations that you’ll be monitoring the feedback over the course of some period of time (or don’t tell the execs that you’re gathering feedback until you have improvements to show), so that you have a chance to respond to feedback and see improvements. Following up with individual customers to find out if they’re happy that you incorporated their ideas can be a great source of positivity.
Another possibility is to find out what kind of feedback scores other parts of your company are getting so you can have a basis for comparison. A 75% thumbs up rate might look like a “C” but if the help desk is only getting a 70% approval rating, then that helps put your number in perspective.
And if no amount of perspective will make your feedback scores look good, approaching conversations with execs with a proactive plan to improve the scores (and then really following through with them) will make you an asset rather than a problem.
My managers are just finding out about the added value of good documentation. What’s the pitch to get them excited about connecting with clients? 
Here’s a good one for selling the bottom-line impact of good documentation. It’s a quote from Aaron Fulkerson of MindTouch in an article in Forbes.com:
Documentation, once siloed in the realm of how-to guides, is actually feeding top-of-the-funnel activity. In fact, some companies that I have spoken to are reporting that their documentation is bringing in over 50% of their qualified leads. I can report that my company receives 70% plus of our site traffic from organic sources, and our documentation generates more than half of our overall site traffic. Furthermore, over half of our lead generation is driven by our documentation.
Did Amanda use Mindtouch to create the Wiki? How did she choose to go with Mindtouch?
MindTouch was initially chosen by one of our product managers when he wanted to create an internal repository of product knowledge. Such a tool was, of course, of great use to me in creating the documentation, and after a couple weeks of using cleaned up wiki content in the documentation and then turning around and making those same changes back into the wiki, it became clear that publishing an instance of the wiki content to customers would be a whole lot more straightforward.
The product manager who chose the software researched several wikis at the time and found MindTouch to be best of breed. One of the great benefits it offers now is the Dream API, which we use extensively for the content automation we do. MindTouch now also offers a suite of technical communication tools, and we’ll soon be making use of their multi-lingual capabilities.
Wikis can contain a lot of information. What are some of the strategies or tools you use to make it easier for users to find the subject they’re interested in in the wiki?
The tools we currently use to help users find what they’re looking for in the wiki aren’t anything new:
- Hierarchical navigation that corresponds as closely as possible to the hierarchy within the product
- Search
- Hyperlinks within text to take readers to related articles
- A little bit of role-based documentation, like getting started guides for developers versus for UI users
What we’re working on for our new products, though, is a highly contextual help system that will apply a lot of intelligence to presenting the information that the reader is most likely to want.
On the interactive socially enabled doc forum, what if you don’t know the answer to the customer’s question?
I guess it depends on why we don’t know the answer. If the customer is asking about feature functionality that we don’t know about, then that’s a red flag that we need to jump in and figure it out. If the customer is asking about something specific to their account, then we refer them to contact customer support.
What sort of organizational cooperation, if any, do you get from the dev and/or support staff in order to respond to customer questions to which you do not know the answer?
We in documentation seek out as many opportunities as we can to collaborate with other parts of the organization, whether for official customer-facing technical documentation or just to help out with their information management projects. By doing so, we create relationships with people in the majority of departments in our company which we can use when we’re tracking down information we don’t already have. The fact that we seek out opportunities to help other departments to solve their problems puts us in a good position to ask for help down the road.
It sounds like a tit-for-tat kind of situation, but it really isn’t like that. We try to take the first step in demonstrating a dedication to interdepartmental collaboration for the benefit of the customer and thereby make it safe for others to do the same. My company isn’t a particularly cut-throat place to work anyway, but when people see that you’re genuinely dedicated to serving the customer and not just out for yourself, it makes it that much easier for them to feel good about helping you.
Interested in attending our next webinar?
Tune in with Scott Abel and Kristina Halvorson this Friday, August 19, 2011 in “Don’t Overlook Governance! Understanding The Need For Control In A Web Content Strategy”. Sign up Now!
