In a discussion on Facebook, someone asked the difference between a beta reader and an editor, and the cost one might expect to pay for the services of either. When I said that one should not pay for beta readers, there was disagreement. However, I still maintain that one need not pay for beta readers.
Consider them your product testers. They’re the focus group who tries out the new invention, samples a new product, gives feedback on an upcoming ad campaign, views an early cut of a movie, or tests a new video game to see if it plays as it should.
If you (or a close, trusted individual) are the alpha reader of your manuscript, then beta readers are the folks who see the final, pre-publication draft. That version can still be a manuscript, or it can take the form of a galley or proof copy of the book.*
In return for their effort on your behalf, give beta readers a signed copy of the published book, or offer to read or test something they’ve created.
But don’t hire beta readers as you would hire an editor. And while editors can provide a similar service in the form of a manuscript critique,** there’s nothing like getting feedback directly from readers — who are, of course, a writer’s intended audience.
UPDATE (8-7-16): The paragraphs below are from a reader’s comments in a Facebook discussion sparked by this blog post. They expand upon and better explain what I attempted above.
A beta tester for a video game or other piece of software enters into an agreement wherein he receives a free or discounted early release of the software to use, and in return, the tester will tell the company what he thinks about the software — what does or doesn’t work, what is or isn’t intuitive, what he would like to see changed or further developed, etc. The beta tester is not paid for his work. He is asked, as an average user, to give the company his average-user opinion of the product. At best, he gets a free copy of the software, but it is both understood and accepted (and generally stated in some Terms and Conditions document somewhere, for legal reasons) in the IT community that beta testers are not compensated.
Testers who are hired on for their services are not hired to come at the software from the average user’s perspective; they are hired to make sure that the software functions appropriately (e.g. program doesn’t crash on loading, save function actually functions, etc.). They are hired to seek out and fix problems with the software, not to provide the average user’s perspective. These testers are not referred to as beta testers, because that’s not the job they do.
A beta reader receives a free or discounted early release of a book to read, and in exchange, the reader will tell the author what he thinks of the book — what does or doesn’t seem to fit or flow well in the story, what does or doesn’t make sense, what he would like to see further explained or developed, etc. This makes a beta reader the exact literary equivalent to a software beta tester. Traditionally, beta readers are treated the same as beta testers — that is, they are not paid for their services. And there is nothing wrong with that.
For clarification, if any reader, compensated or otherwise, provides any services outside what I listed above (other services include but are not limited to any form of editing, proofreading, etc.), then he has ceased to be a beta reader and strayed into editor/manuscript critic territory.
* It’s best if beta readers are honest with you about what works or doesn’t, what they like or don’t like, and are willing to give specific feedback (not merely generic “I hate it” or “I like it” statements, but detailed responses).
Prepare a list of questions for them to answer, so they know what kind of feedback you need. Example: “In the scene where Tara is driving Sven to the airport and they encounter an overturned ambulance, is the dialogue and action believable? Why or why not?”
Keep the questions simple and straightforward, and keep the list short. Try not to make the readers feel they’re doing homework, but make it easy for them to help you.
Also provide readers with a simple way of reporting any typos or grammar issues they find. It’s handy when they provide you a page number, and maybe even a paragraph and a line number — “page 35, paragraph 3, line 7” — as well as a description of what’s wrong (“dipsolve” should be “dissolve”).
** Manuscript critiques may cover such issues as continuity, characterization, worldbuilding, etc. Regular editing may also touch on those issues, but will also focus on the writing itself.
Adventures In Fiction 