Stc Presentation2010

1,799 views
1,769 views

Published on

Implementing a wiki-based documentation solution does more than just change a documentation\\’s department workflow. This case study takes a look at how ExactTarget took on the challenge of a new wiki and used it to change the way documentation needs and products are realized.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,799
On SlideShare
0
From Embeds
0
Number of Embeds
1,511
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Inherited an Adobe RoboHelp file from years beforeAbility to modify restricted to a small number of usersLicensing costLack of familiarity with the toolIntimidation factorLengthy publishing process6 editions; 3 output media24 hours to publishHighly inflexible filesDifficult to output to media not already supported by RoboHelpDifficult to convert to other solution
  • Over the years, people across the organization had introduced Word and PDF documents to address the limitation of the online help file, resulting in Microsoft Word and PDF documents floating around the collective consciousness. While these standalone documents provided the flexibility to address particular customer needs, they had an annoying habit of persisting and they had no central inventory. So multiple people would make what was essentially the same document over and over again and plop them out someplace where their customer could find them, customers would hold on to the links to these documents, but no one was making sure the documents were up to date, and customers weren’t getting the best experience.I know I make it sound bad, but this approach met the needs of the people at the time. It got the job done, it just didn’t scale.
  • I wasn’t the only one recognizing the need for some content management, and around the time I was beginning to investigate alternative documentation solutions, one of our product managers was setting up the MindTouch wiki as an internal tool for sharing information within the company. To be honest, I think he was tired of answering the same questions over and over again and wanted a place to dump what he knew and point people there.Of course, this quickly became a primary resource for the documentation and I found myself cleaning up the content dumped there before copying-and-pasting it into my documents. Being lazy, I wanted to stop maintaining this content in two places, and it was just a short leap to begin to see the benefits of using the wiki as our documentation delivery tool. At first, the wiki was not well accepted because it contained spotty information that was allowed to get out-of-date, but as the Documentation team began to process-ize the creation, completion, and maintenance of the date it became the main source of product information within the company. Nowadays, the wiki is hosted on a virtual server with multiple processors and we’ve hired a full time automation engineer to enable workflow and automation.
  • We also had a special challenge in addition to our kitchen full of cooks. Because ExactTarget’s product offering is software-as-a-service, we are able support a model through which part of our clientele are resellers. Reseller take our product and change the branding on it to appear as if it were their own. Then they resell it, maybe with consultative services as a value-add, to their own customers and we get a cut.Of course, these resellers require a user experience where they control the branding. It would be seriously confusing for their customers to have entered into a relationship with reseller ABC but to see “ExactTarget” throughout the documentation. So, we would offer a “white labeled” edition of the online help. In this edition, we used conditional text to remove our company name. However, with the tools we had we could only provide a document that *didn’t* say ExactTarget, we couldn’t provide them a way to brand it themselves. Plus, because of the difficulty of predicting what features would be enabled in the client accounts, we were really only in a position to provide a one-size-fits-all document that covered a set scope of product features, regardless of whether those features were enabled in the client accounts.
  • Stc Presentation2010

    1. 1. CASE STUDY: Developing Wikis as a Documentation Solution<br />
    2. 2. Presenters<br />Amanda Cross <br />Documentation Manager<br />Ryan Williams<br />Documentation Writer<br />
    3. 3. WHO IS EXACTTARGET?<br />Global software as a service leader (600+ employees)<br />Power all types of digital messaging (Small Biz to Global Enterprise)<br />Integrated platform (Email, Mobile, Social, Sites)<br />
    4. 4. Challenges<br />
    5. 5. Challenges – Online Help through RoboHelp<br />Inherited an Adobe RoboHelp file from years before<br />Ability to modify restricted to a small number of users<br />Lengthy publishing process – urgent needs for promptness<br />Highly inflexible files<br />
    6. 6. Challenges – Word and PDF docs<br />People across the organization began to create their own documentation<br />Stored on FTP site, SharePoint, Salesforce, and less expected places<br />No central inventory of documents<br />No plan to keep the documents up-to-date<br />Served the need, but didn’t scale<br />
    7. 7. Solutions<br />
    8. 8. Wiki – Base – MindTouch<br />Uses Mindtouch, available at www.Mindtouch.com<br />Started as personal project for product manager on single machine<br />Main source of customer-facing and internal-only documentation and product knowledge for ExactTarget<br />Now hosted on virtual server with multiple processors with dedicated Automation Engineer<br />
    9. 9. Wiki – Publishing from Base to Customer-Facing<br />We publish a subset of the content in Base to our customer-facing wiki<br />The rest of the content is for internal-use only and may be contributed to and consumed by development, product management, marketing, customer service, and others<br />We use tags to control:<br />What content is published<br />When the content is published<br />Workflow around editing and revision<br />Relationships among pages<br />
    10. 10. Wiki – Customer Facing Edition<br />wiki.memberlandingpages.com<br />A separate instance of MindTouch is available online for external users<br />Contains material published from Base<br />Closed to public comments, but feedback email address available<br />
    11. 11. WHAT DOES THE WIKI DO FOR US?<br />Multiple input points for knowledge<br />Easy move of staged documentation (Base) to customer-facing documentation (Wiki)<br />Instant correction and review of documentation<br />Version control prevents accidental deletion or loss of knowledge<br />Centralized location of knowledge<br />Easy to upgrade and export for future uses or formats<br />
    12. 12. BRINGING THE WIKITO LIFE<br />
    13. 13. Content – Converted <br />Once the wiki was available to customers, we decided all future content would be created there<br />We then converted the old RoboHelp and PDF documents to wiki<br />In some cases, the documents were already structured so it was a copy-and-paste exercise<br />In other cases, the existing doc was just used as source material to create a new, structured document<br />
    14. 14. Content – Created <br />Customer Support contributes use cases and review<br />Developers contribute technical articles, sample code, product details, and review<br />Product managers contribute product details and review<br />When a contributor outside the Documentation Department changes a document, Base notifies the department and allows documentation writers to review and approve<br />
    15. 15. Content – Automated<br />Automatically generated by processing WSDL and other files created by developers<br />The system generates a page in Base for each of the Methods, Objects, and Properties, and uses tags to describe the relationships among them<br />Developers contribute higher-level information, sample code, and review entries<br />
    16. 16. Revenue Generation<br />
    17. 17. Challenges – Resellers and White Labeling<br />Resellers require a user experience in which they control the branding<br />We could provide white-labeled content, but not customized<br />One-size-fits-all scope<br />
    18. 18. WIKI CONTENT – PRODUCTIZED DOCUMENTATION<br />White-labeled documentation<br />Customized versions of existing documents<br />Customers provide branding<br />We provide documentation and updates as a paid service<br />Tiered levels of support<br />
    19. 19. WIKI STATISTICSThe numbers<br />
    20. 20. SCREENSHOT<br />
    21. 21. WIKI USAGE STATISTICS<br />March 15, 2009 – March 15, 2010:<br />64,734 visits<br />318,225 page views<br />4.92 pages per visit<br />Approximately 3500 visitors per month (in recent months)<br />Most-viewed pages include our Web Services API Reference Guide, AMPscript pages, and our Social Forward Service<br />The wiki stores over 1,700 pages of feature guides, solution guides, technical articles, and other reference pages<br />
    22. 22. WIKI CHALLENGES<br />
    23. 23. WHAT DO WE NEED TO WORK ON?<br />Encouraging contributors to participate<br />Promoting company-wide adoption of Base<br />Integrating Base information with other business systems<br />Raising awareness of the information included in Base and the Wiki<br />Developing and instituting documentation standards on Base<br />Working out code sample and publishing issues<br />
    24. 24. Questions?<br />

    ×