Gather a few things See what you’ll need
- Notebook
- Pen
- Calendar
- Relevant message or meeting note
Separate asking from waiting
Read the original message or meeting note if you have one. Did you make the request? Did the other person acknowledge it? What exactly did they agree to provide? If you have only thought about asking, write the request as your own next action. A waiting entry should not disguise work you have not yet started.
GTD materials include a waiting-for list as a place for outstanding dependencies. A community forum discussion usefully separates that overview from a dated follow-up reminder. You may want both, but they answer different questions: what remains outstanding, and when should I take another look?
Follow the spare-key dependency
Which stage of the exchange is current?
The request is still your action.
Do not call an unmade request a wait.
Record enough to recognize the exchange
Use a simple line with person or source, expected result, request date, and review point. “Noor: spare hall key; asked 4 Sep; check Thu evening” is more useful than “Noor.” Add a short project or reason if that prevents confusion: “for Saturday setup.”
You can use four columns if your page is wide enough, but a hanging paragraph works in a pocket notebook. Test one full entry before ruling a table. Leave room to add a received date or brief follow-up note. The result you are waiting for should be concrete enough that you can tell whether it arrived.
Write a recognizable waiting entry
Edit the worked example into a note you can use.
Who or what:Noor
Expected result:Spare hall key for Saturday setup
Review point:Asked 4 Sep; check Thu evening
Your words have a place now.
Label your chosen check separately from any delivery date somebody promised.
- Words on this card
- 20
“Stop when the request, expected result, and next review point are clear.”
Distinguish a promise from your own check
If the other person gave a date, record it as their expected delivery date. If you choose a day to review, label it “check” so it does not look like a promise they made. For a Saturday setup, Thursday evening may be a sensible example because it leaves time to make another arrangement.
Choose the interval around the real situation rather than automatically checking every dependency daily. Some waits can be reviewed with your normal weekly list; others need a calendar reminder before a deadline. A notebook page cannot alert you while it is closed, so use an actual reminder where timing matters to you.
Keep a check date distinct from a promise
Move the reveal control to inspect the specific change.
An ambiguous date
An unexplained date can create a false assumption about the agreement.
Work through the request and its ending
Imagine you ask Noor on 4 September for a spare key needed for Saturday setup. Noor says you can collect it Thursday. Write that agreement on the waiting line and put the collection time in your calendar if a specific time is arranged. Until collection, the expected item remains outstanding.
After you collect the key, add “received Thu” and close the waiting entry. If you still need to check which door it opens, write “test key at hall” on your action list. Receiving the key and verifying it are different finishing points. Keeping them separate makes the record accurate without extending the wait after it has ended.
Use the record to ask a precise question
At the review point, check whether the item has arrived somewhere you have not looked. If it has not, use the original request and reason to compose a short follow-up. You might ask whether Thursday collection still works because the key is needed for Saturday. Record any new agreement beside the entry.
Avoid repeatedly adding another identical line to a daily list. The waiting entry can retain the history while a single follow-up action sits in your current action pool. Once you send that follow-up, mark your action complete and leave the dependency open until its expected result arrives or the plan changes.
Decide what would make the entry end
If a wait remains open for several reviews, ask whether the expected result is still needed and whether you have an alternative. Perhaps the venue now has a staffed entrance, making the spare key unnecessary. Close the line with “cancelled: staff entry arranged” rather than copying it into the next notebook without explanation.
If the result is still necessary, choose your next action: clarify the request, arrange another source, or revise the plan. Do not write a vague “chase” forever. A waiting list is most useful when each entry names an outstanding condition and each review can produce a real decision about it.
Finish with one live dependency
During review, remove completed or cancelled waits from the active view while leaving their record readable. Keep only the outstanding entries you still need to monitor. When the page fills, transfer those live dependencies with their essential dates and mark the original lines as moved.
Stop when the request, expected result, and next review point are clear. You do not need a second list sorted by every person unless that helps your actual conversations. A waiting-for entry ends when the expected result arrives, the need disappears, or you deliberately replace the arrangement.
Close a wait accurately
Move the steps so the necessary checks happen before the actions that depend on them.
One workable order
- Check that the expected result arrivedA follow-up sent is not the same as the result received.
- Record the outcome or new arrangementThe ending should remain understandable later.
- Close the old waiting lineOnly a resolved or deliberately replaced wait should end.
Which check needs to come first?
The example shows one workable order. Other steps can move freely; these checks protect the information you need.
Where this idea began
Want to follow the idea further? These community discussions and maker references are a good place to start.
- Understanding the Waiting For List
Participants distinguish reviewing an outstanding dependency from scheduling a dated follow-up.
- Waiting For Advice
The GTD discussion distinguishes a waiting-for list and the practical need to review it.
