The request arrived in Teams. The task never arrived anywhere.

The customer follow-up is in the CRM and gets done. The internal request arrives in chat and disappears beneath the afternoon’s messages.

That contrast appeared in a September 2024 Reddit discussion. A manager was looking for ways to help a colleague who handled CRM follow-ups but missed requests sent through Teams or email. The manager described their own routines while acknowledging that other people organize work differently.

The discussion points to a place worth checking: where a message is supposed to become a commitment. A request can arrive through several channels. An accepted task needs a dependable place to live, a person responsible for it and a way to know whether it is done.

Find the moment work becomes yours

A message can be a question, a suggestion, a request or a piece of background information. Treating every message as a task creates noise. Treating none of them as tasks leaves promises in conversation history.

When a request needs action, acknowledge what you are accepting. In an illustrative exchange, a colleague asks for a revised scope before a customer call. “Seen” leaves the commitment vague. “I will update the integration assumptions before your Thursday call; I need the revised requirements from you first” defines both the work and its dependency.

If you cannot accept it, say that too. An unassigned request should not become an invisible promise.

Choose one place to review accepted work

The review place can be the CRM, a task tool or an existing team queue. Choose something the person can reliably access and the team already understands. Start with the queue you already check before the day’s customer calls. If accepting a chat request means opening a place you rarely visit, the capture step is likely to be skipped again.

Keep four pieces of information together:

• The action and the result that counts as complete.
• The accountable person.
• The due date or the event it depends on.
• A link to the original context, with appropriate access.

Copy enough detail to make the task understandable, but avoid scattering complete private conversations across several tools. If the original message changes, the task owner should be able to find the correction.

Give waiting work a visible state

Some tasks remain unfinished because someone else must act first. Keeping them on an ordinary to-do list makes them look like forgotten work. Removing them from view makes them easier to forget.

Use a distinct waiting state and name the dependency. “Waiting for the buyer’s sample file” is more useful than “blocked.” Add a review point if the event has no agreed date.

The owner still has a responsibility: check whether the dependency arrived, update the requestor when the deadline is at risk and close or renegotiate the task when circumstances change.

That is different from repeatedly reminding everyone in the original chat thread.

Close the conversation as well as the task

Suppose the revised scope is finished. Mark the task complete and put the result where the requester expects it. A short reply linking the approved document is enough.

“Done” can be ambiguous when there are several versions. Identify the result and any remaining limitation. If the technical assumptions still need specialist review, do not describe the scope as fully approved.

This small closure step helps distinguish completed work from work that has merely disappeared from the queue.

Coach by finding the break

Review a few missed requests with the person involved. Where did each fail?

Break	A change worth testing
The request was never noticed	Agree which channel carries urgent commitments.
It was noticed but not captured	Add a capture step when accepting the request.
The task was too vague	Define the required result and dependency.
The date was unrealistic	Negotiate before accepting.
The work was complete but nobody knew	Add a closure reply with the result.

These are process hypotheses to investigate together. A missed task is not enough evidence to diagnose a person’s motivation or working style.

Choose one change and review whether requests are being captured and closed more consistently. Count actual requests and missed commitments over the same period. Do not mistake a larger task list for an improvement.

RevQ describes follow-up drafts and next steps with owners. That can help prepare the record, but the team still needs to accept the action and keep its status accurate. The sales-to-delivery handoff guide applies the same principle when a customer is waiting for the next promise.

Try this on the next scope request: acknowledge the result you owe, put it in the review queue and link back to the message. When the scope is ready, reply with the document. Check which of those steps, if any, still gets missed.

About this article: AI-assisted writing and editing, informed by the linked public discussion. Illustrative examples are labelled; they are not customer case studies. Read our editorial approach.

Updated October 3, 2026