Post

Design a multi-client week without context thrash

Design the week for two or three clients with day themes, a hard cap on switches, and notes that keep deep work from turning into context thrash.

On this page

Eleven tally marks by lunch

One Monday I stuck a note on the edge of my monitor and drew a mark every time I moved from one client to another. I had three on the go: a site build, a maintenance retainer, and some Android work for a different client with a release coming up.

By one o'clock there were eleven marks. I had answered a retainer email about a broken image, fixed a typo on the build client's staging site, replied in the app client's chat about a crash report, gone back to the build, been pulled out by a second retainer email, and so on. Every switch felt like two minutes. When I looked at what I had actually finished that morning, there was nothing a client would recognise as a deliverable.

Every switch felt like two minutes.

I had been at the desk since nine. I had been responsive to everyone. And I had produced a morning of half-loaded contexts, each one dropped just as I got back into it.

That note changed how I plan. I cannot pretend I have one client when I have three, because that is how I earn. What I can do is design the week so the switches happen on purpose, deep work has a home, and each client still hears from me on a schedule they can predict.

Diagram · 16:9eleven client switches before lunch beside a themed week with two deep contexts and short pulse windows, diagram, ratio 16:9, diagram

Two caps I plan around

These are my own planning defaults, not research. I adjusted them after a couple of weeks of tallying, and you should measure your own before trusting mine.

  • No more than two deep contexts in a day. One is better. Two is workable if the second is in the afternoon and smaller.
  • No more than three billable clients in a week, unless one of them is maintenance only and mostly runs itself.

Why switching costs so much is covered in the real cost of context switching. The short version for freelancers is that switching tax is a big part of why billable hours shrink even on days when you never leave the desk, which billable hours lower than working hours unpacks in detail. If you want the general weekly planning method first, plan a week of remote work has it. What follows is the version I use when two or three clients are paying for the same week.

Thirty minutes on Sunday evening

The planning is short, and I do it before the week starts so Monday does not decide for me.

Mark each client's mode for the week. Deep build, review and feedback, light admin, or waiting. A client who is waiting on their own copy does not get a deep day reserved "just in case". That is how you end up hovering.

Give each day a theme. One client owns the morning. The others get a short window, or nothing.

Name one finishable outcome per deep day. Not "work on the build" but "booking form validation states done and on staging". If I cannot name one, the day is not ready to be a deep day.

Put short pulse windows in the gaps. Fifteen to twenty-five minutes for the non-theme clients: messages, quick questions, invoice queries. Outside those windows, I am not ambiently available.

Plan the switch notes. At every theme boundary I write two lines: where I stopped, and the first thing to do when I return. Without them, Tuesday's retainer batch begins with ten minutes of archaeology from last week. Restarting where you left off is the same habit applied across days instead of across clients.

What the week looked like once I fixed it

Here is the week after the tally-mark Monday, with the same three clients. The site build (A) was my main fee that month. The retainer (B) was mostly small tickets. The app work (C) had a release due the Friday after.

DayDeep themePulseOutcome for the day
MonA 09:30 to 12:30B 13:30 to 14:00A: booking form validation states
TueB 09:30 to 11:30, ticket batchA async onlyB: ticket queue at zero urgent
WedC 09:00 to 12:00B 15:00 to 15:20C: crash fix and release build
ThuA 09:30 to 12:30C 14:00 to 14:30, test feedbackA: payment error handling
FriFlexibleAll clients 10:00 to 11:00Invoices, change orders, leftovers

The biggest change was Tuesday. Before, retainer tickets were sprinkled across every morning, which meant I paid the switching cost five times a week and got no benefit from doing similar work together. Gathering them into one block uses the same logins, the same site and the same mental checklist, which is exactly when batching helps. Spreading them across the week had given me the full switching cost with none of the payoff.

The afternoons look empty in the table. They were not. They held the smaller follow-ups for the morning's client, a pulse window, and the things that keep a freelance business running. They just did not hold a second big context.

Rules that stop the design falling apart by Wednesday

Emergencies need a definition. Production is down, a payment is blocked, a legal deadline is today. "The client feels anxious" is a message for the next pulse, not a reason to rewrite the day.

No new deep context after two in the afternoon. If something urgent arrives, it replaces a pulse or eats Friday's flexible time. It does not become a third deep context on top of a deep day.

Waiting is not a theme. If a client owes me copy, I send one clear request with a date and go back to someone else's work. Hovering over an inbox for a client who has not replied is unpaid thrash dressed up as being on call.

Close one client before opening the next. At the end of an A morning, I write the switch note and shut A's editor windows before I open B's pulse. Mixing two clients' leftovers is how both turn into fog.

The tab problem

A lot of my thrash turned out to be physical. Three chat apps, two design files and a browser full of tabs from different clients meant that every glance at the screen offered me someone else's problem.

So on a deep morning I mute the other clients' chats to mentions only and open just that client's repo, tracker and docs. Separate browser profiles per client help when logins need to stay live. The test I use is simple: a glance at the screen should tell me which client I am working for without reading a tab title.

Closing everything at a boundary takes half a minute. Half-seeing two projects for an afternoon costs far more than that.

What the switches were costing in money

Rough numbers from my own tally, with fifteen minutes as my planning figure for the reload cost of a switch (measure yours, it may be lower or higher):

  • Messy week: about 6 switches a day, 5 days, so 30 switches. 30 × 15 minutes = 7.5 hours.
  • Designed week: about 2 switches a day, so 10 switches. 10 × 15 minutes = 2.5 hours.

That is five hours a week recovered. At my €70 hourly rate, that is €350 a week of time I had been spending on fog. Even my eleven-mark Monday morning alone, at fifteen minutes a switch, was nearly three hours of reloading.

None of that is magic productivity. I stopped giving away most of a day each week to switching, and the time went back into deep work or an earlier Friday finish.

Telling clients without sounding unavailable

Clients do not need constant presence. They need to know when they will hear from you. I put it in the kickoff message:

"I work in focused day themes across clients. You'll hear from me every day in a short window, and your main progress happens on Mondays and Thursdays. If something is genuinely urgent, like the site being down, tell me and I'll reshuffle."

When someone pings outside their window:

"Got it. I'm in a focused block on another project this morning, and I'll pick this up in this afternoon's window. If it's blocking you right now, say so and I'll look sooner."

In three years of using lines like these, I have had one client push back, and that client wanted same-minute replies at all hours. If a client really needs that, it is a different service and it needs a different price. Ambient availability across three clients is how good freelancers turn into tired, average ones.

When a fourth client asks

The real test of the week design is the fourth enquiry. Before saying yes, I look at the current week. If every day already holds two contexts, the new client is not "a few hours on Friday". It is a redesign: drop or reprice a retainer, raise rates and let a poor-fit client go, or say no.

I have found that extra income that wrecks the deep days often means less profit once the thrash and the rework are counted, especially if the new client only fits at a low rate. Cheap freelance rates shrink real income has the arithmetic on that. Count the billable deep hours you would have left, not the hourly rate on the enquiry.

When the plan breaks anyway

It will. A release slips onto a Monday, a client's launch moves. When that happens I do a quick midday redesign instead of letting the rest of the day become chaos: cross out the broken theme, pick one surviving outcome for the afternoon, move the displaced deep block to Friday or next week explicitly, and tell the affected client in one sentence.

The note on my monitor is long gone, but I still tally switches for a day every couple of months, just to check I have not drifted back. Three clients can make a perfectly profitable week, as long as each of them gets a clear part of it. Let all three into every hour and you will be busy all week with very little finished by Friday.

End of this piece

Writer

PrimedEcho

Independent notes on remote work, focus, and freelance practice. About this site.

All posts