In the folder with your novel there is novel_v7_FINAL_edits_MR.docx, next to it novel_v7_FINAL_edits_MR_mine.docx, and somewhere in last week’s email there is a version your editor added three notes to. Nobody is quite sure whether those notes ever made it anywhere. This is not a filing problem. It is the risk that the manuscript you submit is missing half of what the two of you agreed.
This article is about working with an editor in a way that prevents exactly that: what to settle before the first chapter, what tracked changes really do, who should get which level of access, and what changes when you stop swapping files and work in one text instead.
Why swapping files falls apart
The “I send a file, I get a file back with changes” model looks harmless and breaks in the same four places every time.
Nobody knows which version is the real one. All it takes is for you to fix chapter two in your copy during the three days your editor spends on chapter four. Now there are two truths, and somebody has to stitch them together by hand.
Notes disappear during the merge. A comment anchored to a sentence you have since rewritten usually evaporates along with that sentence. No one notices until it turns out that the one thing that needed checking was never checked.
Changes get accepted in bulk. When a document is holding a hundred and thirty tracked edits and the deadline was yesterday, “accept all” is tempting. That is how deliberate authorial decisions vanish from a book because an editor read them as inconsistency.
Rounds take weeks. Every file exchange is a full cycle: send, wait, reread everything from the start, send back. Across three rounds of editing that is a calendar month consumed by logistics rather than by work on the text.
What to agree before the editor opens the file
Most author and editor conflicts come from things left unsaid at the start, not from a difference in taste. Five things worth putting in writing:
- Scope. Structural editing (composition, pacing, character motivation), line editing (the sentence, style, repetition) and proofreading (spelling, punctuation, typos) are three different services. Mixing them into one pass ends with somebody polishing sentences in a chapter that is going to be cut. The order is set out in the guide on how to edit a novel.
- Who has the final word. By default, the author. Say it out loud anyway, together with the second half of the arrangement: if you reject a change, the editor is entitled to know why, because otherwise the same issue returns three chapters later.
- What is deliberate. Breaking the rules on purpose is normal in prose: sentence fragments in action scenes, deliberately crooked syntax in a character’s speech, repetition used as a figure. List those at the start, or you will receive a hundred changes to reject.
- How to flag uncertainty. Your editor needs a way to say “not sure about this, please check” without going into the text. A comment pinned to the passage works. A remark buried in a separate email does not.
- Deadlines per chapter, not per book. “Editing done by the end of the month” tells you nothing about whether you are on schedule halfway through the month.
Tracked changes: a proposal instead of a change
Tracked changes is a mode in which an edit does not overwrite the text but becomes a proposal. Insertions appear as additions, deletions stay visible with a line through them instead of vanishing, and the author walks through them in order, accepting or rejecting each one. Word processors have offered the mechanism for twenty years, and in editing it exists for exactly one reason: to keep the authorship of every decision where it belongs.
That matters more than it sounds. An editor without tracked changes has two bad options. Either they edit directly, in which case the author never learns what moved, or they describe every change in comments, in which case the author retypes everything by hand. Tracked changes removes the choice. The editor works at full speed and the source text stays untouched until the author says yes.
A practical rule for reviewing proposals: go in order and decide one at a time. Every time you reject something, add one sentence of reasoning in a comment. It costs two minutes per chapter and saves an entire round of explanation. Keep “accept all” for the situation it was designed for, where you have genuinely read everything and only want to close the file.
Who should have which access
An editor, a beta reader, a proofreader and an agent are four different relationships, and yet they usually all receive the same file. A sensible split looks like this:
Scope is a separate question from role. A beta reader invited to comment on one chapter does not need the whole book, and often should not have it: an opinion on chapter seven is worth more the less that person knows about what you have planned for chapter twenty.
How this works in Vellam
Vellam goes a step past swapping files: your editor opens the same chapter you are writing in. You can see each other while it happens.
One text, two people, no versions. You can both type at once, including in the same paragraph. There is no “someone else is editing” lock, no save button, and no moment where one person’s change overwrites another’s. The book header shows avatars of whoever is inside, with a hint like “editing: Chapter 3”, and in the text you see your collaborator’s cursor in their own colour, with their name on it. If the connection drops you carry on writing, the indicator tells you “Offline. Changes will sync once you reconnect”, and they do.
Suggestion mode. Your editor turns it on with a single toggle in the tools menu. From that point everything they add renders green, and everything they remove stays in place, struck through in red. You get a review bar above the text: a counter reading “3 of 17”, arrows to the next and previous proposal, who proposed it and whether it is an insertion, a deletion or a replacement, and two buttons, Accept and Reject. The arrows scroll the text to the right place, so you are never hunting for a proposal by eye. Bulk actions are demoted into an overflow menu, because reviewing an edit is a decision per passage, not one click.
Proposals do not contaminate the manuscript. This is a detail that works differently in most tools and has real consequences. Until you accept a proposal, the rest of the system behaves as though it were not there: chapter analysis, export, the word count and your daily writing goal all see your version, not your editor’s. A suggested word does not count towards your goal until you accept it.
Roles instead of trust. You grant access with an invite link carrying a role and an expiry. An Editor works in the text, a Commenter reads and comments, a Viewer only reads. A reviewer can be invited into selected chapters rather than the whole book. You can also decide whether an invited person sees everyone else’s comments, which matters with several beta readers at once: opinions gathered independently are worth more than a chorus.
The manuscript does not leave the building. The collaboration layer runs on our own infrastructure, with no intermediary service that the text of your book passes through. For an unpublished novel that is not a technical footnote. More on roles, comments and sharing is on the collaboration page.
What this collaboration does not do
Worth being straight about the limits, because they shape how you set up the process.
Suggestion mode is for the owner and the Editor role. A Commenter can read and comment but cannot propose a change to the text. If you want your proofreader to be able to suggest anything, they need the Editor role and suggestion mode switched on. Inviting them as a Commenter and hoping for proposals will not work.
Proposals work inside a paragraph. You can propose inserting, deleting or replacing part of a sentence or a paragraph. You cannot propose splitting one paragraph into two, moving a scene, or reordering chapters. Those are done with suggestion mode off, after agreeing on them in a comment.
There is no version history. You cannot roll back to the state of the text from two weeks ago. Undo covers your own changes, not your collaborator’s.
There are no mentions. Comments support replies, resolving and pinning to a selected passage, but there is no “@Marta, take a look at this” notification.
How to set up the whole process
Putting it together, a sensible run through one book looks like this:
- Finish your self-editing. An editor is not there to catch what you would have caught yourself. Check with a cool head whether the book is ready before you commit someone to hourly work.
- Agree scope, deadlines and who has the final word. In writing, before the first chapter.
- Grant access by role, not by fondness. Editor as Editor, beta readers as Commenters, agent as Viewer.
- Settle the working mode. The editor in suggestion mode, you reviewing proposals chapter by chapter rather than in bulk.
- Review as you go. A chapter reviewed in the same week it was edited is a conversation. A chapter reviewed a month later is archaeology.
- Proofread at the end, as a separate pass, on settled content.
Everything after that is work on the text, which is the part the logistics were tidied up for.
Frequently asked questions
What is the difference between an editor and a proofreader?
An editor works on how the text functions: composition, pacing, character motivation, style and sentence construction. A proofreader deals with the wording, meaning spelling, punctuation and typos. They come in that order, because proofreading content that is still going to change is work you throw away.
Does an author have to accept all of an editor’s changes?
No. The final word belongs to the author, and good practice is to consider each proposal separately and leave a short reason whenever you reject one. That lets your editor recognise your deliberate stylistic decisions and stop raising them again in later chapters, which saves both of you a full round.
How do you work with an editor in one document without losing track of versions?
The simplest answer is to stop multiplying files. One text both people can open, edits raised as proposals to accept or reject, and comments pinned to specific passages rather than described in email. Then there is nothing to merge, because no second version is ever created in the first place.
What access should you give a beta reader?
Comments without editing rights, ideally limited to the chapters you are actually asking about. A beta reader is there to give you a reader’s reaction, not to rewrite sentences. If several people are reading at once, consider hiding their comments from each other so that nobody is influenced by what someone else already said.
Is real-time collaboration good enough for editing a whole book?
For chapters and scenes, yes. That is its natural use: a short loop of change and decision with no email round in between. Structural editing of a whole book still needs a separate conversation about composition and pacing, because those questions cannot be settled with proposals inside the text.