Time-Boxing Customer Support So It Doesn't Eat Your Week

One quick question, one lost morning

The fix is to answer support in fixed windows, not whenever a message lands. Pick two or three slots a day, tell customers when to expect a reply, and let everything else wait. If you are a solo founder or indie hacker, support is part of the job, but it should not decide when your building time starts and stops.

A caveat before the how-to: we found no study that tests time-boxing support directly. What follows borrows from research on interruptions and email batching, and the evidence there is mixed.

Why support eats your maker time

Interruptions disrupt performance and induce errors, and the cost doesn't end when you send the reply. The same overview cites Gloria Mark's figures, relayed through a 2008 newspaper article, that knowledge workers switch tasks about every three minutes and can take nearly half an hour to resume the original task. Treat those as journalistic numbers, not lab results. They still point the same way as what we covered in attention residue: part of your attention stays on the last thing you touched.

Cal Newport's argument about email applies to a support inbox too. Email isn't the problem; the workflow is, because every request arrives in one undifferentiated stream that forces you to keep checking it. For a solo founder, a billing question, a feature request and a bug report all land in the same place, at random times.

Set support windows, not an open inbox

Pick two or three fixed windows

A Dutch field study asked staff at a financial services firm to check email at most three times a day for a month. A reasonable starting point for support is the same: a window mid-morning, one after lunch, and perhaps one at the end of the day. Outside them, close the inbox and turn off notifications.

Be honest about what batching does

The results were modest, though. Emotional exhaustion fell in the batching group, but the drop in interruptions was only marginal, work engagement didn't change, and the effect on exhaustion wore off quickly once the month ended. The authors say batching should not be regarded as a panacea. The benefit was larger for people receiving 25 or more emails a day and smaller where quick replies were expected.

A separate 2016 CHI study, mentioned in a reader comment on Newport's post, found batching linked to higher perceived productivity but not lower stress. Expect fewer interruptions and a clearer head for building. Don't expect a calm inbox.

Match the box to the reply time you promise

The second lesson is the practical one: batching works best when it fits what the job expects. If customers expect an answer in an hour, a once-a-day window will feel like neglect, and you will end up checking anyway.

So decide your reply time first, then build windows around it:

• State it where people ask: the contact page, the app's help screen, and an auto-reply such as "We reply within one business day."
• Start each window at 30 to 45 minutes, then size it from your own log rather than a guess.
• Keep a single place for requests. Forward everything to one inbox instead of watching three.

Shrink the pile before you time-box it

A box is easier to keep when less goes into it. One case in the interruption literature involved programmers pulled in up to 150 times a day through a technical support chat. Adding a dispatcher role and a knowledge base reduced those interruptions. You probably can't hire a dispatcher, but you can play one yourself:

• Write a help page for the five questions you answer most.
• Save replies for those five, so a window is mostly paste, personalize, send.
• Tag each request as bug, billing, how-to or idea. After two weeks, the biggest tag tells you what to fix in the product or the docs.

Decide what breaks the box

Some things can't wait for the next window. Write the list once, while you are calm: an outage, a failed payment on the customer's side, anything involving lost data. Everything else waits. Deciding in advance is the point, since "is this urgent?" is much harder to answer mid-interruption.

Doing this with Pomlo

Pomlo fits because a time box only works if you can see it. Create a "Support" project and start a focus session at the beginning of each window with one tap. When the timer ends, the window ends. At the end of the week, the reports show how many hours support took, so you can shorten the windows or fix the questions that fill them. Pair it with a deep work block of the right length and a capped working week, and support becomes a line in your schedule instead of a leak in it.

Pomlo works on iOS, Android and the web, and they stay in sync. Download it on the App Store or Google Play.

The short version

Answer support in two or three fixed windows. Promise a reply time you can keep, cut repeat questions with a help page and saved replies, and pre-agree the few things that break the box. Then check your tracked hours each week and adjust.

Frequently Asked Questions

How many times a day should a solo founder check support?

There is no proven number. The Dutch study had staff check email at most three times a day for a month, so two or three windows is a sensible start. Adjust it to the reply time you promise customers.

Does batching support emails actually work?

The evidence is mixed. The Dutch study found lower emotional exhaustion, only a marginal drop in interruptions, and an effect that faded after the month. A 2016 CHI study linked batching to higher perceived productivity but not lower stress.

What should break the time box?

Only things where waiting does real damage, such as an outage, a payment failure or lost data. Write the list in advance so you aren't deciding it mid-interruption.

How do I reduce the number of support requests?

Answer repeat questions once in a help page and saved replies. In the interruption research, a knowledge base plus a dispatcher role cut support-chat interruptions for programmers, and a solo version of that is a help page and tagged requests.