Guides
How to Track Async Client Work Across Email, Slack, and Loom
A lot of freelance work no longer happens inside one obvious work block. It happens across email threads, Slack messages, shared docs, recorded feedback, and short Loom videos sent at uneven times throughout the day. That makes async client work easy to underestimate. The effort is real, but the shape of it is messy.
The problem is not only that communication takes time. The deeper problem is that async work often turns into project handling: reviewing feedback, extracting action items, checking technical context, recording a response, confirming decisions, and preparing the next step. If that work is treated like random message activity, the billing record becomes incomplete.
This guide is not about billing every message. It is about recognizing when scattered async interaction has become meaningful delivery work, and tracking it in a way that stays honest, readable, and defensible later.
Last updated: March 23, 2026
Async work becomes expensive when it forces repeated re-entry
The main cost of async work is rarely one message by itself. It is the repeated re-entry into project context. A freelancer reads a Slack thread, checks an old note, reopens the file, confirms what changed, sends a careful answer, then returns later after another reply arrives. Each touch may look minor, but together they create a real working session.
This is why async work is often undercounted. The visible pieces are small. The hidden cost is that each piece pulls the project back into focus and consumes attention that could have stayed on other work.
Not every message is billable, but some async threads clearly become project handling
A quick acknowledgment, scheduling note, or simple yes-or-no reply usually does not need its own entry. But async work changes category when it materially supports delivery. Reviewing detailed stakeholder comments, watching a Loom walkthrough, comparing it against the current implementation, replying with technical options, and updating the next step is no longer casual communication. It is project handling.
That distinction matters because many freelancers already accept that calls, meetings, and live review sessions can be billable. Async review deserves the same seriousness when it performs the same function through different channels.
Signs async work has become a real billable session
- You had to review multiple messages, files, or comments together to understand the issue.
- You needed to reopen project context before you could respond responsibly.
- You watched or recorded a Loom to explain, review, or unblock the next step.
- You translated scattered feedback into concrete actions, decisions, or implementation direction.
- You checked technical details before replying instead of sending a casual response.
- The async interaction clearly moved the project forward, not just the conversation.
The cleanest way to track async work is to group it by purpose
The mistake is usually trying to track every message separately or not tracking anything at all. A better approach is to group related async work into a single purpose-driven entry. If nine small interactions were all part of one review cycle, they should usually appear as one coherent session rather than nine fragments.
That produces a record the client can actually understand. It also reflects how the work felt from your side: not as isolated replies, but as one block of attention spread across a channel or a short period.
A good async entry explains the handling work, not just the channel
Notes like “Slack messages” or “emails” are too weak. They describe the medium, not the value. A stronger note preserves the handling work inside the async session. For example:
- Reviewed stakeholder Loom feedback, checked reporting flow, and replied with implementation plan.
- Processed Slack thread on billing issue, confirmed expected behavior, and summarized next steps.
- Reviewed email feedback and doc comments, extracted revisions, and recorded follow-up walkthrough.
These entries make the work visible without turning the timesheet into a transcript.
Batching async review usually improves both billing and delivery
One practical way to reduce lost time is to batch async review where possible. Instead of responding to every message instantly, you can review related feedback together, reply in a more complete way, and track it as one session. This usually improves clarity for the client and gives you a cleaner billing record.
It also reduces the hidden cost of constant context switching. The goal is not to become slow. It is to avoid letting fragmented channels control the structure of your workday.
A practical way to handle async client work
- Separate trivial chatter from meaningful project handling.
- Group related async interactions into one session when they serve one purpose.
- Track review, interpretation, checking, and response work together when they belong together.
- Write notes that explain the task handled, not just the channel used.
- Batch async work where possible to reduce re-entry and improve clarity.
- Keep the record proportional and consistent across similar situations.
Async client work is still work when it handles the project, not just the inbox
Freelancers do not need to charge for every sentence they read or write. They do need to stop treating all async activity as if it were weightless. When scattered feedback, review, and follow-up become real project handling, the record should be allowed to show it.
The better the async work is grouped and described, the easier it becomes to bill honestly without sounding defensive.
Related guides