GeckoFlag Blog

Tips for choosing project and issue management tools

Series: Task Management Tips for TeamsPart 5

How to Reply to Comments: Say OK, Ask Questions and Send Work Back in a Few Words

Published:

Series “Task Management Tips for Teams”, Part 5: How to reply to comments

About this series

“Task Management Tips for Teams” is an eight-part series, plus a bonus article, for teams that have just started using a task or project management tool. The tips apply to any industry, and you can read the articles in any order.

  1. How Should You Group Your Work?
  2. How to Write Tasks People Understand
  3. How Small Should Tasks Be?
  4. How to Set Assignees and Due Dates
  5. How to Reply to CommentsThis article
  6. How Should You Report Progress?
  7. How to Write When Working with People Outside Your Company
  8. How to Close Out TasksComing soon

Bonus: “How to Write So Teammates Who Speak Other Languages Understand” (coming soon)

The comments on a task go back and forth again and again. Or no reply comes, and you can’t even tell whether anyone read it. A little care in how you write can cut a lot of this.

Note: this article is written by the developer of GeckoFlag.

The short answer: the conclusion in the first line, the request in the last

Readers decide from the first line whether something concerns them. Put the conclusion first and what you need them to do last. In between, include only what they need to decide.

How to write for each situation

When you say OK

“Got it” alone doesn’t say what you agreed to, or what you’ll do and when. Add your next step.

Not so good Better
Got it.Got it. I’ll post the first draft by Thursday morning.

For updates that don’t need a reply, a short “Seen it” is enough. If your tool has reactions (responding with an emoji), use them.

When you ask a question

  • If you have several questions, number them, so the reply can go “1: …” by number
  • Offer choices when you can. “Should we go with A or B?” is easier to answer than “What should we do?”
  • Say when you need the answer by

When you send work back (asking for changes)

  • Pinpoint what to change: “the heading on page 2,” “the phone number at the bottom right”
  • Give the reason: once they know why, they can fix similar spots on their own
  • Separate “must fix” from “nice to have”: if everything carries the same weight, they won’t know where to start
  • Keep the lead-in short: stacking up softening phrases buries the actual request. If you want to mention what was good, one line is enough

When you report that something is done

Say what’s finished, where it is, and whether anything is left. “Done” on its own leaves the other person hunting for the deliverable.

Templates you can use as is

Replace the parts marked with ___.

OK

Got it. I’ll ___ by ___ on ___.

Question

I have two questions about ___.

  1. Is ___ A or B?
  2. Do we need ___ again this time?

If I can have your answers by ___, I can keep things on schedule.

Sending back

I’ve checked it. Please fix these two points.

  1. (Must) Change ___ in ___ to ___. Reason: ___.
  2. (If possible) Make ___ a little bigger.

Everything else is fine as it is.

Done

___ is finished.

  • Location: ___
  • Still to do: nothing (or ___)

Please take a look.

Running late

___ won’t be ready by the ___ due date.

Reason: ___

I can have it ready by ___. I could also send you just ___ first. Which would you prefer?

Three rules for writing comments

1Make it clear who should read it

In a comment thread that several people see, if there’s no addressee, nobody thinks it’s for them. Write the person’s name, or choose who gets notified.

2Say whether you need a reply

Just writing “No reply needed” or “Please reply by ___” cuts the time spent waiting for answers.

3One topic per task

When a different topic comes up, create a new task. If several conversations get mixed into one comment thread, you can’t trace later what was decided.

When you have to say something difficult

Delays, mistakes, saying no: the harder something is to say, the longer the lead-in tends to get. Write the facts briefly in this order: what happened → how it affects things → what you’d like to do. One short apology is enough; use the space instead to spell out the next step.

When to use chat instead

Quick discussions are faster in chat. But whatever gets decided in chat, record it in one line in the task’s comments. Chat messages scroll away and become hard to find later (this is covered in detail in our beginner series article “Why Do Requests in Email and Chat Get Lost?”).

An example of what can happen

A team asked for changes in a single sentence: “Make it a bit brighter overall, the text bigger, and also the photos…” Nobody could tell which changes were required, and it went back and forth three times. After they started numbering requests and separating “must” from “if possible,” more drafts came back right the first time.

How to do this in GeckoFlag

  • Comments use rich text, including numbered lists. You can preview a comment before posting.
  • When you post a comment, you can change the status, priority and assignee at the same time. For example, while writing a done report, you can set the status to “Awaiting review” and hand the issue back to the person who asked.
  • You choose which members get notified each time you post, so you decide every time who should read it.
  • You can react to comments with 20 different icons, which cuts down on replies that only say “Seen it.”
  • The latest 3 comments are shown, and older ones are collapsed. When a long thread reaches a decision, it’s easier to read if you also reflect it in the issue’s description.

You can try the actual screens in the demo.

Summary

In comments, put the conclusion in the first line and your request in the last. Just adding who should read it and whether you need a reply cuts down the back-and-forth. Next time, we’ll look at how to set up the statuses you use to report progress.

SeriesAlso see Part 4, “How to Set Assignees and Due Dates”

SeriesNext: Part 6, “How Should You Report Progress?”