On this pageJump to a section
December 26 is the quietest day of the year for a lot of operators, and most of them waste it.
They scroll, they half-answer email, they feel vaguely guilty about not working, and on January 2 the same broken things are waiting: the lead who never got a reply, the new client who had to ask three times where to send files, the report nobody trusts. The slow weeks are not a hole in the calendar. They are the only time many of us get long, uninterrupted stretches, and that is exactly what systems work needs.
Why are the quiet weeks the best time for systems work?
Because the work is a maker's work, and makers need long blocks.
Paul Graham drew the line between two kinds of schedules years ago. A manager's day is cut into hours, and a meeting fits anywhere. A maker, he argues, wants blocks of at least half a day, because "a single meeting can blow a whole afternoon" by splitting it into pieces too small for hard work.1
Building a system is hard work
Writing a follow-up sequence, mapping an onboarding path or untangling a report means holding the whole thing in your head at once. Break that concentration three times in an afternoon and you will end the day with a list of fragments. The year-end lull removes the pings that break it, which is the real gift of the holiday slowdown.
Rest is part of the plan
Do not read this as a case for working through Christmas. Harvard Business Review's classic article on energy opens with the point that many people answer rising demands by working longer hours, and that this leads to burnout that costs both the person and the organization.2 Plan two or three focused half-days. Spend the rest of the break being a person. And if the quiet gives you thirty spare minutes, spend them on your long-term plan, the one system no software will build for you.
Which two-week projects are worth doing?
I would choose from three. Each one fixes a place where small businesses lose money without noticing.
Project one: lead follow-up
The problem: leads wait, and every hour a lead waits is an hour they spend looking at someone else. (The full argument is in Build the Follow-Up Before You Buy the Traffic.)
The build:
- Write down the exact path from "form submitted" to "first human conversation."
- Draft three messages: an instant acknowledgment, a useful second touch and a closing-the-loop note for people who go quiet.
- Decide who owns replies, and what happens when that person is away.
- Form submittedThe lead lands in the right place
- Instant acknowledgmentAutomatic, within minutes
- Useful second touchSomething worth reading
- Human conversationOwner assigned, backup named
- Closing-the-loop noteFor people who go quiet
Definition of done: a test lead submits your real form. They receive every message on schedule, the lead lands in the right place, and you did not touch anything.
Project two: client onboarding
The problem: every new client asks the same five questions, and you answer them from memory, differently each time. (Onboarding Is Where Refunds Are Born shows why it matters.)
The build:
- List every step between "paid" and "first deliverable."
- Write a welcome message that answers the five common questions up front.
- Build one intake form so you stop collecting information through twelve separate emails.
Definition of done: a friend plays a new client and gets from payment to first deliverable without asking you a question twice.
Project three: reporting
The problem: you check six places, get six different numbers and trust none of them.
The build:
- Choose five numbers that matter and name the single source for each.
- Build a one-page weekly view that pulls only from those sources.
- Write down how each number is calculated so the definition survives your memory.
Definition of done: you can produce this week's scorecard in fifteen minutes, and a skeptical partner can trace every number back to where it came from.
What should the two weeks look like?
Keep the calendar boring.
- Choose one project. Write its definition of done on a single line before you do anything else.
- Block two half-days in the quiet stretch. Put your phone in another room.
- Build the ugly version first. A working rough draft beats a polished plan.
- Run the test from your definition of done. Fix what fails.
- Document it in one page: what it does, who owns it, how to check it.
- Schedule a ten-minute review for the first week of January to see if it held up.
One project at a time
Resist starting all three. Each one touches different tools, and a half-finished system is worse than none, because it creates the feeling that the problem is handled. If you only have a few free days, do follow-up first. It sits closest to revenue.
How do you know a system is actually finished?
By the test, never by the feeling.
Sharran Srivatsaa said the same thing about process in a video posted on September 3, 2024, about the three habits behind his real estate brokerage's growth:
Good process and good process alone drives good results.
"Alone" is a strong word, and I would not apply it to every business. But a holiday week is the right time to prove it on one process of your own.
Write the definition of done first
The definition of done forces you to decide what "good" is before you get attached to what you built. It also gives you a clean place to stop. Without it, a two-week project turns into a two-month hobby.
What usually goes wrong in a systems window?
Three things, and I would plan for all of them.
You rebuild the tool instead of the process
The temptation over the holidays is to switch software. A new tool feels like progress, but if the process behind it is unclear, you have only moved the confusion. Fix the path on paper first. Change tools only if the paper version proves the old one cannot do the job.
You add steps nobody asked for
A follow-up sequence with eleven touches sounds thorough. Three that actually get sent beat eleven that nobody maintains. Keep each system as small as it can be while still passing its test.
You skip the test
Building feels productive. Testing feels like admitting the build might be wrong. Test anyway, with a real form, a real payment link or a real report, because the failure you find now costs you an afternoon and the failure you find in March costs you a client.
Why this matters to me
When it is only you, a leak in follow-up or onboarding is not a department's problem. It is yours, every week, until you fix it. That is why I treat the quiet weeks as scheduled repair time instead of leftover time.
The best time to fix the roof is when it is not raining, and the holidays are the dry season.
You do not need a perfect January. You need one thing that works without you on the first Monday back, and the rest builds from there. Building these systems end to end is the core of the work I do for clients.
Keep building.Ekai
Questions people ask
What business systems should I fix during the holidays?
Start with the three that leak the most when you are busy: lead follow-up, client onboarding and reporting. Each can be rebuilt in a few focused half-days, and each has an obvious test for whether it works.
How do I decide what counts as finished?
Write a definition of done before you start: a specific test anyone could run. For example, a test lead submits the form and receives every follow-up message on schedule without you touching anything.
Should I work through the holidays to get ahead?
Work in short, protected blocks and rest the rest of the time. Harvard Business Review's piece on managing energy argues that responding to demand with ever longer hours leads to burnout, so plan the work around your energy rather than around the calendar.
What if I only have a few free days?
Pick one project, not three. A finished follow-up system beats three half-built ones, and you can schedule the other two for January.
Sources
- 1
- 2
- 3
