A well-developed FAQ (aka frequently asked questions) adds a level of automation to your business.  By creating a set of FAQ that is easy to use, relevant and accessible, you can reduce the amount of time it will take to address very simple customer inquiries.

When are FAQ necessary?

FAQs are strongly suggested for traditional businesses and service providers that sell well-developed and relatively stable products or services (think retail and wholesale outfits, catering companies, wedding planners and music teachers, for example).  Retail and wholesale outfits can use FAQ to address questions related to the ordering process, manufacturing, and shipping.  Catering companies and wedding planners can use FAQ to address scheduling or booking questions.  Music teachers can use FAQ to address questions related to lesson plans, methodology and expectations.

FAQ are always helpful, but not always necessary.  Bottom-line: you need FAQ if you’re getting (or you anticipate getting) a lot of frequently asked questions.  Otherwise, FAQ is optional (see unconventional uses at the bottom of this post for example). Simple as that.

Note: FAQ can be incredibly helpful for online marketers who are launching new products, also.  Online marketers can use FAQ on sales pages and in e-mail marketing for better conversions (since the questions will be addressed upfront).

If you don’t get a lot of questions or if the questions you get are always unique, don’t spend time on FAQ.  Part of effective business process management is doing things that are useful and helpful – don’t waste time on unnecessary tasks!

How should FAQ be formatted?

When the FAQ are basic questions about your products or services, you can list them on a web page or in a brochure.  Note: it isn’t necessary to create a separate page just for FAQ – put them where they are most relevant.  You can use this opportunity to improve your customer experience with your website and/or marketing material.

For example, you could put FAQ that are about your experience and background wherever your About Me information is.  You could put FAQ that are about your products and services wherever that information is present.   And you could put FAQ that are about how to contact you on/near your contact information.

Why use FAQ at all?

Really, the answer has to do with what I wrote at the beginning – developing a good set of FAQ improves your business process by adding a level of automation that would otherwise become laborious and time-consuming.  If you find yourself getting a lot of the same questions by customers hesitant to buy/sign up/schedule a consultation, for example, perhaps you should put together a list of these FAQ and make it accessible to prospective clients and customers.

Should You Spend Money on FAQ Software?

Truthfully, I didn’t know there was such a thing as FAQ software until I began researching FAQ while writing this post.  My opinion is that you do not need FAQ software as a small business owner.  FAQ software is useful for technical writers, software developers, etc.  But for you – you should not be automating your FAQ creation (which is hard for me to say, as someone who assists small businesses in automating their business processes).  Use the FAQ development as a learning experience for you – it can help you get to know your business, as well as highlight some opportunities to improve your business processes.

How to Create the Perfect FAQ

The following is a list of steps you can follow to develop and implement a good set of FAQ for your business.  If you have any questions on how to implement these, send me a message or leave a comment and I will respond!

1. For the next 1-2 months, collect any and all questions you receive in a list.  The questions can be from prospective or current clients/customers. Make a note each time a question is received so you can tell which questions are asked most often.
2. Gather the most frequently asked questions as well as the most useful questions into a separate list.  If you have a lot of FAQ, organize them into sections that make sense.  Splitting them into relevant sections will help people find what they are looking for more quickly.
3. Develop a relevant, accurate answer to each FAQ.  Spend a lot of time on this.  Getting the answer right is just as important as choosing the right FAQ.  If you’re developing FAQ for a website, link the answer to the page on your website that provides more information, if possible.
4. Decide where to put the FAQ.  It is OK to put them all together in a list – this is conventional.  But you can also put them where it makes the most sense contextually.
5. Publish your FAQ.
6. Spend 2-3 months testing your customer/client experience now that the FAQ is available and be sure to use website analytics to determine whether or not anyone is even reading your FAQ (if you’ve placed them on a page on your website, for example).  If you find that 3 months has gone by and you are still getting peppered with the same questions, you need to look at the placement of your FAQ and the overall effectiveness of the marketing tool (brochure, website, chalkboard – wherever you have placed FAQ).

Unconventional (but awesome!) other ways to use FAQ

1. Subliminal marketing: When written well, you can use FAQ to be persuasive in addition to purely informational.  When used in e-mail marketing, for example, you could use FAQ as more of a way to address the questions you think your prospective customers/clients would ask themselves.  Perhaps they would ask themselves what value the new product adds to their life or whether or not the price is worth it.  A well-developed FAQ could answer that question for them.
2. Address how-to: If you sell a product, you can use FAQ to talk about how to use it (if it’s not obvious).  You can also use FAQ to talk about how to use a service or how to contact you.
3. Talk about privacy: Privacy policies use standard language that is usually boring and no one reads it.  You can use FAQ to talk to people about how you manage their information.
4. Show off your personality:  This is your first real opportunity to talk to your customers/clients about things that are on their minds.  So, talk to them like you would talk to them in person or over the phone – be genuine!  A great example of this is the FAQ page over at Mailinator (which I found referenced in a blog post about FAQ).  They even use the term “stupid-head.”    This demonstrates a lot about their personality.  Show yours in your FAQ, too!
5. Generate Backlinks: If your FAQ is interesting and informative enough, you could even use your FAQ to generate backlinks.  See the list of good FAQ examples below.  These FAQ pages have tons of backlinks, which means a lot of websites link to them.

Examples of Great FAQ on Websites

1. U.S. Copyright Office – Relevant, critical FAQ.  Essential for the massive amount of business they do.
2. IRS – Need I say more?  Have YOU ever used IRS FAQ?  I have!
3. Cairns Wedding Planner – Great use of subliminal marketing!
4. OSI Business Services – Another great use of subliminal marketing.
5. Amazon Associates – They’ve integrated FAQ into a huge help section.
6. Dance Dimensions Dance Studio – I like that they’ve shown some personality in both the way the word each FAQ as well as how they answer each one.

Questions? Comments?

How do you use FAQ?  Do you think they’re important?  Do you notice any FAQ on my blog?  What do you think about that?  Please include a link to your FAQ if you would like to show it off!

© 2010, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

Related posts:

1. How Business Process Management Can Help Small Businesses What is Small Business Process Management? Business process management can...

Related posts brought to you by Yet Another Related Posts Plugin.

Business process management can help small businesses in two ways: (1) identifying repeatable processes and (2) automating them.

Automating repeatable processes (straightforward ways of doing things that you do over and over again the same way) saves time and money by removing guesswork, making training easier, and allowing you to take a break from running your business without the whole thing falling apart!

Business process management takes into account the things you do every day to make your business run and lays them out visually, so you can see just how your business looks when drawn out in a diagram.  This is a great way to discover your repeatable processes.  When you work with a small business process consultant, you talk through your business processes, where you can trim activity and where you can ramp up activity, so that your business can run more smoothly and be more profitable.

For example, if you own a small cafe or flower shop and every Monday you take inventory and order supplies, it would be ideal to find a way to automate at least part of that process.  Or, if you run a small organization of 50 employees or contractors, it would be ideal to automate the help desk system or supply ordering process.  If you are a solo entrepreneur, you can automate billing, setting up accounts, tasks you send to your virtual assistant, article writing or blogging, responding to basic questions or concerns, or even your social networking!

Small Business Process Automation in Action

You probably will recognize some or all of these things, but you may not have learned to implement them in your own business.  This is where a business process consultant can help.  Which of these is right for your business?  All of them?  None of them?

• Automated or semi-automated supply ordering (e.g., food, office supplies, etc.)
• Automated new account creation
• Frequently Asked Questions booklets or page on your website
• Help desk system for internal employees or outside clients
• Project management software
• Time tracking systems for yourself, employees or contractors
• Billing management systems
• Online postage/printing shipping labels

There a hundred more we could add to this list.  What have you automated in your small business? Leave a comment; I’d love to hear about additional ways of automating small business processes!

© 2010, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

Related posts:

1. How to Create the Perfect FAQ (and why you should!) A well-developed FAQ adds a level of automation to your...

Related posts brought to you by Yet Another Related Posts Plugin.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

I started to respond to this principle here going one direction, but I forced myself to keep reading it and now I have a different perspective.

While I believe that face-to-face can be more efficient, I do not agree that it is always most effective.  If you look a little deeper into the psychology of people and also into how we interact in groups, I think you’ll find that sometimes, being face-to-face isn’t always most effective.

Even so, it’s not that I don’t believe being face-to-face is effective, it’s that I don’t believe it is always most effective.  And now I am particularly curious as to why someone would think it is always most effective?  Haven’t you ever been in a face-to-face conversation that has gone awry?  Certain types of body language, external distractions, and facial expressions can all hinder good communication.  I’ll be honest with you, some of the clearest, most direct communication I have ever had has come via e-mail.  Straightforward questions, straightforward answers.  Nobody excused themselves in the middle of a discussion to get a cup of coffee or go to the bathroom, and if someone was rolling their eyes, I didn’t see it and wasn’t distracted by it.  What is it about being face-to-face that is so much more effective?

If the principle is more about the other “things” – like a whiteboard or scrap paper – that can help facilitate conversation… I’d buy that.  But the principle specifically states face-to-face conversation.  And, to what degree does there need to be face-to-face conversation, and at what points in the development cycle?  All stages?  I can think of times where my developers would IM me, instead of getting up and walking the 5.5 feet between our desks.  That’s not exaggerating! And I didn’t mind that one bit.

So anyway… this principle has just got me wondering.  Is face-to-face truly the most effective way of communicating to a development team?  If so, why?

© 2010, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

Related posts:

1. The Role of the Analyst in Agile Projects I posted the following as a reply to several comments...
2. Are tech writers obsolete in an agile development world? Technical writing as a role doesn't really fit well within...

Related posts brought to you by Yet Another Related Posts Plugin.

Read my reply here first, and then go read the article.

I find this conversation so fascinating. In my opinion, the ultimate goal is to build something timely that meets the customer’s expectations and needs. Whether or not there is a business analyst active on the development team is a decision that needs to be left up to that team. If you fall into a prescriptive mentality about agile development, you’ve already lost and are no longer agile. You need to do what works for your team and the project at hand.

I disagree that we are all BAs and I strongly disagree with the notion that developers should practice business analysis. I would prefer to work with a developer who writes clean, working code in the best way she/he knows how to do. I want to work with a developer who focuses on the best WAY to accomplish the WHAT. The WHAT is my job. The WAY is the developer’s job. Trying to master both of these things will extend the cycle and also, as a developer, I think you would be happier to not waste your time filtering through the mess of getting to the what, because, it’s really messy.

I’ve worked as a BA on projects where the developers insisted on my presence. I suppose many of you have not had this happen, but in cases where you are a small dev shop and you are dealing with a large PMO [corrected here - typo in original reply] client, you will benefit from having a BA take the reins – from them, really – so that you can manage scope more effectively.

Project managers manage “when.” BAs manage “what.” Developers manage “how.” There will always be back and forth and everyone’s input is certainly necessary but in the end, someone has to be on point for owning that part of it. That’s been my experience. I know it’s really oversimplifying it but keeping it simple rocks.

Link to the article

© 2010, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

Related posts:

1. Feature! Look me in the eye! My perspective on Agile Principle # 6 In the Twelve Principles of Agile Software, # 6 says:...
2. Are tech writers obsolete in an agile development world? Technical writing as a role doesn't really fit well within...

Related posts brought to you by Yet Another Related Posts Plugin.

© 2010, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Boy, were those two completely different worlds of documentation!  In the one setting, we had team fully dedicated to managing documentation – ENTIRELY!  We were documentation specialists.  In the other setting, documentation was either needed or not needed.  It wasn’t someone’s “job” to document, rather, the documentation was a byproduct of the development or business contract.

Of course, I didn’t mind the second setting in the least.  Even though I have a technical writing degree, I completely get the logic behind the theory that documentation is simply a means of communication, and a pretty lousy one at that.

Here’s why:

1. It’s expensive.
2. It’s high-maintenance.
3. It serves no real purpose.
4. The wrong people write it.
5. The right people ignore it.

Traditional documentation can’t keep up with you.  It can’t follow you.  You can’t ask it, “do you get what I’m saying?”  It’s a static, physical object that someone – a live person – must update constantly.  And that takes time.  And time costs money.  Lots of it.  And what’s worse, if you print tons of copies (even worse, in color!) it’s wasteful and bad for the environment.  I abhor traditional documentation (which is essentially blasphemy for a technical writer to say, right?).

Scott Ambler wrote a great piece on this subject a handful of years ago, and you can read it here.  It goes into much more detail (and commentary) than I will here, but it is an excellent resource for any technical writer or manager looking to adopt agile development methods.

In an agile development environment, communication is king.  The focus is taken off of a certain document and instead is placed back onto the what – what does this system do and what do its users do with it?  Business analysts in this setting need to understand modeling and need to have a much higher technical aptitude than a traditional tech writer.  They also need to understand how to write acceptance tests, because these become the building blocks for development.

So are tech writers obsolete in this new world of development?  Sadly, most probably are.  Business clients are being wooed and romanced by the show and tell model – rather than producing endless revisions of updated “documentation” that supposedly reflects what’s actually being developed, agile developers are releasing more frequent builds of in-progress projects.  Business clients can then provide feedback, and changes can be made and released in the next build.

Of course, there are serious pitfalls (scope creep, out of control change requests, etc.) with that process, and this is where the old tech writer can grow into a more functional role in an agile setting.

• If a tech writer can take on business analysis skills, these new BA types can interface with clients and sales engineers (and hopefully, keep them both in check).
• The tech writer/BA can be attractive to the business client, because this type of BA can produce better documentation, which in the end is still always required by the business client (clients need to show documentation to their stakeholders, product marketing managers, etc).
• The tech writer/BA will also be useful to the agile developer (even if she or he doesn’t realize it) by communicating necessary changes (bugs) rather than an endless stream of change requests.  Ultimately, good developers would rather not be face-to-face with business clients.  The two do not share a common language nor a common goal, so it’s best if there is someone in between who can really bridge the gap between those two worlds.

So, in my opinion, yes, technical writing as a function within a development cycle is out of style and organizations trying to adopt agile techniques will need to let it go.  However, technical writers need not jump ship altogether.  Instead, making a transition from king or queen of documentation to king or queen of communication would be a great strategy.

© 2010, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

Related posts:

1. Feature! Look me in the eye! My perspective on Agile Principle # 6 In the Twelve Principles of Agile Software, # 6 says:...
2. The Role of the Analyst in Agile Projects I posted the following as a reply to several comments...

Related posts brought to you by Yet Another Related Posts Plugin.

Here’s the tick-list of things I hope to accomplish:

• Clean out some of my closets and cupboards
• Get to the grocery store at some point (even though is it ridiculously cold out there)
• Put together some puzzles with Aidan
• Read more of The Tipping Point while Aidan naps (I know, I’m behind the times, OK?)
• Do some baking

It’s Sunday.  This should be easier than it probably will be (which is an indication that I need to do this more often).  I wonder what would happen if a large % (and, really, that “large” % could be less than 1%) of heavy internet users actually did that – just stepped away?  I suppose that’s something I won’t know.  But, I’m off to start my No Internet challenge now.  Ready… Set… Go!

© 2010, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I am itching to get back to working with functional and business requirements again (remote/telecommute).  It is very challenging work that I appreciate, because I love software development and I am not a programmer (although I am teaching myself Python ).

I will be posting a few of the articles I’m going to be writing around the subject here, as one way to draw extra visibility to them (hint – an online marketing strategy: marry articles posted with article databases with blog posts).  The resource box will be linked to my LinkedIn page, rather than this website, since the main goal is to draw potential clients to that page to contact me.  As always, my ultimate goal would be to do this work from home.

Feel free to comment on those – and of course, Digg and Stumble them all you want as you see fit!

Cheers and Happy New Year,

Tia

© 2010, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

“In the midst of all of our u-turns, rewinds, re-runs, regrets, and re-do’s, is the mystery of this life that makes it all worth doing – again and again.”

© 2009, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

Related posts:

1. Getting back into technical writing My degree is actually in technical writing, and my very...

Related posts brought to you by Yet Another Related Posts Plugin.

That’s kind of what I’m doing with this thought log, also.  Starting again.  You’ll see that I’ve moved all of my old posts (59 of them) into the Retired Posts category, where they will lay to rest.  This blog has a new purpose now.  I no longer live to work, and I don’t live my work.  I work to live, and my focus has shifted not on what I do any longer, unless it is what I do for others.  Instead, my focus is on living – on breathing, on being, on loving, and for me personally, who I am in God, as well.

Several years ago I abandoned much of who I was, because really, I was frightened and decided I would live by the five senses – only what I could see, feel, hear, taste and touch.  I abandoned faith, because it didn’t give me precisely what I wanted, when I wanted.  As a result, I have been living a faithless life.  For some, that is OK, but for me, it’s led actually to even less assurance, security and peace.  I thought that by abandoning faith, I would find solid ground.  Instead, I headed down a careless, scary road with no light around me and no road signs, either.

So, like I’ve done with my old posts, I’m moving all of the old me into the Retired category, so that I can start fresh (again).  The nice thing about life do-overs is that there’s an endless amount of them.

© 2009, Tia Peterson. All rights reserved. This text may be reproduced with permission. Please contact tia@tiadpeterson.com to request permission to reuse this content. Thank you!

— Tia Peterson

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.