[Introduce ourselves]ADAM explains that he no longer works at ExactTarget [I think I’ll only do this for the STC Chicago meeting, mainly because people know I no longer work there and they’ll be confused]
RYAN[you can introduce the company, since I don’t work there anymore]ADAMSome ways that you might have been reached by ExactTarget is through several of our clients. If you’ve ever booked travel through Expedia, your confirmation email and email receipt came through our system. Several major banks are ET clients, so it’s possible that your e-statements and notifications come through ExactTarget as well. If you use Twitter and have ever tweeted with Nike, Delta, or McDonalds, the tweet came through SocialEngage, one of our products.
ADAMEven though ET is a marketing company, we work in the documentation department, which isn’t so marketing-y. But, our audience is marketers. We need to think like marketers in order to produce documentation they would find useful. So here are a few things we implemented.
RYAN:[Go over slide]
ADAMWe encourage our readers to get in touch with us, and luckily we work for an organization that encouraged that sort of interaction. We wanted to hear from our readers for several reasons: We didn’t know if people found the information helpful How else would we know our readers and what they were looking for if we didn’t have conversations with them? We suspected that if our readers had the chance to provide feedback, they would be brutally honest, which could only strengthen the documentation.So, as Ryan said, we put a feedback form on the bottom of every page. [Read slide]. When you do something like this, you really have no idea how it’s going to be received. We could get a lot of negative comments, a lot of praise, or nothing at all. After all, when you see a feedback form on a webpage, you probably assume it goes into a black hole and no one will ever receive it. Well, to some people’s surprise, feedback started rolling in. Slow at first, but before long, our workflow was defined by our feedback emails.
ADAMWe were receiving all this feedback and we had to decide how it was going to impact our documentation. Sometimes it was an easy decision (if someone points out a typo, we obviously need to fix that). But other times, a user would have a recommendation that would drastically change the format or structure of the document. This is where we had to make a decision. Do we put in a lot of work to please one client or do we draw a line in the sand and say “thanks, but no thanks”. One of our corporate values is customer satisfaction, so we decided that we would try to meet every customer request to the best of our ability.Or they’d just send in something totally wrong. Then we have to point that out tactfully.RYAN[talk about Code@, and anything else relevant on this slide]
ADAMSo we had feedback rolling in, our workload increased, and our customers had our email addresses – what were we getting out of this?
ADAMBut, despite all our successes, there are still things we can do better.
Online Help Solution • Help presented via hosted and cloud-based wiki solutions – http://wiki.memberlandingpages.com – http://docs.code.exacttarget.com – Lexis • Edited in internal staging environments, pushed to public- facing instances • Includes an online feedback mechanism
Get In Touch With Us! • Each page in all environments includes a feedback form. • Submitting a comment by form sends out a “This page was helpful” or “This page was NOT helpful” email. • OUR NAMES ARE ON THE FORMS. • Every email goes to specific author. • An email message can contain return contact information, random comments about Justin Bieber, etc.
Workflow • User sends the email message. • We receive the email message. • We respond in a variety of ways: – We thank user for recognizing our awesome efforts (it happens sometimes). – We dig up relevant information for the user. – We forward the user on to Global Support. – We make requested corrections. – We commiserate with user on the state of the world.
You actually change the documentation? • If mistakes were made, we rectify. • If there’s a better solution, we verify and implement. • At CODE@, we actually foreground user code samples and efforts if they’re better than what we initially provided (it happens sometimes). • Change is easy! – Quick edits – Versioned – Single-sourced information
It’s quite rewarding… • Close contact with users promotes confidence in documentation and product. • We learn as they learn. • Even our own employees use the feedback form, which breaks down silos and enhances collaboration. • Feedback allows a direct response to problem areas in documentation. • Feedback promotes swift attention to issues.