Back to the table

18 Intermediate Br Beta Readers Drafting & Publishing

Beta Readers

Test readers who react before the book is published.

What it is

Beta readers are ordinary readers who read a finished but unpublished draft of your book. Then they tell you what happened to them while they read it.

That last part is the whole job. They report what happened, not what you should change. They tell you where they got lost and where they started skimming. They tell you where they guessed the twist forty pages early. They tell you where they put the book down for the night and how easily they picked it up again. They tell you where they laughed, where they cried, whether the ending felt earned, and whether they'd buy the next one.

The name comes from software. A beta is the version you hand to real users before release, to find the faults your own team can't see anymore. The comparison holds up well. A beta reader is the first person who doesn't already know what you meant. Improving your prose is someone else's job.

Beta readers are easier to define by what they aren't. Almost every problem writers have with them comes from mixing up one of these roles with another.

Where do they fit? After your own structural revision, and before line-level polishing and editing. Send a raw first draft to volunteers and you waste their goodwill on problems you already knew about. You also burn through readers you can't easily replace.

People don't all use these terms the same way. Brandon Sanderson's own FAQ, for example, describes alpha readers as the industry professionals around him: his editor, his agent and his writing group. His beta readers are a test audience of people who like books, recruited mostly from his fan community. Now and then he also picks someone for specific expertise, such as someone who works in medicine reading a medical scene. Some writers add a third round of pure error-hunting after everything else is fixed. The labels matter less than being clear, every time you send a file out, about which of those jobs you're asking for.

ARC readers are a different job, with different rules. An ARC, an advance review copy, goes out when the book is finished, edited, formatted and locked. Nothing in it is going to change. The ARC reader isn't there to help you fix the book. Their job is to read it before launch and, if they choose, post a review at or near publication, so the book doesn't go on sale with an empty review section. Beta readers work on a draft and report privately to you. ARC readers work on the final book and report publicly to everyone. Mixing up the two is the most common mistake in this whole area. Some writers send ARCs while there's still time to change things, and then can't change them. Others send drafts to people expecting a launch-day review, and end up with public reviews of an unfinished book.

At the time of writing, September 2026, most copies go out through services or through your own mailing list. NetGalley, which launched in 2008, hosts digital review copies for publishers and authors, who pay. Members (reviewers, bloggers, librarians, booksellers, media) use it free, and NetGalley's own pages say plainly that feedback isn't guaranteed. BookSirens says on its own site that it connects authors with a community of more than 51,000 reviewers, and it doesn't promise reviews either. BookSprout and StoryOrigin work in the same space. Prices, terms and reader numbers on all of these change. Check each service's own pages instead of an article about them, and that includes this one.

The rules that matter are the retailer's, so read them yourself instead of taking them from a blog post. Amazon's Community Guidelines for amazon.com, read on September 26, 2026, say customers are allowed to review free books from authors or publishers, including advance reader copies. The author or publisher "can't require a review in exchange for free books or try to influence your opinion". The same page says reviews created, edited or removed in exchange for compensation aren't allowed, and neither are reviews from people with a personal connection to the author. Amazon also limits who can post reviews at all, so check its current rules before you ask readers for one. Those are that retailer's rules on that date, on that page, and they get revised. Read the current version before you build a process on them, and check the matching page for any other store you sell through.

In practice, ask for an honest review, never a positive one, and never make the free copy depend on getting one. Keep your beta readers off your ARC review team. The people who helped you fix the book are the very people a platform may see as personally connected to you.

The other risk is leaks. An unpublished manuscript out in the world is a file you no longer control. NetGalley itself published a notice on December 23, 2020, about a security incident two days earlier. Someone without permission got into a backup of its member database, which held member names, email addresses and passwords, though no financial data. That was reader data and not manuscripts. The principle is the same. Every copy you send is a copy that exists. Send individually addressed files instead of one open link. Number or watermark them if your tools allow it, and keep a record of who has which copy. Ask for a clear agreement not to share the file, quote from it, or post plot details before publication. Say the word spoilers out loud. Beta readers are often keen fans, and a well-meant comment in a Facebook group can give away your midpoint eight months early.

Why it matters

You can't read your own book for the first time. That's no figure of speech. Being the author puts a permanent limit on you. You know which reveal is coming, so you can't feel it when it's missing. You know what the character meant, so a line that could go two ways reads clearly to you. You've read chapter three eleven times, so you can't tell whether it's gripping or just familiar. Every trick for reading your own draft cold, the drawer, the printout, the different device, tries to fake something a stranger gets for free. If you're writing on a production schedule, the case gets more specific than that.

It runs in parallel, and almost nothing else in your pipeline does. While five readers have your manuscript, you're writing the next book. A beta round that takes three weeks costs you almost no working time. Compare that with a structural edit you have to sit and wait for.

It protects your reviews, and your reviews are an asset. A problem found by six beta readers costs you an email and a week's work. The same problem found by six hundred buyers costs you one-star reviews that sit on the product page for good. It hurts your read-through rate into book two, meaning how many readers go on to the next book, and the algorithm quietly stops showing the book to people. No quality control in publishing costs less than beta readers. It's also the only kind that happens before the money is spent.

It catches the everyday faults nothing else catches. Two characters whose names begin with the same letter, so readers kept mixing them up. A point-of-view switch nobody noticed. A clue you thought was subtle that three people spotted right away, and one you thought was obvious that nobody saw at all. A timeline that says Tuesday twice. None of these is a craft failure. They're the ordinary noise of a long manuscript, and you can't see them from the inside.

It tells you whether the promise is being kept. Readers of your genre know what the book is supposed to deliver. They'll tell you when it doesn't, usually in a sentence that sounds like a complaint about something else. When a romance reader says the middle dragged, it often means the couple were apart too long. When a thriller reader says they got confused, it often means the pace outran the plot. Betas are also the only cheap way to test a blurb. Send it to people who haven't read the book and ask whether they'd click.

In a series, it adds up. Readers who've read books one to three will catch the contradiction in book four that you won't. They're holding the whole thing in their heads as readers. You're holding it as a filing system. Record what they find in your continuity bible, so the fix carries into the next book.

There's a human part too, and working writers underrate it. Drafting is a long stretch of not knowing whether the thing works. When five people finish the book and argue about the ending, that's proof you've written a book. You'll be glad of it on the days when the next one isn't going well.

Real-world examples

Jane Austen's Opinions of Mansfield Park and Opinions of Emma (c. 1816): beta feedback that contradicted itself

Some time around 1816, Jane Austen wrote down what her family and friends thought of two of her novels. The manuscripts survive. The British Library holds them as Add. MSS. 41253A, and they're transcribed in the free scholarly edition at janeausten.ac.uk. They're headed Opinions of Mansfield Park (that novel came out in 1814) and Opinions of Emma, which came out at the end of 1815. Selections appeared in her nephew's Memoir of Jane Austen in 1870, and R. W. Chapman printed them in full in 1926.

They're the oldest beta-reader spreadsheet in English literature, and their most useful feature is that they don't agree.

On Mansfield Park, her brother Francis found Fanny Price a delightful character. Her niece Anna disliked Fanny and was delighted by Mrs. Norris. Miss Lloyd was delighted by Fanny and hated Mrs. Norris. Her nephew George disliked Fanny and liked only Mary Crawford. Several readers thought the book wasn't as good as Pride and Prejudice. Miss Lloyd preferred it to everything Austen had written. Two readers, separately, objected that Henry Crawford's behavior late in the novel wasn't believable after what had come before. Austen's sister-in-law thought it was perfectly natural.

On Emma, the notes are even more scattered. Cassandra Austen ranked it above Pride and Prejudice and below Mansfield Park. Her brother preferred it to both. Fanny Knight couldn't bear Emma herself and found Mr. Knightley delightful. Miss Bigg thought there was too much matchmaking in it. Austen's mother found it more entertaining than Mansfield Park and less interesting than Pride and Prejudice.

If you've ever run a beta round, you'll recognize this document right away. Its lessons still hold two centuries later.

As a verdict, the whole pile is worthless. As a map, it's valuable. No ranking comes out of it. A cluster does. The main character of each book split readers sharply. The comic monsters were the most-mentioned characters. One specific late plot turn drew the same objection from more than one reader, each on their own. That cluster is a signal. "It was inferior to Pride and Prejudice" is not.

The strongest signal is often something the author already suspected. Her nephew's Memoir reports that when she began Emma, she said she was going to take a heroine whom no one but herself would much like. The readers duly reported it. A note that confirms a private doubt you've been avoiding is the most useful note in the pile, and the easiest to brush off.

Best of all, at about the same time, Austen wrote Plan of a Novel, according to hints from various quarters. The short satirical outline is now held by the Morgan Library in New York. She took the suggestions she'd received, including some pressed on her by the Prince Regent's librarian, James Stanier Clarke, and put them together into one deliberately absurd novel. Notes in the margin record whose idea each part was. Nobody has made a neater argument against putting your feedback into the book just as you got it. Every suggestion in it came from a real reader, and together they add up to nonsense.

Neil Gaiman's rules in The Guardian (2010) and Stephen King's On Writing (2000): who to send it to, and how to settle a tie

In early 2010, The Guardian asked a number of novelists for their personal rules of writing. Neil Gaiman has since reposted his answer on his own Tumblr. Two of his eight rules sum up how this whole element works.

Rule four tells you who to send it to. Put the draft aside, read it as though you'd never read it, then show it to "friends whose opinion you respect and who like the kind of thing that this is". That last part is where most writers choose wrong. You want someone who likes the kind of book you've written. You don't want the most well-read person you know or your most critical friend. A reader who doesn't read cozy mysteries can't tell you whether yours is a good one. They can only tell you that they don't like cozy mysteries, and you knew that already.

Rule five tells you how to read what comes back. When people tell you something is wrong or doesn't work for them, they're "almost always right". When they tell you exactly what's wrong and how to fix it, they're "almost always wrong".

Treat that as law. Readers are instruments, and they're well tuned for one measurement: their own experience. I was bored here. I did not believe this. I could not remember who this was. I skipped to the end of this chapter. Nobody is better placed to report that than the person it happened to. You can't argue with it, either. It's a fact about them, not a claim about your book.

The moment a reader moves from reporting to prescribing, they lose that accuracy. Now they're doing your job with a fraction of the information. They're usually offering the first fix that came to mind: cut the subplot, kill the sister, start at chapter three, add a prologue. The prescription is still useful, as evidence about what went wrong. Someone who wants a prologue is usually telling you they felt lost in chapter one. Someone who wants the sister cut is usually telling you the sister has no purpose.

Stephen King's On Writing (2000) gives you the other half, for when readers disagree. He puts it as a sports rule. When some readers love a thing and others hate the same thing, it's a tie, and the tie goes to the writer. When everyone who reads the book reports the same problem, you have a problem. No rule for conflicting notes is cleaner. It's the reason to count your notes instead of weighing them.

Bloomsbury and Harry Potter and the Philosopher's Stone (1996): the test reader who answered the only question that mattered

In 2017, talking to ABC News about twenty years of Harry Potter, Bloomsbury's Nigel Newton described what happened when the manuscript of Harry Potter and the Philosopher's Stone reached him. It had already been turned down elsewhere. He gave a photocopy of the opening to his eight-year-old daughter, Alice. By his account, she came back an hour later and told him it was so much better than anything else, and that he had to publish it. He has said she went on asking for the rest in the months that followed. He approved an advance of £1,500, later raised to £2,500. The book was published in June 1997.

The lesson isn't "find a lucky child". It comes in two parts. First, the reader was the right reader. Newton was a publisher, so he could have read it himself, and he had. What he didn't have, and couldn't have, was the reaction of someone in the book's intended audience. His daughter was one. Gaiman's clause applies again: someone who likes the kind of thing this is.

Second, the most reliable signal a test reader gives you is what they do, not what they think. Alice Newton didn't deliver a structural report. She read fast, came downstairs excited, and kept asking for more. Behavior like that outweighs any amount of careful opinion. Design your beta questions to capture it. Where did you stop? How quickly did you come back? Did you ask for the next one?

An everyday scenario: the questionnaire that finally produced answers

Round one on a fourth-in-series romantic suspense went out to six people, with a cover email that said, more or less, let me know what you think.

Four replied. Two loved it. One loved it and pointed out a typo on page two. The last one said the middle was "a bit slow but that might just be me". Useful information in total: none. The author spent two weeks guessing which middle.

Round two, on the next book, went out to nine people. This time the file had visible chapter numbers, a two-week deadline and eight questions. Seven replied.

Five of the seven named chapter fourteen or fifteen as the place they stopped and didn't come right back. Two said they'd been confused about why the detective was still on the case. One said she'd guessed the killer in chapter six and was annoyed. One wanted the sister's subplot cut. One said, in the last line of her email, that she'd cried at chapter twenty-nine, which the author hadn't expected.

The prescriptions all conflicted. The map didn't. Chapters fourteen and fifteen were where the investigation lost its official reason to go on, and the two confused readers were reporting the same thing from a different angle. The sister's subplot was fine. It sat in the place where that missing reason should have been. The fix was one new scene in chapter thirteen and a change to the detective's orders in chapter eleven. Those were one to four chapters before the place anybody complained about, and that's where fixes usually live. The reader who guessed the killer in chapter six got one clue moved later. The reader who cried at chapter twenty-nine got nothing changed, and the author noted the page number for the next book.

Try it yourself

  1. Decide what this round is for, and send at the right moment. Beta readers go out after your own structural revision and before the line pass. Write down the two or three questions you really don't know the answer to. Does the middle hold? Does the ending pay off? Is the love interest likable? Those questions become your brief.
  2. Recruit about twice as many readers as you need reports from. Five or six usable reports is plenty. Three is enough to see a pattern, and ten is a project-management problem. Invite eight to twelve and expect a third to a half to vanish, which is normal and not personal. Your own mailing list is the best place to look by far, because those people chose you. You can also try genre reader groups, or the Goodreads Beta Reader Group, which listed 29,773 members on September 26, 2026. On Reddit's r/BetaReaders, writers post a genre, a word count and an offer to swap. There are long-running critique communities too. Critique Circle, online since October 2003, makes you earn credits by critiquing before you can submit. Scribophile works the same way with karma points. Don't use your partner, your mother, or the friend who doesn't read your genre.
  3. Send a clean, readable file. Send an EPUB or a PDF with visible chapter numbers, formatted like a book, with a plain note at the front saying it's an unedited draft. Don't send a Word file with your tracked changes still in it, or a Google Doc with comments turned on, unless you really want line notes. At this stage you don't.
  4. Write a brief that closes the doors you don't want opened. Keep it to two or three sentences. Give the deadline, say you're after their reading experience and not corrections, and ask them plainly not to fix your typos. Give a real date, and say what happens if they can't finish. Telling you where they stopped is the single most useful thing they can send, so stopping isn't failure.
  5. Ask questions that can only be answered by having read the book. Use the ten questions below. Adjust the chapter numbers, and put them at the end of the file as well as in the email.
  6. Go quiet while they read. Don't explain, don't defend, and don't send context. If a note really is unclear, ask one factual question and no more: "when you say the middle dragged, which chapters were you in?" That one question tells you more than all the rest of the back-and-forth.
  7. Collate before you judge. Make one grid, with chapters down the side and readers across the top, and put every comment in the cell where it happened. Patterns show up in the grid that you'd never see in seven separate emails. The grid also stops the most articulate reader from taking over the round.
  8. Apply the counting rule. When three or more readers report trouble in the same place, that's a fact about your book. Act on it. When readers split for and against the same thing, it's a tie, and the tie goes to you. If one reader with relevant expertise reports a factual error, check it, no matter how many others missed it. One reader with a strong opinion nobody else shares is taste, and taste isn't data.
  9. Diagnose the fix yourself, and look earlier. The place a reader notices a problem is usually a few chapters after the place that causes it. Boredom in chapter fifteen is usually a stakes or pacing failure in chapter twelve. Disbelief in chapter twenty is usually a missing setup in chapter four. Never make a change you can't explain to yourself in one sentence.
  10. Close the loop, every time. Thank everyone within a week, warmly and without guilt-tripping, including the ones who ghosted you. Tell the readers who finished one or two things you changed because of them. Nothing makes a volunteer more likely to come back. Offer them their name in the acknowledgments, and ask before you print it. Then send them the finished book free.
  11. Run the pool as a standing asset. Keep a simple list of what each reader read, when, whether they finished, and how useful they were. Rate them without sentiment. The reader who sent back three sharp sentences on time beats the one who sent four pages late. Rotate them, so nobody reads three books in a row and starts reading like a writer. Recruit two new readers every round to replace the ones who drift away. Tell them in advance roughly how often you publish, so a request every four months is expected and doesn't feel like an imposition. Keep this list separate from your ARC list: different people, different job, different ask. See self-publishing for where each one sits in a launch.

The ten questions, to copy into the email and the end of the file:

  1. Where did you stop reading, each time you stopped? Note the chapter.
  2. Was there anywhere you skimmed or skipped? Which chapters?
  3. Was there anywhere you were confused about who was speaking, where we were, or when this was happening?
  4. At the end of chapter 10, what did you think was going to happen? Did the ending deliver on that?
  5. Did you work out [the twist] before chapter [N]? Which chapter?
  6. Which character did you want more of? Which did you want less of?
  7. Was there anything you did not believe: a decision, a coincidence, a reaction?
  8. Was there anywhere you felt something? Mark the spot, even if you cannot say why.
  9. If you had read the blurb and then this book, would you have felt you got what you were promised?
  10. Would you buy the next one? One line on why or why not.

Common mistakes and misunderstandings

Asking "did you like it?" No other question is so sure to get you a useless answer. From a volunteer who knows you, the truthful answer is always some version of yes. You should be able to answer every question on your list with a chapter number, a name, or a description of something that happened to the reader.

Sending the book too early. A first draft doesn't need beta readers. It needs you. Volunteers who read a draft full of problems you already knew about will hand you a list of those problems. Then they won't be around for the version where their answers would have mattered.

Sending it too late. If the file has been edited, proofread, formatted and uploaded, you aren't running a beta round anymore. You're collecting compliments and inviting notes you can't act on.

Using friends and family. The trouble isn't that they lie, though some do. They can't unknow you. They read your book as evidence about you, which makes their reaction warm and sincere and completely unusable. There's a practical reason to keep them away from the review side too. Platforms take a dim view of reviews from people personally connected to the author.

Recruiting readers from outside your genre. A literary reader will tell you your thriller is thin. A thriller reader will tell you where it sags. Only one of those is a bug report. See reader promise.

Letting them line edit. If you don't say otherwise, most readers fall back on the only editing they know: sentences and commas. Then you get a hundred comma notes and nothing about chapter fourteen, and you've used up a reader on it.

Arguing. Explaining to a reader why they shouldn't have been confused doesn't un-confuse them or help the next reader. It reliably ends the relationship. The report is the report.

Making every change readers suggest. Austen poked fun at this mistake in Plan of a Novel. Take every suggestion and you end up with a book built by committee, which is worse than any of the single opinions that built it. Treat a reader's suggestion as a clue about what they went through, not as an instruction.

Weighing instead of counting. One confident reader with a clear, well-argued case will always sound like everyone agrees. They're one reader. Put them in the grid with everyone else.

Treating a split as a verdict. If half your readers love the ending and half hate it, you don't have a problem to solve. You have a strong ending. Go back and read the Opinions of Emma again.

Expecting reviews as payment. Beta reading is a favor, and so is an ARC review. Make either one depend on the other and you end up on the wrong side of retailer review policies, and on the wrong side of readers who'll notice. Ask for honesty, never for stars.

Paying for it and then trusting it. Paid beta reading services exist, and some are good. A report you've bought comes with a pull toward being encouraging and detailed, when what you need is accurate. If you're paying, you're close to paying for an editorial assessment anyway. Think about buying the thing that comes with a diagnosis. See editing.

No deadline, and no plan for ghosting. Without a date, drafts sit unread for months. Assume a third to a half won't finish, invite enough people to cover that, and never chase a volunteer twice. The one who read four chapters and told you where she stopped has given you real data. Thank her properly, and she may finish the next one.

Forgetting the file is out of your hands. Send individual copies instead of an open link, and ask clearly for no sharing and no spoilers before publication. Even large professional platforms have had incidents. NetGalley's own breach notice of December 2020 is the standing example. Plan as if every copy you send exists somewhere forever.

Using a beta round to decide whether to publish. Five readers can't tell you that, and asking them to puts an unfair weight on a favor. They can tell you where the book stopped working. Whether it goes out is your call, and it belongs with the rest of your production plan.

Related elements