Beyond "please share the doc": tips for successful collaboration with clients in Google Docs
- Paige Schwartz
- Apr 2
- 7 min read
When you work with clients in Google Docs, you’re playing a game with a lot of unwritten rules. What sharing settings should you use? When can you consider a comment closed? When do you edit directly vs. use suggesting mode?
We’ve worked with several writers who, coming from engineering backgrounds, understand how to run a code review but could use an etiquette guide for Google Docs. (Or Notion, which is quickly reaching parity with features for writing and editing.) Note that certain norms are practically universal, but in most aspects, you’ll find plenty of cultural variation—different clients have different ways of doing things. So, with a grain of salt, here are the rules we teach our writing team and some advice on when to break them.
Name your document clearly
First impressions matter, and your document’s first impression is its name! So if you are the owner and originator of the doc for your piece, don’t call it “Blog post draft.” Be clear and consistent, and come up with naming conventions that work for you and your client(s).
At Copytree, we use a concise name that clearly describes the project—typically, it’s the name the client gives us in their brief or uses to refer to the piece. This is different from the actual title of the work, which might change over time. We also include the type of piece in the name (blog post, white paper, case study, etc.).
Finally, we indicate whether the piece is currently internal to Copytree (we’re drafting or editing it and it’s not ready for the client to look at), or shared with the client. That way, writers don’t make internal-only comments on something the client might be viewing.
Putting it all together, our doc names look like:
“[INTERNAL/SHARED] <Project name> | <Type of piece>”For example:
“[INTERNAL] Personalized Language Model | Engineering Blog Post” Or:
“[SHARED] Nationwide x Anomalo | Customer Story” Provide a spec sheet at the top of the piece
Now that you have a name, what do you want the next first impression of your piece to be? Rather than launching into your draft, it’s helpful to provide a bit of context up front.
We always include a table at the top of our docs with some fields our clients care about. It’s nothing too complicated or long, and can be easily ignored when loading the work into a CMS, but it provides a level of consistency and lets you know at a glance that this work came from Copytree. It also makes it easy for reviewers to cross-reference the brief or understand the timeline for the piece.
Here’s a screenshot of that table before it’s filled out:
Sometimes you’ll find your client already has a similar template they use, in which case you can defer to their system.
Use a shared folder to control access
You’ve finished your draft and it’s ready to share—congrats! Watch out though, because there are some do’s and don’t when it comes to the exact protocols of sharing your Google Doc with your client.
Clients usually want to restrict who can access their docs. However, adding people individually to each doc is tedious, and workflows slow down while reviewers and stakeholders are waiting for access.
Therefore, it’s best to set up a shared Google Drive folder and put everything in there. Anyone who has access to the folder can see everything within. If the client creates this folder, they can elect to open access to everyone in the company or specific internal groups.
Relatedly, if you get an access request from someone you don’t recognize, ask the client over Slack if it’s ok to share with that person, rather than just sharing the doc. It could be their graphics agency working on an image to accompany your piece, but it could also be someone the client really doesn’t want seeing what you wrote. It’s a good security practice, and also shows the client that you are serious about protecting their non-public information.
Follow layout standards but don’t get fancy
What does layout have to do with collaboration, you ask? Well, if you follow certain norms here, your doc will be clearer and easier to read for your client. And they’ll have an easier time loading it into their CMS and publishing it.
The first rule of layout is to use H1s for titles, H2s for headers, and H3s for subheaders. This is standard for CMS systems. (So, ignore Google Docs’s “title” option, and avoid simply bolding the font for headers).
The second rule is to avoid custom fonts and just use the Google Docs defaults. The client is going to be loading your doc into a blog where everything will have their branded look and feel. When we’ve asked, our clients feel it’s not a worthwhile use of writing hours to zhuzh up the GDoc.
Still, there may be pieces of the post that benefit from special formatting to convey information. Tables or basic charts can illustrate your points, a larger, bolded font can indicate a pull quote, and Google Docs code blocks can make code easier to read. It’s a good idea to check with your client to see if they want this sort of formatting in the documents you provide.
Finally, when you share a draft, the text itself should look clean and professional, even if the expectation is that you’re sharing something rough. So delete or reformat as a comment any cruft like notes to self, alternate header options, or questions for the client.
Get cozy with suggesting mode—but recognize its limits
If you get some feedback from a client on your piece, it’s a best practice to make revisions in Google Docs Suggesting mode and let the client accept or reject them.
Suggesting mode is a bit of an art. Be thoughtful about the placement of suggested edits to make clear what’s new without creating a confusing soup of half-crossed-out sentences. Helpfully, you can comment on a suggested edit to anticipate any confusion or pushback about that edit (“I’m not deleting this paragraph, just moving it to the next section where it fits better!”).
Don’t feel obliged to use suggestions for every single edit. You should directly edit anything you think your client wouldn’t want to weigh in on, starting with only the most obvious fixes and expanding as you get to know the client’s preferences. Did your client give feedback that a feature name should be capitalized? Make that change directly, without asking them to accept a suggested edit every time the name appears. Or perhaps you see an opportunity, on rereading, to cut or refine some words here and there without a change in meaning. This minor polish is typically not worth your client’s time to review.
On the other end of the scale, sometimes you revise so heavily that your suggested edits make the piece hard for even you, the author, to read. When that happens, it’s time to think of another approach. Create a fresh “v2” and draw attention to what’s changed with a comment at the top, highlighted sections, or just a conversation over Slack. If you start from scratch, you can always offer to use Google Docs’s “Compare documents” feature to perform a before-and-after diff in case your clients want a record of what’s changed.
There’s also the question of what to do when your client edits your work. First, ask them to use Suggesting mode—it’s the best way to learn from their feedback. Then, we recommend accepting most suggestions outright, because the client knows a lot more about their goals, audience, and voice than you do. If you need to push back (see our advice on how and when to push back), such as when an edit changes your intended meaning, or if something seems just plain wrong, reply to the suggestion and leave it open, and only reject it once you’ve reached agreement with your client.
If you agree with the spirit of the suggestion, but want to make some edits for phrasing, accept the suggestion and then make those edits directly. You may want to say something like, “Great idea, I am just going to tweak the wording.” Google Docs will send an email saying you “Rejected” the suggestion if you simply delete or reword it inline.
Approach comments like conversations
Treat each comment thread as a mini conversation. Always respond thoughtfully rather than leaving comments dangling or closing them out sans reply.
However, as long as you’re communicating with care, you can and should take some liberties to keep comments under control—otherwise they’ll grow like weeds and slow down your piece’s progress to publication. Feel free to close comments that you’re confident have been fully resolved, with a note explaining why. If a comment thread gets unwieldy and you need to re-focus attention, it’s OK to comment that you’ll start a new one, close the old one, and then start afresh.
When you want to comment about a suggestion that someone made, avoid starting a new comment. Instead, reply directly to that suggestion. It’s cleaner and maintains context.
If someone’s comment will get deleted (auto-resolved) by your revisions, it’s a good idea to note that before you make said revisions. You can write a reply stating, “This is getting cleared up by some changes I’m making.” Otherwise, the person who commented will get an email saying that their comment is resolved, without seeing the resolution.
If you need to get a specific person to look at a comment, use the @ mention feature. The exception would be if you expect them to review the entire document—there’s no need to mention them in every comment.
Pro tip: If you aren’t the owner of the doc, but still want to get notified every time there’s a comment, you can change your notification settings by clicking on the comment icon in GDocs, then the bell icon.
Using collaborative writing tools like Google Docs and Notion isn’t really about figuring out their functionality, which is pretty straightforward. It’s about the much messier problem of etiquette and norms when working with other humans. We hope these tips help you navigate future writing assignments with more confidence. We've got more on becoming a writer clients love to edit.
