A client emails on Monday asking for a change to the homepage banner. On Wednesday they mention a new footer link during a call. On Friday a colleague gets a chat message asking whether the contact form can send a copy to a second address. Two weeks later the client asks, politely but pointedly, why only one of those three things has been done.

Most agency owners and project leads know this moment. Nobody ignored the requests. Each one was heard, and some were even written down. They simply ended up in different places, held by different people, and only some of them turned into work. This article looks at why that happens in small teams and sets out a simple fix: one task list per project where every client request lands before anything else happens to it.

Where client requests actually go missing

Requests rarely vanish in a dramatic way. They leak out through small gaps that feel harmless on their own.

  • The personal inbox. A request sent to one person stays in that person's email. If they are busy, on leave or have moved to another project, the request waits with them.
  • The meeting that nobody wrote up. Three people heard the client ask for something on a call. Each assumed one of the others would capture it.
  • The quick chat message. Requests made in passing feel small, so they get a reply like 'sure, will do' and no record.
  • The half-captured task. Someone creates a task called 'banner changes' with no detail, no owner and no date. It exists, but nobody can act on it.
  • The request inside a longer thread. One genuine ask sits in paragraph four of an email about something else, and is never pulled out.

Each of these is a capture problem, an ownership problem or both. The request either never becomes a visible item, or it becomes one that belongs to nobody.

Why it keeps happening even in good teams

Small teams usually lose requests because they are good at being responsive, not because they are careless. When there are five or six people, everyone talks to the client, everyone can help, and things move quickly. That informality is a strength until the volume grows.

A few patterns make it worse:

  • No agreed front door. If the client can reach anyone through any channel, the team needs a rule for where requests go once received. Without one, each person invents their own.
  • Capturing feels like admin. Writing a request down properly takes two minutes. Doing the work sometimes takes five, so people skip straight to the work, or plan to note it later.
  • Requests and tasks get mixed up. A request is not yet agreed work. It might be out of scope, need a quote or clash with something else. When requests go straight into the main work lists, they either get done without being checked, or they get parked and forgotten among dozens of other tasks.
  • Nobody reviews the backlog. Even when requests are captured, there is no regular point where someone looks at all of them and decides what happens next.

The common thread is that requests have no single, visible home with a clear process attached.

The fix: one request list per project

The approach is simple. Inside each client project, create one task list dedicated to incoming requests. Call it something obvious such as 'Client requests' or 'Inbox'. Then agree one rule with the team: every client request, however it arrives, becomes a task on that list before anyone acts on it.

That one rule changes a lot. Requests stop living in personal inboxes. Anyone on the team can see what the client has asked for. And there is a natural place for the lead to decide what each request becomes.

What a useful request task contains

A request task does not need to be elaborate, but it should be complete enough that someone else could pick it up. A practical minimum:

  • A clear title in plain words, such as 'Add second email recipient to contact form'.
  • Who asked, when, and through which channel.
  • The original wording or a copy of the email, attached or pasted in.
  • An owner responsible for the next step, even if that step is just 'clarify with client'.
  • A due date if the client gave one.

Keep requests separate from scheduled work

The request list is a holding area, not the place where work gets done. Once a request is reviewed, it is either moved into the relevant working list, turned into a quote or scope discussion, or closed with a note explaining why. This separation stops the main task lists from filling with unreviewed asks, and it keeps a clean record of what the client asked for versus what was agreed.

Running the list week to week

A request list only helps if someone looks at it. For most small teams, a short, regular triage is enough.

  1. Pick an owner per project. Usually the project lead. They do not have to do the work, but they make sure every request gets a decision.
  2. Set a rhythm. A daily ten-minute check for busy projects, twice a week for quieter ones. Put it in the calendar.
  3. Give every request one of a few outcomes. Accept and schedule, clarify with the client, quote as additional work, or decline with a reason.
  4. Reply to the client. Confirm that the request was received and what will happen next. This alone removes many of the 'did you see my email?' follow-ups.
  5. Close the loop. When the work is done, tell the client and mark the request as complete, so the list reflects reality.

Over a few weeks, the list also becomes a useful record. You can see how often a client asks for out-of-scope work, which helps with conversations about budgets and future estimates.

How Tilvin supports this approach

You can run this method with any tool, but it helps when requests sit in the same place as the rest of the project. In Tilvin, each client project already groups task lists, messages, files, notebooks and time logs, so adding a 'Client requests' task list puts intake right next to the work it turns into.

A few capabilities fit the method well:

  • Task types and priority. Tasks carry a type, including task, bug, discussion and future item, plus priority, assignees and dates. A request that is not for now can be marked as a future item rather than lost.
  • AI task generation. Paste in a client email or meeting notes and the AI proposes tasks and sub-tasks for you to review before they are created. This is useful for long emails where one real request is buried among other content.
  • Discussions on tasks. Clarifications happen in threaded comments on the request task itself, with attachments and @notify for team-mates, so the context stays with the request. If a thread gets long, an AI summary can pull out a summary, item list and open questions.
  • Workflows and the Kanban board. An administrator can define a process with steps such as New, Clarifying, Accepted and Done, and the project's Kanban board shows requests as cards moving through those steps.
  • Project-level roles. Projects support manager, user and client roles, which is worth considering if you decide to involve the client more directly in the project.

Practical next steps

You do not need to reorganise every project at once. Start small and let the habit prove itself.

  1. Choose your busiest client project and add a task list called 'Client requests'.
  2. Agree the rule with your team: every request becomes a task there before anyone acts on it.
  3. Go through the last two weeks of email and chat for that client and add any open requests you find.
  4. Name an owner for the list and book a short, recurring triage slot.
  5. After a month, look at what changed: fewer follow-up chases, clearer scope conversations, fewer surprises. Then roll it out to other projects.

Client requests will always arrive through many channels. The goal is not to control how clients reach you, but to make sure that once a request arrives, it has one home, one owner and a clear next step.