Choosing task software · 10 November 2026
How to choose a task app for work you are waiting on
By Qubit
When a task depends on someone else's input, compare apps by what happens after the first follow-up. A reminder can help you ask again. A received reply may still leave your work blocked.
Before paying, define what usable input would look like and test whether the workflow lets you see what remains missing. You may be able to do this in the task app you already use.
Separate three things you need to track
| Record | Question it answers | What does not settle it |
|---|---|---|
| Your task | What result do I owe? | Someone replying to a related conversation |
| Expected input | What must arrive before I can proceed? | An acknowledgement that the request was seen |
| Next check | When should I revisit the dependency? | Treating that check as the other person's agreed deadline |
For example, you owe an analysis, but need approved figures first. “Chase figures Tuesday” is your planned action. “Figures promised Wednesday” is their agreement, if confirmed. “Analysis due Friday” is your delivery. A useful record should let you distinguish all three.
Alfred's task documentation distinguishes work you need to do from a conversation awaiting a reply. That is a useful starting distinction. For a dependency, also ask whether the response supplied what you need. Product labels alone do not answer that question.
Test four responses to the same request
Use a fictional or permitted sample. Suppose you ask Sam for the approved May figures so you can finish a report. The agreed report cannot be completed with estimates alone.
| Event | Expected state of your work | What to inspect in the app |
|---|---|---|
| No reply | Waiting for the figures | Request/source remains findable; next check is visible |
| “Seen, I'll look later” | Still waiting for usable figures | An acknowledgement does not silently close the dependency |
| A file arrives with estimates; approval is still pending | Input received, requirement not yet met | You can record what arrived and exactly what remains missing |
| Sam supplies the approved figures | Ready for your next action, subject to your review | Waiting state can end without marking your report finished |
These are expected workflow states, not a test performed on any named app. Automatic handling is not essential if a clear manual update fits your needs. If an app only tracks whether a thread received a response, inspect how you will retain the unfinished work elsewhere.
Look beyond the follow-up notification
For each candidate, check whether you can:
- Keep a useful source reference and the person or role supplying the input.
- Record what the input must contain, including any approval condition.
- Maintain your next check separately from an agreed delivery date.
- Change the expected input without losing your own downstream task.
- Correct a mistaken completion or reopen the unresolved work through a supported path.
ClickUp’s incomplete-work warning, for example, can flag unfinished subtasks, assigned comments or checklist items before closure. That is a specific check, not proof that an incoming file satisfies an approval condition. Inspect the actual rule rather than assuming all completion controls mean the same thing.
Only test behavior the product offers. Do not assume an email integration can inspect every chat, attachment or approval. A file opening successfully does not establish that it contains the agreed final information.
Keep, improve or change the system
Copy this for your existing app and any candidate:
My task and its agreed delivery:
Input required before I can proceed:
Who is supplying it:
Source and actual promise, if any:
My next check:
Response tested: none / acknowledgement / partial / usable:
What the app now shows:
Manual correction or review needed:
Is my task waiting, ready, or actually complete?
Decision and unresolved requirement:
Keep your current app if a clearer waiting record and review point do the job. Improve its structure if the failure was unclear wording. Investigate a replacement when the expected input repeatedly disappears or keeping the states current demands upkeep a supported alternative can demonstrably reduce.
If all you need is a simple working record, the client follow-up tracker may be sufficient. It is a separate browser tool, not evidence of automatic tracking inside Qubit.
Where Qubit fits
For freelancers, agency owners and teams, fractional CXOs, consultants, and client-facing roles like account managers. Compare whether a reply supplies the input you need, rather than assuming any response unblocks your work.
Qubit's waiting-on workflow is relevant when commitments and inputs are scattered across supported work context. Review what it captures or updates, and tell it about changes it could not see. An acknowledgement, an approved input and your final deliverable remain different events to check.
Choose the workflow that keeps those distinctions usable for you. Do not choose a larger sales or client-management system when the actual job is maintaining your own next actions and dependencies.