The 'quick favour' tasks quietly eating your week (and how to spot them)

Why small requests feel cheaper than they are

The time a request takes is not just the two minutes of doing it. It is the switch away from what you were doing, the search for the file or link, the reply, and the time it takes to get your focus back. A short interruption can easily cost far more than its visible duration.

Quick favours also hide patterns. The same request from three different people looks like three separate small things, when it is really one recurring task that nobody has designed.

Make the invisible work visible for one week

You cannot fix what you cannot see. For one normal week, keep a simple log of every unplanned request. Keep it lightweight so you actually do it: a note on your phone or a tab in a spreadsheet is enough.

• What was asked (in a few words).
• Who asked, and through which channel (chat, email, in person).
• Roughly how long it took, including finding things.
• Whether you have done the same thing before.

Sort the log into four groups

At the end of the week, read the log and group similar requests. Most fall into one of four types, and each type has a different fix.

• Information requests ('where is…', 'what's the link…'): fix with a shared, well-organised place people can check themselves.
• Repeated routine actions (resending, updating, copying): standardise, then consider automating.
• Genuine judgement calls (approvals, exceptions): keep them, but give them a clear route and a time slot.
• Things that should not be your job at all: hand them back politely, with a pointer to the right owner.

Fix the top two, not all of them

Pick the two groups that took the most time. For information requests, a single shared page with the ten most-asked-for links and files often removes a surprising number of interruptions. For repeated actions, write a short SOP so someone else can do it, or a simple automation so nobody has to.

Then tell people about the change. A new shared page only works if you reply to the next request with 'it's here now', kindly and consistently, for a few weeks.

Protect focus time with a request window

Some requests will always remain. Rather than answering them the moment they arrive, agree a simple norm with your team: non-urgent requests go to one channel or tracker, and you handle them in one or two set windows each day. Define what genuinely counts as urgent so nobody is left blocked.

This is not about being unhelpful. It is about doing the favour well, once, at a sensible time, rather than doing it badly in the middle of something important.

How to say no to a favour without damaging the relationship

Some requests simply should not be yours. Declining them is uncomfortable, especially in small teams where everyone helps everyone. The trick is to redirect rather than refuse. Instead of 'I can't do that', try 'The quickest way to get that is the shared folder, here's the link' or 'Riya owns supplier updates now, she'll have the latest'.

Redirecting teaches people where things live and who owns what. Each time you do it, you remove one future request. Doing the favour 'just this once' teaches the opposite: that you are still the fastest route.

Common mistakes when tackling invisible work

Teams that try to fix quick favours often stumble in the same places:

• Logging for a day instead of a week, which misses weekly and end-of-week patterns.
• Building an automation before writing down the routine, so the automation copies a messy process.
• Creating a shared resources page but never telling anyone, so requests continue as before.
• Treating every favour as a problem. Some quick help is part of good teamwork; the aim is to remove the repetitive kind.

Repeat the log every quarter

As the team grows, new quick favours appear. A one-week log every few months shows you what has crept back in and where the next improvement is. It also gives you honest evidence, rather than a feeling, when you ask for help or propose an automation.

Your first week, step by step

If you want to start today, this sequence keeps it manageable:

1. Monday: create the log and add every unplanned request as it happens.
2. Wednesday: glance at the log and check you are capturing chat requests too.
3. Friday: group the entries and circle the two biggest groups.
4. Next Monday: fix one group, tell the team, and keep logging lightly.